COM Discussion Boards

Re: Default parameters in IDL

18-Sep-02 20:47

add the [optional] attribute in front of the parameter(s).

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.

Vi220-Sep-02 3:32

Vi2

20-Sep-02 3:32

[id(1)] HRESULT Func1([in, optional] long a);
[id(2)] HRESULT Func2([in, defaultvalue(777)] long a);
[id(3)] HRESULT Func3([in, optional] BSTR a);
[id(4)] HRESULT Func4([in, defaultvalue("xxx")] BSTR a);
And only for VARIANT
[id(5)] HRESULT Func5([in, optional] VARIANT a);

With best wishes,
Vita

OLE Object DocFiles and the Clipboard

Striker918-Sep-02 15:54

Striker9

18-Sep-02 15:54

I have a question: I have a serialized OLE Object DocFile (Excel Worksheet) that I need to copy to the clipboard and then paste into MS Word using the "PasteSpecial" method and Automation...I use StgOpenStorageEx to load the docfile and then I copy it to the clipboard using COleDataSource::CacheData and COleDataSource::SetClipboard... problem is when I try to paste special in Word, it says "Clipboard is empty or contains invalid data"...I am using the clipboard format "DataObject" when copying to the clipboard and the STGMEDIUM type is TYMED_ISTORAGE. I read that it might be that I need to use the "Embed Source" and "Object Description" clipboard formats in order to copy correctly. Is this true? How should I do this? Thanks for your help...

-Striker9

Problem registering (0x000003e6)

ssirisha18-Sep-02 2:46

18-Sep-02 2:46

I have just created an empty COM DLL with support to MFC using VC++5.0. When complied, it fails to register.

Regsvr32: LoadLibrary(".\Debug\testxyz.dll") failed.
GetLastError returns 0x000003e6.

I looked up for the error message and it is "Invalid access to memory location"

Thanks for your help in advance.

Stephane Rodriguez.18-Sep-02 3:15

18-Sep-02 3:15

Put a breakpoint in DllRegisterServer().
And if you don't export such function, well eh.. now you know! Cool | :cool:

ssirisha18-Sep-02 3:19

18-Sep-02 3:19

I tried putting a break point in DLLRegisterServer but it doesnot stop there..

Just to clarify once more this error is poping after linking while registering ActiveX Control..

Thanks

Stephane Rodriguez.18-Sep-02 3:29

18-Sep-02 3:29

The custom build-step in VC does a regsvr32 component.dll which in fact loads the component and calls DllRegisterServer() on it.

If it doesn't reach DllRegisterServer(), that's because the problem lies where the COM component itself is loaded, or during the initialisation of the global vars of your COM component.

In other words, your component links with .lib libraries. Some of these libraries export functions and thus the associated .dll file is loaded automatically by the COM component. That's where the problem is. Either you've got a missing DLL the system is trying to load (the error is sometimes weird by the way), or it loads one of the DLLs which executes wrong code in their DllMain() entry point.

What should do now is isolate the code. Use dependancy walker and list all DLLs. Then for each dlls, do a small program that loads them (::LoadLibrary() should be enough). Or if you know how to use it, use RunDll32.exe (Windows 9X) or DllHost.exe (2K/XP).

To get to know if the error is because of one of your global vars, just try loading a stripped down version of your component (all linked code removed) by doing a simple ::LoadLibrary().

Good luck!!!! Cool | :cool:

ssirisha18-Sep-02 3:37

18-Sep-02 3:37

Really appreciate you taking time and explaining. Thank you.

I have created this COM component using the wizard. After the wizard is completed I have not added any methods or any code manually to this project. I simply compiled it and that's when I get this message.

So If I understand your feedback correctly, some of the libraries that the the project has linked are missing or cannot load..
How can I investigate which Dll is having problem with ?

Thanks once again.

Stephane Rodriguez.18-Sep-02 3:55

18-Sep-02 3:55

ssirisha wrote:
I have created this COM component using the wizard.

So you probably haven't added any features from external libraries yet. Do you ?

If that's the case, then you may also get the problem if you use the wizard to create an ActiveX or ATL component, with no custom implementation inside. Tried it ?

I would suggest that if this code linking and registering is fine, that you start adding code from this point, until you reach the error. That may speed up a little bit code isolation.

Otherwise, as I said, I would load each external library separately with a ::LoadLibrary().

ssirisha18-Sep-02 4:05

18-Sep-02 4:05

No features from external libraries added.

No custom implementation added.

I soon as I finish with the wizard, I tried to compile.
Thanks.

IDispatch

Barry Lapthorn17-Sep-02 9:09

17-Sep-02 9:09

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'. Wink | ;)

Stephane Rodriguez.17-Sep-02 9:53

17-Sep-02 9:53

a. Yes, provided automatically by VB or other automation-language by just loading the type-library (of course all interfaces must be dispinterfaces).
b. Yes, provided by late binding (VB Automation uses late binding, which means all of your interfaces are dispinterfaces).

Barry Lapthorn17-Sep-02 11:06

17-Sep-02 11:06

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.

David Salter17-Sep-02 11:31

David Salter

17-Sep-02 11:31

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.

Barry Lapthorn18-Sep-02 8:29

18-Sep-02 8:29

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. Smile | :)

Stephane Rodriguez.17-Sep-02 18:47

17-Sep-02 18:47

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).

Barry Lapthorn17-Sep-02 22:22

17-Sep-02 22:22

Thanks Stephane,

Ah, now we're getting somewhere! I'm pretty sharp on my C++, but I'm not a COM person or VB( Wink | ;)

), 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.

Stephane Rodriguez.17-Sep-02 23:26

17-Sep-02 23:26

object is a simple variant type, unlike OLEObject.

Anonymous18-Sep-02 2:56

Anonymous

18-Sep-02 2:56

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.

Stephane Rodriguez.18-Sep-02 3:17

18-Sep-02 3:17

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...

Barry Lapthorn18-Sep-02 8:32

18-Sep-02 8:32

I don't think that's appropriate to what I've been asked to do Smile | :)

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 | :OMG:

I might have a play with the IDispatch interface anyway, as it sounds a quite interesting thing to do.

Cheers,

B.

Bart Robeyns17-Sep-02 13:50

Bart Robeyns

17-Sep-02 13:50

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'.

Barry Lapthorn18-Sep-02 8:26