The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

ActiveX/COM client problem

I am trying to write a COM client/server set of wrappers that are intended for Qt.  I mention Qt because I'm not using any microsoft compiler or template library like ATL or whatever - forcing me to develop these by hand.  That, and I want to understand COM and what better way then to write my own wrapper.

So, I cam calling myDisp->Invoke with the correct parameters to receive a new interface. Using that interface, I'm calling Invoke again with nearly the same parameters to get another interface.  The second call is failing.  The HR I'm getting back is 0x57.  Not 0x80000057, just 0x57.  I've verified all the params and everything and I just can't find theproblem.  Like I said the Invoke between use #1 and use #2 is nearly identical.

How can I best track down the erro 0x57 especially if it's occurring inside COM?

If someone can dialog with me on this I can send code snippets and whatnot.  I have been stuck on this for days now.
Mark Petryk Send private email
Friday, January 05, 2007
 
 
If the HRESULT is really 0x57, that's a success code, not a failure. Failure HRESULTs have the first bit set to 1, so a failure would need to be greater than 0x80000000.

Friday, January 05, 2007
 
 
Well, 0x57 == Decimal 87, and WinError.h has this:

//
// MessageId: ERROR_INVALID_PARAMETER
//
// MessageText:
//
//  The parameter is incorrect.
//
#define ERROR_INVALID_PARAMETER          87L    // dderror


My guess is the author of that function you are calling accidentally used the Win32 error code ERROR_INVALID_PARAMETER instead of the proper COM error code E_INVALIDARG.

If so, that would mean that it doesn't like your parameters - are you possibly not passing the parameters in reverse order? Just to make life interesting, I seem to remember that the parameters need to be in reverse order. It is pretty painful to mess with this stuff without ATL.
Michael G
Friday, January 05, 2007
 
 
Thank you.  It's terrible to mess with this stuff without ATL, and I'm completely unfamiliar with it and kind-of wishing I could use it.  Are the ATL headers "open-source", as in would I be able to acquire them and then fit them to my compiler?

Parameter reversal I'm unsure about.  My object structure is as follows:

myServer.exe      svrDB = CoCreateInstance
 IsvrDB          cursor = svrDB->GetCursor("Table Name")
  IsvrCursor    rowSet = cursor->GetQueryRowSet(count)
    IsvrQueryRowSet

I get a pointer in svrDB without problem.  I can then call GetCursor to get a cursor pointer.  This call works and it has three parameters (though only 1 is shown).  The call to GetQueryRowSet fails.  But the code for GetCursor and GetQueryRowSet is nearly identical except for the interface pointers (of course) and the dispatch ID's and of course the parameters.

The .cursor. pointer has several methods and properties.  One of them is category() property, which returns the name of the table.  So I test with cursor->category() to see if my interface pointer is valid and that function call works properly.  There are other methods, GetEditRowSet, GetAddRowSet and so on, so I implemented one of the others, GetEditRowSet, and I get basically the same failure except with a different HR return value - this time 0x87.

So, in summary:

String cursor->category() works no problem
IQRS  cursor->GetQueryRowSet() fails HR == 0x57
IERS  cursor->GetEditRowSet()  fails HR == 0x87

I'm just totally stumped.  I'll try reversing the parameters.

Thank you, again.
Mark Petryk Send private email
Saturday, January 06, 2007
 
 
holy......... smokes!!!!!!

Reversing the parameters worked!  I am shaking!!!!  I have been stuck on this one problem for a week now, it has had my whole project stalled.

Thank you, thank you, thank you, thank you, thank you, thank you, thank you!!
Mark Petryk Send private email
Saturday, January 06, 2007
 
 
Another example of why COM never really took off, I remember still finding frustrating "gotchas" like that still after two years of working with it full time... anyhow ATL is free and "open source," just download the Microsoft Platform SDK and #include <atlcom.h> and/or <atlbase.h>
Steve
Saturday, January 06, 2007
 
 
The problem with COM was not COM, it was C++.

http://www.nsbasic.com/desktop/info/interview.shtml

[BTW, that article was a gag as noted at the end.]
Codger
Saturday, January 06, 2007
 
 
> Thank you, thank you, thank you, thank you,
> thank you, thank you, thank you!!

:) You're welcome!
Michael G
Saturday, January 06, 2007
 
 
"Another example of why COM never really took off ..."

You're kidding right? Name one other component model that was more successful than COM. Corba? I don't think so.

With the introduction of COM a billion dollar industry was born.
Wayne B Send private email
Monday, January 08, 2007
 
 
"Name one other component model that was more successful than COM."

COM, or more precisely DCOM, is being superceded by SOA and SOAP.  COM served as a simplifying mechanism for calling DLLs and worked well inside a single machine.  When it was expanded to work remotely, a whole host of issues arose, including: versioning, security, latency, and zombie runtimes.  DCOM and CORBA were both learning experiments, but the approach of logically passing objects between different machines has been rejected, and we are now back to passing data structures to APIs (i.e., XML and SOAP).

I worked with DCOM for quite a while and when it worked it provided excellent capabilities, but the earlier poster was right.  Getting DCOM to run successfully in production environments was challenging and a challenge I do not wish to have to repeat.
Wayne M.
Tuesday, January 09, 2007
 
 
Wayne "M" summarized it very nicely... "Getting DCOM to run successfully in production environments was challenging." You would call a method on some interface and get "E_ACCESSDENIED." Nothing else, no documentation, no clues. Or you'd get "S_OK," call succeeded, except everything on the receiving end is NULL or gibberish. And yet "S_OK." 

So you'd just sit there thrashing around for some months trying random things until you found the problem. Such was COM... (*wipes tear from eye*)
John
Tuesday, January 09, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz