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.
| Вернуться в корень Архива |