ActiveX issues in Dolphin...

I am trying to work with Excel (97 and 2000) via ActiveX in Dolphin.
ActiveX in Dolphin does not seem to be quite as easy as in VB.  I did not
see any documentation regarding ActiveX in the education center, is there
any?

Here is one specific problem:

VB Code:
=====================
    Set xlApp = CreateObject("Excel.Application")
    Set xlWb = xlApp.Workbooks.Open("D:\file.xls")
=====================
Dolphin Code: (via DNU)
=====================
  xlApp := IDispatch createObject: 'Excel.Application'.
  xlWb := xlApp Workbooks Open: 'D:\file.xls'
=====================
I get this error 'Unable to set the Open property of the Workbooks class' on
the second line.  Open() is not a property, it is a method.

I also tried generating the classes via the ActiveX component wizard.  I
tried to be selective about the classes I generated but it ended up
generating a ton of Excel classes (I guess it generates all classes that are
referenced).  I wonder if a future enhancement might be on demand class
generation, that way only the classes actually needed in Smalltalk would be
generated.

I also found that the Workbook.FullName property getter was represented as
Workbook<<fullName: lcid .  If I just send fullName it uses DNU and is slow,
if I send fullName: nil it works faster than the DNU.  There are quite a few
properties and methods that have this lcid parameter.  What is it, and why
is it there?

I am also curious as to why some Excel classes were prefixed with an
underscore.  Workbook for example became Excel_Workbook, I would have
expected it to be ExcelWorkbook.

I was able to accomplish what I needed to do by using the generated classes
with some changes.  However I would like to better understand how ActiveX is
implemented in Dolphin.

Chris

Chris,

> I am trying to work with Excel (97 and 2000) via ActiveX in Dolphin.
> ActiveX in Dolphin does not seem to be quite as easy as in VB.  I did not
> see any documentation regarding ActiveX in the education center, is there
> any?

I found the IDispatch class-side example methods to be very helpful.  You
might find something on the Wiki.  I recently posted something (shamelessly
stolen from Blair long ago<g>) that gets IDL from an IDispatch instance, and
might help you sort out the problem.


> I also tried generating the classes via the ActiveX component wizard.  I
> tried to be selective about the classes I generated but it ended up
> generating a ton of Excel classes (I guess it generates all classes that
are
> referenced).  I wonder if a future enhancement might be on demand class
> generation, that way only the classes actually needed in Smalltalk would
be
> generated.

Interesting idea, but, I'd be concerned about development/deployment issues:
what happens when an end user runs down a path you didn't expect?  My
concern is that if it worked at all, the app would intermittently crawl
generating things that it needs (or thinks it needs).  I sorta like the idea
of generating as a development step: it either generates something
tolerable, or not in which case one can discard the changes and use a
non-generating approach.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Christopher

You wrote in message news:9mers6$1nlm3$[hidden email]...
> I am trying to work with Excel (97 and 2000) via ActiveX in Dolphin.
> ActiveX in Dolphin does not seem to be quite as easy as in VB.

It is certainly a challenge to beat VB at is own game and on its home
territory, and there is still work to do to achieve that. On the other hand
it is possible to utilize Active-X controls in Dolphin that VB can't use at
all.

>...
> I get this error 'Unable to set the Open property of the Workbooks class'
on
> the second line.  Open() is not a property, it is a method.

There are two factors at play here:
1) VB's syntax allows it to distinguish between a property put and a method
invocation - it has the notion of assignment to properties of an object,
whereas in Smalltalk one can only send messages to an object. Interestingly
VB cannot distinguish between a propget and a method invocation, and so the
IDispatch specification is deliberately skewed to allow for this.
2) Dolphin's DNU handling of IDispatch does not use type information, even
if it is available, and thus (on top of the (1)) it has to make a simple
assumption in its DNU processing. Generally this works well for propgets,
but often fails for propputs.

I intend to improve this in future, but it is not a terribly high priority
because the alternative of generating interface classes is much to be
preferred anyway (at least IMO).

>
> I also tried generating the classes via the ActiveX component wizard.  I
> tried to be selective about the classes I generated but it ended up
> generating a ton of Excel classes (I guess it generates all classes that
are
> referenced).  I wonder if a future enhancement might be on demand class
> generation, that way only the classes actually needed in Smalltalk would
be
> generated.

Well one could arrange for that, but I personally would rather that the
complete application were fleshed out via thorough testing before deploying
it. Also you might find that due to differences in the type libraries (new
versions) that the code generated would be different or somehow clashing.
Its an attractive thought, until one considers the ramifications.

Remember that you can achieve much the same effect by selectively generating
the classes. Although the wizard will generate classes you didn't ask for,
these are only placeholder stubs (generated so that at least the complete
set of referenced types is available) and they won't contain any methods
until you explicitly generate them. Furthermore the Lagoon image stripper
will do a very good job of removing the unused stuff, so the eventual
executable size should not be any larger than it needs to be.

