OLE/ActiveX

Hi,

I've been experimenting with the ActiveX stuff for a bit, and unfortunately
get stuck with what I think is the supplier's OLE source not being fully
object oriented.

Imagine the following: A document consists of lines and the lines consist of
elements. Therefore 3 classes pop up in the OLE structure, a document able
to hold a collection of lines and each line able to hold a collection of
elements. The interface provides a method to create a new document, but then
the problems start. Within the document there are two methods; #addLine: and
#getDefaultLine. Apart from the #getDefaultLine there is no way to create a
line; if I try to #new a line directly, an error is reported 'Class not
registered'. I could live with the #getDefaultLine, but I have the same
problem with the elements; if I try to add an element to the collection of
elements, I get the same problem (class not registered) as when I try to
create a line directly, but in this case I don't have an alternative.

The supplier basically says that it all works nicely in Visual Basic, but of
course I want it to work with Smalltalk. I have the impression that as VB
merely uses 'classes' as structures for their 'objects', they don't have to
#new them, as they don't create real objects based on these classes. Am I
thuinking along the right lines or am I talking jibberish (won't be the
first time)?

Anybody can shed some light on this?

Thanks in advance,

Ted

Ted

You wrote in message news:8veuc2$4htcs$[hidden email]...
> ...
> I've been experimenting with the ActiveX stuff for a bit, and
unfortunately
> get stuck with what I think is the supplier's OLE source not being fully
> object oriented.
>
> Imagine the following: A document consists of lines and the lines consist
of
> elements. Therefore 3 classes pop up in the OLE structure, a document able
> to hold a collection of lines and each line able to hold a collection of
> elements. The interface provides a method to create a new document, but
then
> the problems start. Within the document there are two methods; #addLine:
and
> #getDefaultLine. Apart from the #getDefaultLine there is no way to create
a
> line; if I try to #new a line directly, an error is reported 'Class not
> registered'. I could live with the #getDefaultLine, but I have the same
> problem with the elements; if I try to add an element to the collection of
> elements, I get the same problem (class not registered) as when I try to
> create a line directly, but in this case I don't have an alternative.

Its not that unusual to restrict creation of subsidiary COM objects so that
they can only be created by a "parent", although if that is the case they
ought to be marked as noncreatable in the type library, rather than just not
registered, which Dolphin would notice. If the subsidiary objects can only
be created by a parent or container, then the latter must obviously expose
methods that can be used to create the subsidiary objects, and possibly
methods to add those objects too. E.g. in MSXML there are methods on
DOMDocument to create new nodes of different types, which are then added
into the document in a separate operation. It seems like you're saying that
the creation methods do not exist?

Another possibility is simply that the components are not properly
registered for some reason, or that the type library contains incorrect
information.

> The supplier basically says that it all works nicely in Visual Basic, but
of
> course I want it to work with Smalltalk. I have the impression that as VB
> merely uses 'classes' as structures for their 'objects', they don't have
to
> #new them, as they don't create real objects based on these classes. Am I
> thuinking along the right lines or am I talking jibberish (won't be the
> first time)?

With few exceptions Dolphin has more powerful (though sometimes lower level
and less seamless) OLE capabilities than VB. It can call all the C++ style
interfaces that VB can't at a user level (e.g. IPersistStream). Therefore if
you can use it from VB, it ought to be possible to use it from Dolphin. Of
course we occassionally find or hear of problem areas, and address them as
soon as we can.

You might need to create the objects in different ways, for example by
passing the prog-id or clsid directly to #createObject:. This can then be
wrapped up in convenience instance creation methods on your classes.

If you have some sample VB code, then it will be easier to map this to the
operations you need to use in Smalltalk, which will probably be similar.

Regards

Blair

Hi Blair,

"Blair McGlashan" <[hidden email]> wrote in message
news:p4MS5.2823$[hidden email]...
> Ted
>
>
> Its not that unusual to restrict creation of subsidiary COM objects so
that
> they can only be created by a "parent", although if that is the case they
> ought to be marked as noncreatable in the type library, rather than just
not
> registered, which Dolphin would notice. If the subsidiary objects can only
> be created by a parent or container, then the latter must obviously expose
> methods that can be used to create the subsidiary objects, and possibly
> methods to add those objects too. E.g. in MSXML there are methods on
> DOMDocument to create new nodes of different types, which are then added
> into the document in a separate operation. It seems like you're saying
that
> the creation methods do not exist?
>
> Another possibility is simply that the components are not properly
> registered for some reason, or that the type library contains incorrect
> information.
>
> > The supplier basically says that it all works nicely in Visual Basic,
but
> of
> > course I want it to work with Smalltalk. I have the impression that as
VB
> > merely uses 'classes' as structures for their 'objects', they don't have
> to
> > #new them, as they don't create real objects based on these classes. Am
I
> > thuinking along the right lines or am I talking jibberish (won't be the
> > first time)?
>
> With few exceptions Dolphin has more powerful (though sometimes lower
level
> and less seamless) OLE capabilities than VB. It can call all the C++ style
> interfaces that VB can't at a user level (e.g. IPersistStream). Therefore
if
Well, after doing it all step by step (great tool - the workspace with
temporary variables), I managed to pin the problem down to some application
specific business rules that I didn't quite follow/put in the wrong order.
I've got it all working now. Checking it with the VB interface, indeed in
Dolphin you can do loads more. Especially the #invokeId: was a bit of a
shock to the developers ;-). Anyway, if I ever get the chance to do some
design work for an OLE object, I now know what to look for and what the do's
and dont's are.

Thanks for your help Blair.


> Regards
>
> Blair
>
>

Ted