Automation: VARIANT gets lost
-
are there any known issues with dispatching VARIANTs from one app to another in VS.NET? when dispatching BSTRs and the like, everything goes fine. i tried some older applications (compiled under VS6) on my computer and they do work properly (using VARIANT as a paramter through automation). i built the very easiest example of one server-app exporting one function
VARIANT Test(VARIANT var);and one client using this function through automation. when debugging the client, the server gets properly loaded and the mfc-dispatchwrappers all do their job well (at the and of F11-ing the client the VARIANT-argument is ok as i constructed it). but when i debug the server, the VARIANT-argument getting in there is crap. moreover: it is different for each debugging-session. as the proper functions get called, i assume, there's everything ok with registring the component and that stuff. is there anything known about this issue? any hints and ideas are greatly appreciated... :| thx. :wq -
are there any known issues with dispatching VARIANTs from one app to another in VS.NET? when dispatching BSTRs and the like, everything goes fine. i tried some older applications (compiled under VS6) on my computer and they do work properly (using VARIANT as a paramter through automation). i built the very easiest example of one server-app exporting one function
VARIANT Test(VARIANT var);and one client using this function through automation. when debugging the client, the server gets properly loaded and the mfc-dispatchwrappers all do their job well (at the and of F11-ing the client the VARIANT-argument is ok as i constructed it). but when i debug the server, the VARIANT-argument getting in there is crap. moreover: it is different for each debugging-session. as the proper functions get called, i assume, there's everything ok with registring the component and that stuff. is there anything known about this issue? any hints and ideas are greatly appreciated... :| thx. :wqit even doesn't work, when i compile the server as a dll. in that case, everything is running in the same process and i can debug each and every step. just before the server-function is called, there are some fancy stack-creation and inline-assembler thingies in the code. when the function is called then, there's crap on the stack! ah. just found one more: even the return address seems to be corrupt. when i return from the server-function into the mfc-wrapper-code i end up higher than i started! :omg: the result is: the server-function is entered again and afterwards that inline-assembler-code wants to derefence a NULL-pointer. bang! :laugh: maybe there's an error in the VC++.NET implementation of that code? or maybe i have some wrong settings in my project? weird! :~ :wq
-
it even doesn't work, when i compile the server as a dll. in that case, everything is running in the same process and i can debug each and every step. just before the server-function is called, there are some fancy stack-creation and inline-assembler thingies in the code. when the function is called then, there's crap on the stack! ah. just found one more: even the return address seems to be corrupt. when i return from the server-function into the mfc-wrapper-code i end up higher than i started! :omg: the result is: the server-function is entered again and afterwards that inline-assembler-code wants to derefence a NULL-pointer. bang! :laugh: maybe there's an error in the VC++.NET implementation of that code? or maybe i have some wrong settings in my project? weird! :~ :wq
ok. i cross-checked that thing with VS6 and the following turns out: the VS6-client crashes when using the VS.NET server the VS.NET-client crashes when using the VS.NET server the VS6-client works correctly with the VS6 server the VS.NET-client works correctly with the VS6 server so i believe there is a bug in the VS.NET automation-server MFC-implementation when using a VARIANT-parameter. and now? how can i report this. :confused: or maybe i made a mistake somewhere, but i don't know where... :~ :wq