So far I've only really found the flood of classes to be a problem with a
few "monolithic" programs or components (MS Office and, sadly, IE spring to
mind). These tend to be older programs that have vast object models that
appear to have grown by accretion.

>
> I also found that the Workbook.FullName property getter was represented as
> Workbook<<fullName: lcid .  If I just send fullName it uses DNU and is
slow,
> if I send fullName: nil it works faster than the DNU.  There are quite a
few
> properties and methods that have this lcid parameter.  What is it, and why
> is it there?

Its the locale id. Its probably an optional parameter, which is why the DNU
without it works. Although we could arrange for the analyzer to
auto-generate further method wrappers that default the optional parameters
to methods/properties, we chose not to do this because Smallltalk's scheme
for doing this can lead to a combinatorial explosion. If you look at some of
the methods in the MS Office object model that take perhaps 15-20
parameters, most of which are optional, and then thing about all the
different combinations required to express _all_ the needed messages in
Smalltalk you will see what I mean. Of course a human coder would choose
only a few of those combinations (hopefully a human coder would avoid
creating methods with 15-20 parameters :-)), but an the analyzer doesn't
know which parameters are more significant than others and so can't make any
kind of intelligent guess. The only reasonable approach I have considered so
far would be to just default all optional parameters, as it seems that one
quite often needs that. It may be that the analyzer will do that in a future
release, but at the moment one has to manually add convenience methods.

> I am also curious as to why some Excel classes were prefixed with an
> underscore.  Workbook for example became Excel_Workbook, I would have
> expected it to be ExcelWorkbook.

It is because the wrapper classes in Dolphin always represent interfaces,
whereas VB tends to mix up the concepts of classes and interfaces and
present them as the same thing. Those classes with an underscore prefix are
probably hidden, default, interfaces on same-named (but without the
underscore prefix) coclasses that would would only appear in VB as the
coclass, yet as objects with all the methods/properties of the default
interface.

>
> I was able to accomplish what I needed to do by using the generated
classes
> with some changes.  However I would like to better understand how ActiveX
is
> implemented in Dolphin.
>

I hope the above helps, but one of the best ways is probably to look at the
methods generated by the type-library analyzer, and also at the component
packages we supply as part of the system (i.e. the MSXML package), which
although they originated as classes generated by the wizard have usually had
careful modifications made to make them more useful and usable in Smalltalk.
These methods (sometimes there are whole classes as in the case of the MSXML
package) can be spotted because they won't be in the **auto-generated**
category.

Regards

Blair

Bill Schwab <[hidden email]> wrote in message
news:9mf140$1td6l$[hidden email]...

> I found the IDispatch class-side example methods to be very helpful.  You

Been there, done that. ;)  They are handy, I am glad they are there.

> Interesting idea, but, I'd be concerned about development/deployment
issues:
> what happens when an end user runs down a path you didn't expect?  My

Yes, there would be room for an untested code path gotcha if ActiveX code
were dynamically generated.  Blair mentioned that the extra classes were
only place holders with no methods, so I don't feel so bad about the number
of classes being generated now.  It is just more to wade through when
looking for a class.  Class categories may provide me with a way of setting
off my "favorite" ActiveX classes I actually use.

Thanks,

Chris

Blair McGlashan <[hidden email]> wrote in message
news:3b8bb492$[hidden email]...

> It is certainly a challenge to beat VB at is own game and on its home
> territory, and there is still work to do to achieve that. On the other
hand
> it is possible to utilize Active-X controls in Dolphin that VB can't use
at
> all.

Yes, I suppose ActiveX is somewhat VB biased.  I wonder if the MS .Net
common VM will improve some of these issues.

> Remember that you can achieve much the same effect by selectively
generating
> the classes. Although the wizard will generate classes you didn't ask for,
> these are only placeholder stubs (generated so that at least the complete

Thank you for clarifying this, I don't feel so bad about the number of
classes now, since most are empty.  My only concern then is that it just
adds to the classes I have to wade through when I am looking for something.
I suppose I could get around that with some browser tricks and possibly
using class categories to set off the classes I care about.

> Its the locale id. Its probably an optional parameter, which is why the
DNU
> without it works. Although we could arrange for the analyzer to
> auto-generate further method wrappers that default the optional parameters
> to methods/properties, we chose not to do this because Smallltalk's scheme
> for doing this can lead to a combinatorial explosion. If you look at some
of

I have some ideas about handling this with a special DNU method.  If I have
time to do something with this I shall post the code.  I may catch hell for
even suggesting this, but perhaps one could consider extending the syntax
just a little to accommodate keyword message sends with optional arguments
to better support ActiveX via the Wizard.  Just a thought. ;)

> I hope the above helps, but one of the best ways is probably to look at
the
> methods generated by the type-library analyzer, and also at the component
> packages we supply as part of the system (i.e. the MSXML package), which
> although they originated as classes generated by the wizard have usually
had
> careful modifications made to make them more useful and usable in
Smalltalk.

Yes, this helps me a lot.  Thank you.

Chris