|
Regarding your declarations, I cannot find anything wrong: it looks as expected.
N.B. I'm not quite convinced yet. I think the problem described in the forum discussion you found could be a consequence of this mixup. The reason why I'm not sure is because it's an .odl file and you want to be compatible with MKTypLib and I'm not 100% on top of what happens then.
So, the server is an out-of-process server.
This means that every call has to be marshalled.
Sohail Kadiwala wrote: The coclass has no threads. The Exe server is multithreaded but the coclass Start method simply delegates the call there.
I don't exactly know what you mean by these statements, but I guess you mean that you do not initialize more than one apartment in the server and that is in the application thread of the server. I hope this also means that you do not call any interface functions from anywhere else than from that thread, even if you're talking about an event sink.
Tell me if this is not the case.
Sohail Kadiwala wrote: Regarding marshalling, I believe standard marshalling should take care of this because i am using the OleAutomation compatible type.
Well, if you haven't built and registered anything else explicitly, the universal marshaller will be used for automation interfaces. This is also known as type library marshalling. Standard marshalling requires you to build a second DLL with the proxy/stub.
I assume you're using typelib marshalling, which is exactly why I was talking about a mixup between boolean types since the generated typelib will be used for marshalling. I think you can figure out the rest if I present the problem as "you may declare a return type as 16-bit wide in your code but 32-bit wide in the typelib".
Sohail Kadiwala wrote: Everything works fine for Start method and I succesfully get the "BSTR" from my clients hence I see no issue about marshalling.
This is not proof of anything other than the call to Start seems to work. The call to IsWorking may still be erroneous even though it looks OK as mentioned above.
I would like to follow up on the forum discussion you found. I think there might be something there to try out.
If you change the type back to VARIANT_BOOL and put a breakpoint after the call is made in oledisp2.cpp, line #373. Try forcing the server to return VARIANT_FALSE and VARIANT_TRUE every second time you call it. Take a look at the lower 16 bits of the return value. It should change between 0x0000 and 0xffff. The upper 16 bits could contain garbage which would make the return value evaluate to true even if VARIANT_FALSE is returned.
What happens? What type is returned (VT_BOOL) and what is the value of it?
Let's first find out what is returned and how it's wrong and then we can try and find the correct solution for it.
--
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
|
|
|
|
|
Let me work on this as you mentioned and update you. I'll create a sample which I can share with you if required.
BTW 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?
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.
|
|
|
|
|
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;
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Sohail Kadiwala wrote: SOLVED!!!
Is it, really? 
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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  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 That is the reason why I copied the values exactly from my memory window, but forgot to mention about it 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
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.
|
|
|
|
|
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]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
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. 
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
|
|
|
|
|
Roger Stoltz wrote: Let me express my most humble gratitude for that.
Someone who sincerely helps should deserve atleast a 5 on CP
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.
|
|
|
|
|
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
|
|
|
|
|
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
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.
|
|
|
|
|
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
|
|
|
|
|
by inserting javascript in a webpage, how can we get information from web page like no.of images, sections, headings...?
|
|
|
|
|
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.
---
![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif) Hakuna-Matada
It means no worries for the rest of your days...
It's our problem free, Philosophy
![Jig | [Dance]](https://codeproject.freetls.fastly.net/script/Forums/Images/jig.gif)
"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."
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
I doubt there is COM on Linux. CORBA, probably.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Thanks for the feedback.
:josh:
My WPF Blog[ ^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle
|
|
|
|
|
There is plenty of COM on Linux.
--
LOADING...
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
:josh:
My WPF Blog[ ^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
