While looking through the OLEObject code a few things:
* The OLEObject class has the undocumented methods SEND, SENDWITH, CLASS and
COPY: these methods
first check with the help of the method hasOLEmethod() whether the Windows
side implements
methods by that name and if so, invokes the Windows methods. This is a nice
feature IMHO as
these names can be seen in Windows programs relatively often such that it
becomes a PITA to use
unknown() or dispatch() instead.
However, having these methods in the OLEObject class makes it impossible to
invoke the same
methods in the ooRexx root class .Object. This IMHO is a no go, it must be
possible for an
ooRexx programmer to invoke them for OLEObject objects as well. So there is
a need for having
one or more methods that can be used for forcing the invocation of the
ooRexx .Object methods.
One idea would be to add for each masked method one by the same name
followed by a dot and the
string "super". The dot in the name should make it impossible to be mistaken
with an existing
Windows method as to the best of my knowledge it is illegal for Windows
method names to contain
a dot (this idea was the reason why BSF4ooRexx uses dots in BSF routine and
BSF method names to
make sure that sending messages that contain a dot can only be resolved on
the Rexx side).
This would mean that methods with the name SEND.SUPER, SENDWITH.SUPER,
CLASS.SUPER and
COPY.SUPER get added which merely do a "FORWARD CLASS (super)".
In any case all these methods must be documented such that the programmer
can become aware of
them and understands what they do and why.
* The method "hasOLEmethod(name)" is currently defined to be private such that
Rexx programmers
cannot use it. This method could prove helpful in some situations as it
allows to interrogate an
OLEObject whether it implements a specific method (supplying the name).
Therefore I would
suggest to make this method available with the appropriate documentation.
* The native code defines the attributes !PROGID and !CLSID for an OLEObject,
but does not make
them available to the programmer. Suggesting to make a get attribute
available for the
programmers and document it.
o Currently if a Windows component returns a different OLE object the
ooRexx support wraps it
up as an OLEObject (using its dispatch id). In this case it would be
especially helpful to
have access to their !PROGID and !CLSID, which would have to be queried
which is not the
case currently.
Any comments?
Anyone wanting to lend a helping hand (in part or in full), maybe on another issue (using AutoCAD
via OLE): could not find the reason why ooRexx does not create the necessary VT_VARIANT of a
VT_ARRAY of type VT_R8 from an ooRexx array; also did not find the reason why using .OleVariant is
not successful either; so if anyone can shed some light on this or would be able to solve this I
would really appreciate it very much as then the student could go ahead and successfully become able
to use addCircle(center,radius) method of AutoCAD via OLE from ooRexx (other programming languages
are able to do so successfully).
---rony
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
