IDispatch
-
I'm not much of a COM person, but if I do the following in VB: dim obj as object set obj = CreateObject("Excel.Application") then the next line - obj.act doesn't bring up 'obj.activate' in intellisense, i.e. with late binding the intellisense isn't working. If I'm dynamically loading the methods supported by my interface, then I can't use early binding, and therefore can't produce a type library. Or am I wrong? Thanks, B.
That's normal, you've got to use this instead :
Dim obj As OLEObject
Set obj = CreateObject("excel.application")And add a reference to the type-library in your project (Tools \ references \ Microsoft Excel xx.0 library).
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
-
That's normal, you've got to use this instead :
Dim obj As OLEObject
Set obj = CreateObject("excel.application")And add a reference to the type-library in your project (Tools \ references \ Microsoft Excel xx.0 library).
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
Thanks Stephane, Ah, now we're getting somewhere! I'm pretty sharp on my C++, but I'm not a COM person or VB( ;) ), so apologies once again! So what is the difference with: Dim obj as object and Dim obj as OleObject ? I notice the intellisense works on the second (OleObject). I'm going to check out MSDN in the meantime, but I'd expect you guys would give me a simpler answer. B.
-
Thanks Stephane, Ah, now we're getting somewhere! I'm pretty sharp on my C++, but I'm not a COM person or VB( ;) ), so apologies once again! So what is the difference with: Dim obj as object and Dim obj as OleObject ? I notice the intellisense works on the second (OleObject). I'm going to check out MSDN in the meantime, but I'd expect you guys would give me a simpler answer. B.
objectis a simple variant type, unlikeOLEObject.
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
-
objectis a simple variant type, unlikeOLEObject.
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
Think I've gotten the wrong end of the stick. I was under the impression that OleObject was some kind of solution to my problem, but it isn't. The intellisense working with OleObject is because OleObject is part of the Excel objects, and not part of vb. It looks like my solution is either: a. They don't get any intellisense, and I implement something under IDispatch to provide late binding only. or b. Go through some proper analysis of the object model they *should* be using to minimise the need for releasing new interfaces every day.
-
Think I've gotten the wrong end of the stick. I was under the impression that OleObject was some kind of solution to my problem, but it isn't. The intellisense working with OleObject is because OleObject is part of the Excel objects, and not part of vb. It looks like my solution is either: a. They don't get any intellisense, and I implement something under IDispatch to provide late binding only. or b. Go through some proper analysis of the object model they *should* be using to minimise the need for releasing new interfaces every day.
Nope. All Automation object models I have played with so far expose an entry point IApplication interface. This one doesn't change by design, but gives access to lower-level interfaces, such like IDocuments, ..., which in turn may be updated. So yes, it's a good habit to support such code snippet, whatever type-library version is implemented behind :
Dim obj as Application
obj...
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
-
I have a requirement at work to produce a component that: a. Allows the use of intellisense in VB b. Allows the 'interface' to be updated remotely, from a server for example. Or rather the interface frequently has more methods added to it. c. To be used in VB Any thoughts? My initial feeling is that only (b) is possible, and by using late binding through IDispatch. I don't think that (a) is a possibility. Trouble is that these 'requirements' break the idea of interfaces remaining constants. The requirements come from a fairly non-techie person who claims that 'we had it in our last place'. ;) B.
There is a small technique to work around. Dim o As Your.IntellisenseObject ' with loading of typelib infprmation => early binding ... o.SomeProp = ... ... Before making of EXE file, you may simply change the bold line with Dim o As Object ' without loading of typelib => late binding Or use the comment between these lines Dim o As Your.IntellisenseObject ' Dim o As Object and ' Dim o As Your.IntellisenseObject Dim o As Object With best wishes, Vita
-
As you stated, an interface must never change after initial publication. But you can support new interfaces from an existing component. Maybe your problem can be solved simply by adding a new interface everytime methods need to be added. Thus you can - use early binding, and have the convenience of intellisense. - update clients simply by distributing the typelib Of course, if clients want to use these new methods, they'd have to be aware of these new interfaces in order to request them. But they'd have to be adapted for the use of the new method anyway, so that doesn't seem to pose any problem. By the way, you can expose the methods of multiple interfaces through IDispatch, and there's a rather elegant solution to this using ATL and what I believe is called 'bitmap-id fields'.
I think I'm going to argue for a better object model. :) Where can I find more info on 'bitmap-id fields'? B.
-
There is a small technique to work around. Dim o As Your.IntellisenseObject ' with loading of typelib infprmation => early binding ... o.SomeProp = ... ... Before making of EXE file, you may simply change the bold line with Dim o As Object ' without loading of typelib => late binding Or use the comment between these lines Dim o As Your.IntellisenseObject ' Dim o As Object and ' Dim o As Your.IntellisenseObject Dim o As Object With best wishes, Vita
That won't actually work for what I want, as there won't actually be a .tlb file associated with the component. :( But the idea is quite crafty ;) B.
-
If you want to use intellisense, then you need to use early binding. Using Late Binding, VB doesn't really know what it is talking to - certainly not at design time anyway. Dave.
Agreed. You'd have thought that VB could have been a bit sneaky and parsed the code as you typed it, and maybe even used IDispatch to see what methods were available other than using the .tlb file. :) B.
-
Nope. All Automation object models I have played with so far expose an entry point IApplication interface. This one doesn't change by design, but gives access to lower-level interfaces, such like IDocuments, ..., which in turn may be updated. So yes, it's a good habit to support such code snippet, whatever type-library version is implemented behind :
Dim obj as Application
obj...
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site.
I don't think that's appropriate to what I've been asked to do :) Sounds like some serious over engineering. I think I'm going to have to argue the case for a better object model. There is some definite commonality in the methods that are being called. Still all this commotion is caused by a trader that thinks they are a developer. :omg: I might have a play with the IDispatch interface anyway, as it sounds a quite interesting thing to do. Cheers, B.
-
I think I'm going to argue for a better object model. :) Where can I find more info on 'bitmap-id fields'? B.
I've delved into my archive and found that the technique actually is called 'DISPID Encoding' and I first learned it from 'Professional ATL COM Programming' by Richard Grimes (Wrox Press, 1998). At http://www.codeguru.com/atl/dispidEncoding.html you can find it online.