|
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.
|
|
|
|
|
Put a breakpoint in DllRegisterServer().
And if you don't export such function, well eh.. now you know!
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 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
|
|
|
|
|
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!!!!
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.
|
|
|
|
|
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.
|
|
|
|
|
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().
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.
|
|
|
|
|
No features from external libraries added.
No custom implementation added.
I soon as I finish with the wizard, I tried to compile.
Thanks.
|
|
|
|
|
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.
|
|
|
|
|
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).
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'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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
