|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
object is a simple variant type, unlike OLEObject.
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.
|
|
|
|
|
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. 
I might have a play with the IDispatch interface anyway, as it sounds a quite interesting thing to do.
Cheers,
B.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Hi,
I just wanted to get peoples opinions on OO and COM, and how they approach developing components to be used in a distributed manner. Using COM for n-tier development typically involves some separation of action/abstraction logic and the data it works on, were pure OO involves keeping the action logic with the data. If you are designing a system that will use com+ components, do you consider OO or do you just think of it as passing around ADORecordsets/XML for example? Do objects even come into the picture?
Just interested on peoples experience.
Nick.
|
|
|
|
|
Can any one give some liks for learing COM.
I am a bigginer in for COM.
I have C++/VC++ Knowledge
Regards
Shirlie
|
|
|
|
|
|
I am currently trying to work with COM and make a container to hold a Word document. What is happening is that I create the frame window, then insert the Word document, and it does what it should, it brings up the doc, puts the Word toolbars and menus on the window, etc. But one thing it does that is strange is that it has several of the toolbar buttons disabled. The Open, New, and Save buttons are disabled. Also, the Print button is enabled but when I click on it, it doesn't do anything. Other buttons, such as the spell check work fine. Everything seems to work fine when using the menus. Does anyone know why these buttons are disabled? How to enable these buttons? Anything about this issue?
I looked through several articles, such as the Using MS Office in an MFC Application but that doesn't ever mention anything like this....
|
|
|
|
|
Have you checked the properties for the control. There might be property settings that will allow you to view the toolbars. If you are importing the Word DLL then look at the TLH file. There must be some property setting. I will look into it myself when I get the time and see if I can find something.
|
|
|
|
|
Hey everyone!
I'm working on an application that suppose to send a WAP configuration from a PC to a mobile via SMS, the mobile that i'm using to send the SMS is Nokia 6110. I'm using a specific SDK (SDK Nokia Connectivity) based on COM objects,I managed to send the SMS using the functions described in the SDK but i can't receive the SMS on the destination mobile.
If anyone has already used this SDK for sending SMS, plz reply to me
Bebe Harhour
|
|
|
|
|
Hi:
I know microsoft word support automation,I can use the fillow two method access word object:
#import .....
IApplicationPtr pApp;
(1)
// Start up existing word, if available
HRESULT hr = pApp.GetActiveObject(L"Word.Application");
(2)
// Start up fresh instance of word
HRESULT hr = pApp.CreateInstance("Word.Application", NULL,LSCTX_LOCAL_SERVER);
I wonder how to implement it in my application. I use Windows API RegisterActiveObject to register my application interface,but it can only use the first method to access my object.Can someone help me? Thanks!
I am seeking...
For what?
Why did you ask me for what? I don't know!
|
|
|
|
|
For CreateInstance() to work, you need to register your class factory with a CoRegisterClassObject() call.
(RegisterActiveObject() is only for existing app instances).
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. Support for development will ship at the same time as the Windows XP Service Pack 1 (SP1) release.
|
|
|
|
|
Thanks very much!
BTW,if I want use build both method in my application,should I use both RegisterActiveObject and CoRegisterClassObject?
I am seeking...
For what?
Why did you ask me for what? I don't know!
|
|
|
|
|
|
Thanks very much!!!
I am seeking...
For what?
Why did you ask me for what? I don't know!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
