Re: [SOLVED] VARIANT_BOOL return value in Automation class - COM Discussion Boards

Re: VARIANT_BOOL return value in Automation class [modified]

11-Jan-07 0:46

Sohail Kadiwala wrote:
VARIANT_FALSE and FALSE and false are all "0" so when I return VARIANT_FALSE the return value should be 0 and not 1 Any thoughts on this?

Well, this is what I want you to verify immediately after the call has returned.
As read even in the forum discussion the thing is when you return a VARIANT_FALSE, which is defined as a 16-bit wide zero, it may be interpreted as 32-bit wide BOOL type. Infact those are not passed 'by value', they're passed as pointers. I think the following will demonstrate the problem:

short* pwValue = new short;
*pwValue = 0;
long* pdwMoreValue = (long*)pwValue; //This is what happens behind the scenes

// A statement like the one below is totally unreliable because
// the upper 16 bit have never been initialized
if( *pdwMoreValue )
{
    ....
}

My point is that your variable may contain zeros in the lower 16 bits, which would match VARIANT_FALSE, but the upper 16 bits may contain garbage. I want you to find out if this is the case as step #1.

--
Rog

"It's supposed to be hard, otherwise anybody could do it!" - selfquote

"No one remembers a coward!" - Jan Elfström 1998
"...but everyone remembers an idiot!" - my lawyer 2005 when heard of Jan's saying above

User 21559711-Jan-07 5:03

Re: [SOLVED] VARIANT_BOOL return value in Automation class

11-Jan-07 5:03

The return value is returned in VARIANT. I checked the debug memory window and played with it for a while in Visual Studio. The value is being returned from IDispatch::Invoke method. The value of VARIANT succesfully changes from VT_EMPTY to VT_BOOL and VARIANT::boolVal memory location changes from 0000 to ffff when I return VARIANT_FALSE from my server.
It seems like something is going wrong in the IDispatch::Invoke. I suspect the problem you mentioned could be the one present there.

If you are willing to check this at your end and ofcourse spare sometime, I can create simple samples and send it across to you and tell you the locations breakpoints. Let me know

S o h a i l K a d i w a l a

To Err Is Human; to Debug, Divine

modified 21-Apr-21 21:01pm.

User 21559711-Jan-07 6:07

Re: [SOLVED] VARIANT_BOOL return value in Automation class

11-Jan-07 6:07

SOLVED!!!

The problem lies in OleDisp1.cpp

I debugged my server using MFC source files. My CoClass implements IDispatch which is called from my client through COleDispatchDriver derived wrapper class.
So when call goes to following method -

BOOL IsWorking()<br />
{<br />
BOOL result;<br />
InvokeHelper(0x2, DISPATCH_METHOD, VT_BOOL, (void*)&result, NULL);<br />
return result;<br />
}

InvokeHelper will get called, which resides in OleDisp2.cpp.

From here we will finally reach, OleDisp2.cpp Line#375 where the actual call to IDispatch::Invoke will occur taking us to Server's IDispatch implementation

On server side, we will reach
File#OleDisp1.cpp, Line# 1220, Function# COleDispatchImpl::Invoke
Which will call
File# OleDisp1.cpp, Line# 908, Function# CCmdTarget::CallMemberFunc

In this function, the problem occurs somewhere at following locations -
Call# PushStackArgs(...) Line# 991

And Line# 1033

default:<br />
	dwResult = pfnDispatch(pfn, pStack, nSizeArgs);<br />
	break;

after the above call, the value of dwResult changes which results in incorrect value of VARIANT_BOOL being assigned and returned at Line# 1100

case VT_BOOL:<br />
	V_BOOL(pvarResult) = (VARIANT_BOOL)(dwResult != 0 ? -1 : 0);<br />
	break;

I think this clarifies my problem. What are your thoughts?

S o h a i l K a d i w a l a

To Err Is Human; to Debug, Divine

modified 21-Apr-21 21:01pm.

Roger Stoltz11-Jan-07 22:45

Re: [SOLVED] VARIANT_BOOL return value in Automation class

11-Jan-07 22:45

Sohail Kadiwala wrote:
SOLVED!!!

Is it, really? Unsure | :~

So what do you think the solution is?

The information you've provided suggests that the problem only resides in the server. Is this correctly understood?

Sohail Kadiwala wrote:
default:
dwResult = pfnDispatch(pfn, pStack, nSizeArgs);
break;
after the above call, the value of dwResult changes which results in incorrect value of VARIANT_BOOL being assigned and returned at Line# 1100
case VT_BOOL:
V_BOOL(pvarResult) = (VARIANT_BOOL)(dwResult != 0 ? -1 : 0);
break;

What happens here? What is the incorrect value of dwResult (all 32 bits)?
After the assignment above, what does pvarResult->boolVal contain?
If you modify the boolVal value after the assignment, does your client get the same value? This test is to make sure that the problem is only at the server side.

--
Rog

"It's supposed to be hard, otherwise anybody could do it!" - selfquote

User 21559712-Jan-07 0:50

Re: [SOLVED] VARIANT_BOOL return value in Automation class

12-Jan-07 0:50

Roger Stoltz wrote:
Is it, really?

Sorry, I should say - "problem area detected"

Roger Stoltz wrote:
So what do you think the solution is?

I haven't figured out the exact solution to this. I will need to dig into the MFC functions - one that pushes content on stack and the other is an assembly code. I'll try to do that over weekend.

Roger Stoltz wrote:
What is the incorrect value of dwResult (all 32 bits)?

the value of dwResult in memory changes from 00 00 00 00 to 00 00 14 00 after
default:
dwResult = pfnDispatch(pfn, pStack, nSizeArgs);

Roger Stoltz wrote:
After the assignment above, what does pvarResult->boolVal contain?

Since dwResult is now 00 00 14 00 = 5120 Decimal, the value of pvarResult->boolVal becomes -1 i.e. 0xFF. This should not happen because I am returning 0 in my server.

Roger Stoltz wrote:
If you modify the boolVal value after the assignment, does your client get the same value? This test is to make sure that the problem is only at the server side.

Do you mean modifying the memory location in debugging? Or modifying the source - which will mean rebuilding the MFC source tree? I think you mean modifying in memory window - I changed it from 0xFF to 0x00 and it returns 0x00 to the client.

S o h a i l K a d i w a l a

To Err Is Human; to Debug, Divine

modified 21-Apr-21 21:01pm.

Roger Stoltz12-Jan-07 1:50

Re: [SOLVED] VARIANT_BOOL return value in Automation class

12-Jan-07 1:50

Sohail Kadiwala wrote:
Roger Stoltz wrote:

Is it, really?

Sorry, I should say - "problem area detected"

Ok, but in my opinion you've only found where it goes wrong, not why. The root cause could still be somewhere else.

Sohail Kadiwala wrote:
the value of dwResult in memory changes from 00 00 00 00 to 00 00 14 00

This is rather funny how we can misinterpret each other, because now I have to ask if this is big-endian or little-endian. If you've copied this directly from the memory debug window it would be little-endian and in that case the value would be 0x00140000 which is 1310720 in decimal. I assume this is the case since it would make more sense to me. My point is that the lower 16 bits that may represent the VARIANT_BOOL type is still equal to VARIANT_FALSE.

Never mind, try this instead:
I've created a simple ActiveX control and a client with two methods returning VARIANT_TRUE and VARIANT_FALSE respectively as I've described it in the interface file (.idl).
It worked like expected until I explicitly changed the return types in my server from BOOL to VARIANT_BOOL. Then I got exactly the behaviour as you have. I don't even have to get marshalling involved: everything is still in the same apartment.
Try and change your return type back to BOOL in your .cpp and .h files, not in the .idl file. Rebuild and see what happens.
I haven't dug into exactly why I get this behaviour, but I suspect there's a mixup (or mismatch rather) between pointers to 16-bit types and 32-bit types as I've mentioned earlier.

Let me know what the results are.

--
Rog

"It's supposed to be hard, otherwise anybody could do it!" - selfquote

User 21559712-Jan-07 4:11

Re: [SOLVED] VARIANT_BOOL return value in Automation class

12-Jan-07 4:11

Roger Stoltz wrote:
Try and change your return type back to BOOL in your .cpp and .h files, not in the .idl file. Rebuild and see what happens.

Overwhelmed Smile | :)

So called it SOLVED.

Roger Stoltz wrote:
This is rather funny how we can misinterpret each other, because now I have to ask if this is big-endian or little-endian. If you've copied this directly from the memory debug window it would be little-endian and in that case the value would be 0x00140000 which is 1310720 in decimal. I assume this is the case since it would make more sense to me. My point is that the lower 16 bits that may represent the VARIANT_BOOL type is still equal to VARIANT_FALSE

Yeah, I thought about it Smile | :)

That is the reason why I copied the values exactly from my memory window, but forgot to mention about it Smile | :)

So it still remained ambiguos

Roger Stoltz wrote:
Ok, but in my opinion you've only found where it goes wrong, not why

This change has solved the problem! I now think the problem is in Wizard generated code! What do you think?

BTW thank you for followup and your in depth reply. my 5s for you Smile | :)

S o h a i l K a d i w a l a

To Err Is Human; to Debug, Divine

modified 21-Apr-21 21:01pm.

Roger Stoltz12-Jan-07 4:40

Re: [SOLVED] VARIANT_BOOL return value in Automation class

12-Jan-07 4:40

Sohail Kadiwala wrote:
That is the reason why I copied the values exactly from my memory window, but forgot to mention about it

