CDispatchDriver::CreateDispatch() fails 50% of time
Alexander Walsh -- sandy@andyne.com
Tuesday, October 08, 1996
Environment: VC 4.1, Win 95, Win32s, NT 3.51, NT 4.0
Hey folks ... here's a little challenging one for ya all.
We do a CreateDispatch from MFC's CDispatchDriver class ... passing it a
ProgID like "Excel.App.1" (for example, actually it's another of our
apps).
50% of the time this works fine. The other 50% of the time, it returns
from the call immediately. It's like the lookup in the registry failed.
We get a "OLE service could not communicate with the object server"
almost immediately. It doesn't matter if the server (another .EXE) is
running already or not. This is especially odd since the classfactory
gets registered when the second (server) exe gets run separately.
This happens on '95, NT3.51, Win32s even NT40 (ha, no surprise). Note
that we are using 4.1 and *not* 4.2 since we want to go to Win32s.
We may have solved the problem by reissuing the request every 1/2 second
for up to 10 times. But this seems like a terrible kludge. If this
*doesn't* work, then the user is just going to get a delay before it
fails ... to add insult to injury.
Should we be locking the OLE client before we try and fire the other EXE
up or something that MFC isn't doing for us??
PULLEEEZZE HELP!
Thanx,
Sandy
--
----
Alexander (Sandy) Walsh | I hope I die peacefully in my sleep
Project Lead - Common Report | like my Dad ... and not screaming
Andyne Computing Ltd | hysterically like his passengers.
Mike Blaszczak -- mikeblas@nwlink.com
Wednesday, October 09, 1996
At 05:21 10/8/96 -0400, you wrote:
>Environment: VC 4.1, Win 95, Win32s, NT 3.51, NT 4.0
>We do a CreateDispatch from MFC's CDispatchDriver class ... passing it a
>ProgID like "Excel.App.1" (for example, actually it's another of our
>apps).
What goes on in the class factory of your app?
>50% of the time this works fine. The other 50% of the time, it returns
>from the call immediately.
How is this success and failure distributed? If you call ten times in a
row, in a loop, do you fail five times and succeed five times? Will you
always succeed after the first successful call?
>It's like the lookup in the registry failed.
Lookups in the registry don't sometimes fail and sometimes suceeed.
Either what you need is there or it isn't.
>We get a "OLE service could not communicate with the object server"
>almost immediately.
Is that a message box, a trace message to the debugger, or the descriptive
text attached to a COleException? Which call, exactly, fails when you
trace into the CreateDispatch() implementation?
.B ekiM
http://www.nwlink.com/~mikeblas/
Don't look at my hands: look at my _shoulders_!
These words are my own. I do not speak on behalf of Microsoft.
Alexander Walsh -- sandy@andyne.com
Tuesday, October 15, 1996
Hey Mike,
>>We do a CreateDispatch from MFC's CDispatchDriver class ... passing it a
>>ProgID like "Excel.App.1" (for example, actually it's another of our
>>apps).
> What goes on in the class factory of your app?
It's the standard MFC class factory definition:
IMPLEMENT_OLECREATE(ARCAutoApp, "CommonReport.Application", 0x889e4aa3,
0x24d7, 0x11cf, 0xbe, 0x85, 0x0, 0x20, 0xaf, 0x23, 0x2a, 0x25)
IMPLEMENT_DYNCREATE(ARCAutoApp, CCmdTarget);
Note that this is our own OLE automation App object, instead of exposing
the CWinApp object directly.
>>50% of the time this works fine. The other 50% of the time, it returns
>>from the call immediately.
> How is this success and failure distributed? If you call ten times in a
> row, in a loop, do you fail five times and succeed five times? Will you
> always succeed after the first successful call?
Very good question ... it's hard to tell since the symptom is spuratic.
However, it *is* easy for us to put a little code in to display the
attempt that succeeded. I'll check that on our side.
>>It's like the lookup in the registry failed.
> Lookups in the registry don't sometimes fail and sometimes suceeed.
> Either what you need is there or it isn't.
Agreed.
>>We get a "OLE service could not communicate with the object server"
>>almost immediately.
> Is that a message box, a trace message to the debugger, or the descriptive
> text attached to a COleException? Which call, exactly, fails when you
> trace into the CreateDispatch() implementation?
It's the descriptive text associated with COleException, we just pop it
up in an AfxMessageBox().
Again, stepping into the code to see when it fails is hard as it is
spuratic. I'm sure, however, that once we get the code in to display the
retry attempt it'll be easy to put a breakpoint in a meaningful location
at a meaningful time.
Actually, this retry thing *has* solved the problem ... it's just
really odd that it occurs anyway, and I don't like the kludgey solution.
Thanx for your reply,
Sandy
--
----
Alexander (Sandy) Walsh | I hope I die peacefully in my sleep
Project Lead - GQL Reports | like my Dad ... and not screaming
Andyne Computing Ltd | hysterically like his passengers.
| Вернуться в корень Архива
|