how to test object integrity

[Chris Holbrook]

My native optimism is taking a bit of a bashing at the moment. I have a sneaking suspicion that COM is responsible for a new Dark Age of debugging.

Seriously (heh! as if I could!) though, is there a way in which I can monitor the integrity of an object? If it occupied a single block of memory, it would be easy, but my understanding is that it does not.

I should add that my "suspect object" passes the ISOBJECT test and that the correct interface is in play.

What does ISOBJECT do, anyway?

[Michael Mattias]

Well if you believe the help file

Purpose
Determine the current status of a given object variable.

Syntax
oStatus = ISOBJECT(objectvar)

Remarks
ISOBJECT is particularly useful in determining the success or failure of a LET (with Objects) statement. It returns TRUE (-1) if the object variable contains a valid current reference to an object interface, or FALSE (0) if it contains nothing.

ISOBJECT is the complement to the ISNOTHING function.

And as I posted in your other thread, it can be used to determine if a calling function as properly initialized an object variable and do that if required.

Think of it this way:

ISOBJECT is to object variables as ARRAYATTR (arrayname(), 0&) is to array variables.

(While you are at it, did you ever wonder why ARRAYATTR requires the empty parens following arrayvariablename, but with LBOUND and UBOUND the empty parens are optional?)

[Fred Harris]

I'm just making a guess here, but I'd imagine IsObject() internally uses the SUCCEEDED() and FAILED() COM macros to determine the outcome of an internal COM Api call such As CoCreateInstance(), CoGetClassObject(), or QueryInterface(). These macros exclusively test just the highest order bit of the 32 bit HRESULT number. As it turns out there are various shades of success and failure and to get into that you'll need to study up on HRESULTs, FormatMessage() and other wonderful stuff like that.

[Fred Harris]

The other thing is, proper codings of QueryInterface() should first set the return value, i.e., pointer to the requested VTable to a NULL pointer as the very 1st statement in the procedure. The next step is to check the passed in interface identifier against the interfaces supported by the class. If a match is made a pointer to the requested VTABLE is returned by casting the class pointer, i.e., IUNknown ptr, to the requested VTable. If after all the tests are made no match is made within the class's QI() function, then E_NOINTERFACE is returned and this I expect would cause IsObject to return %FALSE.

[Chris Holbrook]

As it turns out there are various shades of success and failure ...

Dark Age alert! Dark Age alert!

So the interface might return true to ISOBJECT and yet be crippled. Hmm..

Thinks.... there is a LOT more to this COM stuff than you would think - stuff you need to know when things go wrong....

[Fred Harris]

Thinks.... there is a LOT more to this COM stuff than you would think - stuff you need to know when things go wrong....

...and things always go wrong

[José Roca]

I'm just making a guess here, but I'd imagine IsObject() internally uses the SUCCEEDED() and FAILED() COM macros to determine the outcome of an internal COM Api call such As CoCreateInstance(), CoGetClassObject(), or QueryInterface(). These macros exclusively test just the highest order bit of the 32 bit HRESULT number. As it turns out there are various shades of success and failure and to get into that you'll need to study up on HRESULTs, FormatMessage() and other wonderful stuff like that.

Quite unlikely.

There was an API function called IsValidInterface, now obsolete because it uses IsBadReadPtr and IsBadCodePtr that can be harmful.

BOOL WINAPI IsValidInterface(LPUNKNOWN punk)
{
   return !(
      IsBadReadPtr(punk,4)                            ||
      IsBadReadPtr(punk->lpVtbl,4)                    ||
      IsBadReadPtr(punk->lpVtbl->QueryInterface,9)    ||
      IsBadCodePtr((FARPROC)punk->lpVtbl->QueryInterface)
   );
}

As a replacement, I have seen suggestions about using VirtualQuery.

[Chris Holbrook]

... obsolete because it uses IsBadReadPtr and IsBadCodePtr that can be harmful....As a replacement, I have seen suggestions about using VirtualQuery.

VirtualQuery instead of BadReadPtr? I could possibly use that elsewhere.

[Michael Mattias]

Why not just use ISOBJECT 'as designed' and let the folks in Florida worry about "How?"

What am I missing here?

I might think I'd lost my curiosity, except I *do* go thru these exercises when functions do not "work as advertised".

But if it works as advertised, I really could not care less "how" it is accomplished and would just as soon leave any maintenance issues to PowerBASIC Inc.

MCM

[Chris Holbrook]

What am I missing here?

You have not read post #1, have you?

[Bob Zale]

If you create an object, and ISOBJECT() returns true, you have a valid object. Period. No exceptions. There is no ambiguity, as much as you seem to be looking for it.

There are no shades of success. You cannot get half an object, any more than you can be half pregnant. I have great difficulty understanding the basis of these comments, as they don't even represent observations, just speculation.

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

>You have not read post #1, have you?

Not only did I read it, you will note I questioned not merely its utility but its very raison d'etre. When I learned it was simply a half-clever way to ask for a free lunch I eschewed all alternatives and began prosthelytizing the virtues of the provided tools.

[Chris Holbrook]

I have great difficulty understanding the basis of these comments, as they don't even represent observations, just speculation.

Mr Zale, do these words seem familiar?

If there's anything you still don't understand, ask the question -- you'll get an answer.

My question was not speculation. José's and Fred's responses were, but it is the kind of speculation in which developers routinely indulge all over the internet. My intention is not to give you a hard time, but to understand sufficiently to debug my code when it fails. The factual part of your response is noted, thanks.

[Chris Holbrook]

>You have not read post #1, have you?

Not only did I read it, you will note I questioned not merely its utility but its very raison d'etre. When I learned it was simply a half-clever way to ask for a free lunch I eschewed all alternatives and began prosthelytizing the virtues of the provided tools.

As someone else once said on these forums, "every head is a world".

[Bob Zale]

Chris--

My entire post was factual. I'm not in the habit of being disingenuous with my customers.

There is abundant speculation evident. The problem is not that it hurts me, but when given as fact, it hurts and misleads your many friends who read it and then believe it.

Objects and COM is not some wild scheme to abuse the programmer. It's a rock-solid technology which can provide huge rewards. Use it to your benefit.

Best regards,

Bob Zale
PowerBASIC Inc.

[Chris Holbrook]

Bob, on the basis that we can't both be right and that it is "your house", I will shut up.

[Michael Mattias]

> "every head is a world".

Aha.
Creative Tension.
A Good Thing.