I suspected that, but I got a little confused when you wrote that it evaluated to 5120 in decimal. Don't worry about it!

Sohail Kadiwala wrote:
I now think the problem is in Wizard generated code! What do you think?

Well, partly true.
I haven't found a way to make the wizard to use VARIANT_BOOL as type anywhere. That could be a problem and if so you have to explicitly modify it and that could be considered a "problem" in the wizard generated code.
But, I think the return types in your source code files (.cpp and .h) have been manually modified and if that's the case we cannot blame the wizard. :->

Sohail Kadiwala wrote:
thank you for followup and your in depth reply.

You are most welcome! Rose | [Rose]

I'm glad if I was able to help you.

Sohail Kadiwala wrote:
my 5s for you

Let me express my most humble gratitude for that. Blush | :O

All in all it feels good to leave for the weekend after nailing this one.

Have a nice weekend Sohail
--
Roger

"It's supposed to be hard, otherwise anybody could do it!" - selfquote

User 21559712-Jan-07 5:24

Re: [SOLVED] VARIANT_BOOL return value in Automation class

12-Jan-07 5:24

Roger Stoltz wrote:
Let me express my most humble gratitude for that.

Someone who sincerely helps should deserve atleast a 5 on CP Smile | :)

Roger Stoltz wrote:

Sohail Kadiwala wrote:
I now think the problem is in Wizard generated code! What do you think?

Well, partly true.
I haven't found a way to make the wizard to use VARIANT_BOOL as type anywhere. That could be a problem and if so you have to explicitly modify it and that could be considered a "problem" in the wizard generated code.
But, I think the return types in your source code files (.cpp and .h) have been manually modified and if that's the case we cannot blame the wizard.

I don't think I modified the source files (.H and .cpp). To confirm this, in my sample application, I added another COM method to my interface selecting the return type to be VARIANT_BOOL. The result was VARIANT_BOOL data type as the return type in .H and .CPP files.

Now, this makes me curios - What version of Visual Studio are you using?
I am using MSDE 2003 version 7.1.3088

Roger Stoltz wrote:
All in all it feels good to leave for the weekend after nailing this one.

Have a nice weekend

Yes, I am also feeling happy to nail this one, although I could still have moved ahead with my work with some alternate declaration. But with you around and eager to help, I pushed myself a bit harder. Its been a long time since I got stuck with such a time consuming problem - so I am feeling a lot happy nailing it.

You have a great weekend.

I still have an hour before I head home, came late for work so need to wait some more time completing stuff.

Warm Regards,

S o h a i l K a d i w a l a

To Err Is Human; to Debug, Divine

modified 21-Apr-21 21:01pm.

Roger Stoltz12-Jan-07 5:37

Re: [SOLVED] VARIANT_BOOL return value in Automation class

12-Jan-07 5:37

Sohail Kadiwala wrote:
I am using MSDE 2003 version 7.1.3088

That explains it. I'm still using VC6.

Sohail Kadiwala wrote:
I still have an hour before I head home, came late for work so need to wait some more time completing stuff.

Either you don't arrive at work until the afternoon or you're not located in India as your profile claims... I hope it's the latter one.

In Sweden the time is now 17:35 and I'm about to leave for the weekend in half an hour.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote

User 21559714-Jan-07 7:50

COM and windows service application ...

14-Jan-07 7:50

Roger Stoltz wrote:
Either you don't arrive at work until the afternoon or you're not located in India as your profile claims... I hope it's the latter one.

I do arrive on time at work. At present, I am in Hampshire County, UK. Weekend is over now, and I am planning for my day tomorrow Smile | :)

S o h a i l K a d i w a l a

To Err Is Human; to Debug, Divine

modified 21-Apr-21 21:01pm.

Sakthiu9-Jan-07 0:31

Sakthiu

9-Jan-07 0:31

Dear All,

I have Windows Service Application that has one COM Interface.

Here My problem is that when change this application to service i am facing a problem. sometimes the COM interface gets handle first or the main application gets handle. Once the main application gets handle, I can not call its COM interface functions.. Why ?

Thanks.

Nice things do nice works

How can get information from web page ?

ankprasanna9-Jan-07 0:22

ankprasanna

9-Jan-07 0:22

by inserting javascript in a webpage, how can we get information from web page like no.of images, sections, headings...?

COM dll internals.

HakunaMatada8-Jan-07 19:21

HakunaMatada

8-Jan-07 19:21

What is the difference between a COM dll and a regular dll? I would like to know how memory is managed for both the dlls. Does a regular dll get loaded into the calling application's memory space each time an application makes call to one of its functions or does it get loaded into a global heap? How is this different from a COM dll?

Thanks.

---

Hakuna-Matada Beer | [beer]

It means no worries for the rest of your days...
It's our problem free, Philosophy
Jig | [Dance]

