Problem calling OCX
Locked
 
|
I'm trying to call a third party OCX and am running into problems.
I can actually create and call the OCX fine, the problem occurs when I try to exit the application. When I do, I get the error "MyApplication has caused an error in KERNEL32.DLL. MyApplication will now close." I've traced it down to the OCX becuase if I don't call it, then I can exit fine. I've tried calling the OCX from VB (in Excel) and don't experience the problem. ALSO, if I call the OCX from the Dolphin Development environment and then exit the Development environment, everything's fine. It only occurs when I build an exe using the Lagoon Deployment wizard, and then run that exe. I thought that maybe something was being stripped out that shouldn't be, so I unchecked all the deployment wizard options, but still no luck. Any ideas? Thanks. |
|
|
"drtau" <[hidden email]> wrote in message
news:[hidden email]... > I'm trying to call a third party OCX and am running into problems. > I can actually create and call the OCX fine, the problem occurs when > I try to exit the application. When I do, I get the error "MyApplication > has caused an error in KERNEL32.DLL. MyApplication will now close." > > I've traced it down to the OCX becuase if I don't call it, then I can exit fine. > I've tried calling the OCX from VB (in Excel) and don't experience the > problem. ALSO, if I call the OCX from the Dolphin Development environment > and then exit the Development environment, everything's fine. It only occurs > when I build an exe using the Lagoon Deployment wizard, and then run that exe. > I thought that maybe something was being stripped out that shouldn't be, so I > unchecked all the deployment wizard options, but still no luck. > Any ideas? Thanks. > The OCX isn't implemented in Delphi by any chance? The reason I ask is because it seems that there is an issue with Delphi's handling of threads detaching from a DLL implemented with it where the application is multithreaded (like Dolphin). It seems to be something to do with the order in which the threads detach from the DLL. Regards Blair |
|
|
Not sure if it's implemented in Delphi (I'll try to find out from the vendor). Is there
anything I can check from my end to confirm that I am indeed experiencing this threading problem (any sort of test I can perform)? Is there any workaround for this problem? Thanks again Blair. Blair McGlashan wrote: > "drtau" <[hidden email]> wrote in message > news:[hidden email]... > > I'm trying to call a third party OCX and am running into problems. > > I can actually create and call the OCX fine, the problem occurs when > > I try to exit the application. When I do, I get the error "MyApplication > > has caused an error in KERNEL32.DLL. MyApplication will now close." > > > > I've traced it down to the OCX becuase if I don't call it, then I can exit > fine. > > I've tried calling the OCX from VB (in Excel) and don't experience the > > problem. ALSO, if I call the OCX from the Dolphin Development environment > > and then exit the Development environment, everything's fine. It only > occurs > > when I build an exe using the Lagoon Deployment wizard, and then run that > exe. > > I thought that maybe something was being stripped out that shouldn't be, > so I > > unchecked all the deployment wizard options, but still no luck. > > Any ideas? Thanks. > > > > The OCX isn't implemented in Delphi by any chance? > > The reason I ask is because it seems that there is an issue with Delphi's > handling of threads detaching from a DLL implemented with it where the > application is multithreaded (like Dolphin). It seems to be something to do > with the order in which the threads detach from the DLL. > > Regards > > Blair |
|
|
Just wondering ... the OCX we're trying to use is a third party tool that provides
software copy protection for our Dolphin application. Do you guys have any suggestion/recommendation for copy protection software for Dolphin applications? Thanks again. drtau wrote: > Not sure if it's implemented in Delphi (I'll try to find out from the vendor). Is there > anything I can check from my end to confirm that I am indeed experiencing this > threading problem (any sort of test I can perform)? Is there any workaround > for this problem? Thanks again Blair. > > Blair McGlashan wrote: > > > "drtau" <[hidden email]> wrote in message > > news:[hidden email]... > > > I'm trying to call a third party OCX and am running into problems. > > > I can actually create and call the OCX fine, the problem occurs when > > > I try to exit the application. When I do, I get the error "MyApplication > > > has caused an error in KERNEL32.DLL. MyApplication will now close." > > > > > > I've traced it down to the OCX becuase if I don't call it, then I can exit > > fine. > > > I've tried calling the OCX from VB (in Excel) and don't experience the > > > problem. ALSO, if I call the OCX from the Dolphin Development environment > > > and then exit the Development environment, everything's fine. It only > > occurs > > > when I build an exe using the Lagoon Deployment wizard, and then run that > > exe. > > > I thought that maybe something was being stripped out that shouldn't be, > > so I > > > unchecked all the deployment wizard options, but still no luck. > > > Any ideas? Thanks. > > > > > > > The OCX isn't implemented in Delphi by any chance? > > > > The reason I ask is because it seems that there is an issue with Delphi's > > handling of threads detaching from a DLL implemented with it where the > > application is multithreaded (like Dolphin). It seems to be something to do > > with the order in which the threads detach from the DLL. > > > > Regards > > > > Blair |
|
|
Drtau
> Just wondering ... the OCX we're trying to use is a third party tool that provides > software copy protection for our Dolphin application. Do you guys have any > suggestion/recommendation for copy protection software for Dolphin applications? > Thanks again. Try this: http://www.object-arts.com/Lib/Downloads/5.0/ProtectedScribble.zip You'll need this serial number: 1I20E-F7YRW-V4MP2-GHIGOT Dolphin5 includes a fairly simple method for encrypting runtime applications. Protected applications can be unlocked with a serial number in a similar way to the method used for the Dolphin development system. The serial numbers contain an encoded unique ID so that, if one is released to the wide world, you can track down "who dun it". The serial numbers can also tie the execution of the application to a particular machine. BTW, I tried to send you some mail the other day but have received no reply. Is you e-mail address correct in your newsgroup postings? Best Regards, Andy Bower Dolphin Support http://www.object-arts.com --- Are you trying too hard? http://www.object-arts.com/Relax.htm --- -- Best Regards, Andy Bower Dolphin Support http://www.object-arts.com --- Are you trying too hard? http://www.object-arts.com/Relax.htm --- |
|
|
In reply to this post by drtau-4
Checked with the vendor and it IS implemented in Delphi. Is there any way to
work around this? When I call it from the development environment and then exit, there's no error. Can I recreate the same "exit environment" for a deployed executable so I won't get the error? Thanks. drtau wrote: > Not sure if it's implemented in Delphi (I'll try to find out from the vendor). Is there > anything I can check from my end to confirm that I am indeed experiencing this > threading problem (any sort of test I can perform)? Is there any workaround > for this problem? Thanks again Blair. > > Blair McGlashan wrote: > > > "drtau" <[hidden email]> wrote in message > > news:[hidden email]... > > > I'm trying to call a third party OCX and am running into problems. > > > I can actually create and call the OCX fine, the problem occurs when > > > I try to exit the application. When I do, I get the error "MyApplication > > > has caused an error in KERNEL32.DLL. MyApplication will now close." > > > > > > I've traced it down to the OCX becuase if I don't call it, then I can exit > > fine. > > > I've tried calling the OCX from VB (in Excel) and don't experience the > > > problem. ALSO, if I call the OCX from the Dolphin Development environment > > > and then exit the Development environment, everything's fine. It only > > occurs > > > when I build an exe using the Lagoon Deployment wizard, and then run that > > exe. > > > I thought that maybe something was being stripped out that shouldn't be, > > so I > > > unchecked all the deployment wizard options, but still no luck. > > > Any ideas? Thanks. > > > > > > > The OCX isn't implemented in Delphi by any chance? > > > > The reason I ask is because it seems that there is an issue with Delphi's > > handling of threads detaching from a DLL implemented with it where the > > application is multithreaded (like Dolphin). It seems to be something to do > > with the order in which the threads detach from the DLL. > > > > Regards > > > > Blair |
|
|
"drtau" <[hidden email]> wrote in message
news:[hidden email]... > Checked with the vendor and it IS implemented in Delphi. Is there any way to > work around this? When I call it from the development environment and then > exit, there's no error. Can I recreate the same "exit environment" for a deployed > executable so I won't get the error? Thanks. Things you could try: * Add a surpus AddRef() on the component (i.e. an interface leak, but doesn't really matter in a .EXE if a fixed number of instances of the component are created). * Try loading the DLL/OCX as a resource library (ExternalResourceLibrary class>>open:). This may affect when it is unloaded. * Try explicitly unloading the OCX during application shutdown (e.g. when the master window is closed) by (a) #free'ing all refs to the component explicitly, and (b) calling the CoFreeUnusedLibraries() API. * Try searching the newsgroup archives for related postings Regards Blair |
|
|
Blair ... I tip my hat to you ... using
ExternalResourceLibrary class>>open: did the trick! I don't get the Kernel32 error anymore. Thanks so very much! All I did was to add the "ExternalResourceLibrary open: ..." call in the start of my >>main method of my RuntimeSessionManager class and everything seems to work fine. Do I need to add any code to do a corresponding close/shutdown of the ExternalResourceLibrary when my application exits? Will I get into any trouble if I only add the "ExternalResourceLibrary open: ..." statement? Thanks again. Blair McGlashan wrote: > Things you could try: > * Add a surpus AddRef() on the component (i.e. an interface leak, but > doesn't really matter in a .EXE if a fixed number of instances of the > component are created). > * Try loading the DLL/OCX as a resource library (ExternalResourceLibrary > class>>open:). This may affect when it is unloaded. > * Try explicitly unloading the OCX during application shutdown (e.g. > when the master window is closed) by (a) #free'ing all refs to the component > explicitly, and (b) calling the CoFreeUnusedLibraries() API. > * Try searching the newsgroup archives for related postings > > Regards > > Blair |
|
|
"drtau" <[hidden email]> wrote in message
news:[hidden email]... > Blair ... I tip my hat to you ... using > ExternalResourceLibrary class>>open: did the trick! I don't > get the Kernel32 error anymore. Thanks so very much! I thought it might change the way in which Windows sends the detach messages to the DllMain of the DLL when it is unloaded, and it would appear that it does. FWIW I believe there is a bug in the Delphi runtime support library such that it depends on receiving the DLL_THREAD_DETACH/DLL_PROCESS_DETACH in a certain way or order. Tthe order of termination of threads in Dolphin may be somewhat unusual, which is causing Windows to send these detach instructions to the DLL/OCX in an order that it is able to handle. > > All I did was to add the "ExternalResourceLibrary open: ..." call > in the start of my >>main method of my RuntimeSessionManager > class and everything seems to work fine. Do I need to add any > code to do a corresponding close/shutdown of the ExternalResourceLibrary > when my application exits? Will I get into any trouble if I only > add the "ExternalResourceLibrary open: ..." statement? Although it is good practice to release all resources one uses, it is not required in an executable (for a once off library ref. count like this anyway), since the operating system will clear everything up when shutting down the process. Of course this doesn't apply to applications that are loaded by the web applet plugin (or in D5 as DLLs), since these are not cleaned up until the host executable itself shuts down. In this case I would regard it as a bug workaround, and not bother. Regards Blair |
«
Return to Dolphin Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |