PureBasic Forums - English

Hi there,
I'm seeing an issue with dylibs under OSX and the autorelease pool.
I have a program that calls a library I've made with PB that displays various dialogs (not the XML sort), the issue is that the window event handling routines return back to my calling program without draining/popping their autorelease pools completely. Later inside my program it pops it own pool off the stack with then drains the PB pools as well.
When I call the dialogs again, the event wait routines firstly does a NSAutoreleasePool.Release and then allocates a new pool. Since the pools are no longer existing having been drained and popped while in the main program outside the library then the references to them are invalid.
Since pools are meant to be pushed and popped as a pair (ie you shouldn't pop a pool that isn't topmost on the stack) then this is a problem.
Is there any way that I can force PB to release all of its pools at the end of the dylib call before I return back to the caller?
I'm closing the dialog/window with a CloseWindow call but this isn't draining/releasing the pool I can see a whole lot of PB gadgets and so on still in the topmost pool. PB seems to push two pools on the stack.
In other words, the call to the library isn't completely stateless, and the main program has to be able to manage the Autorelease pools without worrying about the stuff left on the stack by PureBasic.
Any help would be appreciated.

Thanks

Fixed or at least bypassed by creating an additional AutoreleasePoolPage list in the C++ code before calling any of the PB dylib procedures. FYI The Apple Objective C runtime stores the current autorelease pool page list in a thread-local slot, which I am replacing temporarily, no doubt it'll break in some future release of OSX but for now it works.

PB GUI functions are not meant to be called from a dylib, but may be you can add a call to WindowEvent() before returning, this the function which clean the pool (and recreate a new empty one).