"I think my response was 'What idiot dreamed this up?'" -- Mary Ann Davidson, Oracle's chief security officer, in typical blunt manner, remembering her reaction to the company's scheme to brand its databases as "unbreakable."

Re: COM dll internals.

Phil Harding15-Jan-07 3:45

Phil Harding

15-Jan-07 3:45

HakunaMatada wrote:
What is the difference between a COM dll and a regular dll

As DLL's go, there is no difference. Both types have function exports, both types are mapped into the address space of the loading process (and shared across processes).

All COM DLL's have a common and specific set of function exports, whereas regular DLL's have exports specific to the DLL module.

Phil Harding.
myBlog [^] | mySite [^]

System monitor using WMI

abhiramsss8-Jan-07 12:26

abhiramsss

8-Jan-07 12:26

Hi

i want some help from you regarding vbscript and WMI

suppose there are five systems in a network say 1 2 3 4 5 and iam monitoring other systems from system 1. so whenever I run a script it should tell me what are the other systems running in the network and write the output to a log file. and the script should check for a folder and the files in that folder on remote machines and writes to the log file on the monitoring systyem i.e on system 1

can u please help me with a script example for this

Thanks in Advance

abhi

COM on Linux?

Josh Smith8-Jan-07 10:27

8-Jan-07 10:27

I'm on a project where they are considering the idea of creating a COM object to expose some functionality. I don't have any COM experience, so I figured I ask the experts for some guidance.

One concern is that there is a possibility that functionality will need to eventually be hosted on a Linux server. In other words, the COM object will be communicated with from a Windows client to a Linux box via messaging.

I've searched the Web to see what has been written on this subject, but didn't find much information on the subject. Is there good support for developing/using COM objects in Linux? If so, I'd appreciate it if you could post a link to information about the issues/risks/etc to keep in mind when designing the COM class. If not, what makes it a problem?

Thanks for any help.

:josh:
My WPF Blog[^]

We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle

Christian Graus8-Jan-07 11:22

Christian Graus

8-Jan-07 11:22

I doubt there is COM on Linux. CORBA, probably.

Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog

Josh Smith8-Jan-07 11:59

8-Jan-07 11:59

Thanks for the feedback.

:josh:
My WPF Blog[^]

We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle

Jörgen Sigvardsson8-Jan-07 13:18

Jörgen Sigvardsson

8-Jan-07 13:18

There is plenty of COM on Linux. Smile | :)

--
LOADING...

Josh Smith9-Jan-07 3:48

9-Jan-07 3:48

Joergen Sigvardsson wrote:
There is plenty of COM on Linux.

Do you have any advice or information to share regarding COM on Linux? Are there a lot of problems when creating a COM object to be used on both Windows and Linux? If so, are they bad enough to warrant "second thoughts" about whether it is a reasonable thing to do?

:josh:
My WPF Blog[^]

We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle

Jörgen Sigvardsson9-Jan-07 4:27

Jörgen Sigvardsson

9-Jan-07 4:27

When it comes to DCOM, there should be no problems, as all communication is made over the wire. When it comes to COM - the binary standard, it will probably not work out of the box. Last time I checked, g++ did not generate ABI-compatible vtables compatible with the VC++ compiler. Some hackery in C + Wine might do the trick, but it's nothing I would like to maintain...

If you can manage to recompile components for Linux, then there is no real problem as far as binary compatibility goes.

EntireX is a system I played with a long time ago, and from what I can tell, it's still around - although unsupported! There might be other solutions too. I know there are other products for other Unix-operating systems (if I recall correctly, Microsoft bought it from Mainsoft (I think their name was) when they ported IE to Solaris).

I am however a bit skeptical about using COM-technology with Linux. It's akin to pushing a cube through a round hole - it just doesn't fit very well. Are there any specific reasons why you won't make the COM-objects to act like proxies on the Windows-side? It would be an easy task to hook it all up with RPC between Linux and Windows through the proxies. That way you can have proxy objects for communication with Linux servers, and "regular" objects for communication with Windows servers.

Is transparency is an absolute and unalterable requirement? Also, is there a design that you have to adher to, or do you have free reign on the design?

--
Verletzen zerfetzen zersetzen zerstören
Doch es darf nicht mir gehören
Ich muss zerstören

Josh Smith9-Jan-07 7:45

9-Jan-07 7:45

First of all, thanks a lot for the help. I really appreciate it!

Joergen Sigvardsson wrote:
I am however a bit skeptical about using COM-technology with Linux.

Me too!

Joergen Sigvardsson wrote:
Is transparency is an absolute and unalterable requirement? Also, is there a design that you have to adher to, or do you have free reign on the design?

This is a "top down" design approach, where high-level executives push down their decisions on low-level technical details. I'm just looking for ammo to shoot back with. Smile | :)

:josh:
My WPF Blog[^]

We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle