Property is read-only - COM object ( Outlook )

Hey all, just been trying to fix a problem I have with an Outlook Addin
COM object and noticing something strange.

The problem is when accessing an object via an IDispatch created
instance rather than a wrapped class, i.e. the following works:

(Outlook_Application new explorers item: 1 ) Caption

But

((IDispatch createObject: 'Outlook.Application') explorers item: 1) Caption

gives "Property is read-only".

I can however get: (IDispatch createObject: 'Outlook.Application')
explorers count

So my assumption is a requirement to access the array'd element
differently somehow when dealing with IDispatch based objects, however I
can't seem to find any references to it - any ideas?

Mark,
"Mark Derricutt" <[hidden email]> wrote in message
news:ctumvp$[hidden email]... This is because of the way IDispatch>>doesNotUnderstand: deals with
Microsoft's distinction between properties and methods.  If you debug the
expression, you'll see that the problem occurs because the IDispatch
returned by #explorers doesn't understand #item:.  The DNU handling guesses
that since #item: takes an argument, it's either a method or property put.
If you avoid the DNU handling by using

    ((IDispatch createObject: 'Outlook.Application') explorers getProperty:
'item' item: 1)

You get the result you expect.  I attribute the issue to the (to me) useless
distinction between methods and properties, but then I'm a certified
Smalltalk bigot anyway ;^).

HTH,

Don

>
> I can however get: (IDispatch createObject: 'Outlook.Application')
> explorers count
>
> So my assumption is a requirement to access the array'd element
> differently somehow when dealing with IDispatch based objects, however I
> can't seem to find any references to it - any ideas?
>
>

Don Rylander wrote:

>    ((IDispatch createObject: 'Outlook.Application') explorers getProperty:
>'item' item: 1)
>  
>
Sweet, that seems to work - gah, now it brings me yet another problem
which I'm trying to identify, now I'm I'm walking through objects
differently than the wrapped ones, things are slightly differenent, now
I can't seem to find the additional typelib on the objects to connect my
sink to ( in this instance, the _CommandBarButtonEvents typelib, has to
be there somewhere...

COM IS EVIL!

Mark Derricutt wrote:

> the additional typelib on the objects to connect my sink to ( in this
> instance, the _CommandBarButtonEvents typelib, has to be there
> somewhere...

Found it, and everything looks likes it working, now I'm off to delete
3gb of mp3s to make room for a VMWare image where this code actually
breaks - oh well, they were tunes I'd never heard anyway :p