how do I raise COM errors between ActiveX dlls

[ebol]

My history is more of a C++ developer, so I may be missing something obviouse, but I cannot seem to find a method to raise an actual COM error. This would be similar to a C++ AtlReportError (or something like that). The Err.Raise is simlpy a VB runtime error that does not marshall an error across com.

My situation... I've got a ActiveX dll (library) called from an ActiveX exe. My dll is causing an ADO error to be raised that I want to pass on to the activeX to relay onto the main application for logging, etc. I had a method using events where I call RaiseEvent... and capture that in the client (exe) and set a global object that the calling procedure can call after calling the library function. However, it just seems there should be some better way to raise a COM error from VB natively.

thanks,
Eric

[Dave Sell]

Dim'ing a control WithEvents, and using the RaiseEvent is the standard native way of doing things like this.

I never considered there could be an easier way. Is there something better?

[ebol]

At a former company I'm pretty sure someone had done this. But it might have been some WIN API call or something. Just seems odd that VB would support a dll COM object without the ability to raise a true COM Error object that is marshelled to the client. If I can ever hunt it down I'll post it.

In the mean time, I've resolved to using the event, a global error object in the client code, and clearError/checkError helper functions (the later raising a VB error) that you straddle the libary call with.

thanks,
Eric

[Dave Sell]

I am missing something. Why are you using a Global Error Object?

[ebol]

I should clarify. When I say "Error Object" I'm meaning a variable of a custom error class. It's only global in the sense that it's not scoped within the single function that's calling the libary function. It can be global to either the app or only a module. The point is that the event traper function is external to function that causes the event to be raised.

Hmm... perhaps a makeshift diagram would help...

App COM Lib
funcA(...) --> (calls) libFunc(...)
EventTrapFunc(myErrObj) <-- libFunc raises event passing myErrObj
now the trapper function sets a global object that contains the error
funcA calls local checkError()
checkError -> err.Raise....

Hence my helper functions are to take a look at the funcA external varaible and raise a VB error if there is one.

Hope this is readible... tried to improve formatting of above to look like a table with no sucess.

[Dave Sell]

If you start with a main Form and Dim only VB Classes WithEvents, then all those Classes can Raise Custom Events.

No need for all this global data juggling.

[yrwyddfa]

HRESULTs (aka VB Errors) are marshalled across COM apartments, process, and machine.

However, if you want to raise errors across process, or machine, I would recommend that you use the COM+ event service. These are specified as LCE, and are pretty much a subscriber, publisher metaphor pattern.