Miguel, Also please note, you said:
>> If it is called only 1 time as actual xharbour is imperative to call >> OleUninitialize previous to call hb_clsReleaseAll(), Because >> OleUninitialize >> can cause the creation of messages to the control container, which >> can no longer access your variables causing a GPF. >> This makes no sense because NO INSTANCE of any class could exist at this time, because it's *after* all prg variables have been released, and GC completed its work too! So even if we don't releases the classes, the GPF will still exists as your host obviously uses invalid object instance. Ron On Apr 15, 2008, at 12:02 PM, Ron Pinkas wrote: > Miguel, > > We are going in circles, IMO because you didn't to fully review the > information I posted. > > 1. OleUninitialize() should not cause any GPF, if all OLE resources > have been PROPERLY released. > > 2. It's your responsibility to RELEASE [in correct order] all OLE > controls *before* your program QUIT. > > 3. It's your container responsibility to properly, release, and > DETACH all its host interfaces *before* the program QUIT. > > 4. If you have problem with any BUGGY OLE control, which calls your > host even AFTER you detached from it, then you can add an internal > flag so that your host will IGNORE all incoming events, and will NOT > attempt to call PRG. But again there maybe a GPF trap because the C > level Memory allocated for your Host itself should be released at > this point, or you'll have a memory leak. > > 5. If we move OleUninitialize() before the last call to GC, then we > cause a GPF trap for any DESTRUCTOR which uses OLE. > > Ron > > On Apr 15, 2008, at 2:29 AM, Miguel Angel Marchuet wrote: > >> >> OleInitialize() can be called several times with his pair >> OleUninitialize() >> One for each tOleAuto. >> >> It may be called previous of destroy TOleAuto. >> >> If it is called only 1 time as actual xharbour is imperative to call >> OleUninitialize previous to call hb_clsReleaseAll(), Because >> OleUninitialize >> can cause the creation of messages to the control container, which >> can no longer access your variables causing a GPF. >> >> Remember that some activeX are can't be destroyed, and its instance >> persists meanwhile windows is executed, it only need >> to be unlinked of its parent control, Because it uses always the >> same instance. For this types of ActiveX we need to >> translate OleUninitialize to TOLEAUTO. >> >> Such as ActiveX RMCHARTX and others with certain levels of >> protection to be implemented over n times (for example). >> >> So, the decision should be put where its developer OleInitialize >> and OleUninitialize. Or transfer these to the class tOleOuto >> >> Best regards, >> Miguel Angel Marchuet >> >> >> > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save > $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http:// > java.sun.com/javaone > _______________________________________________ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
