On Sat, Nov 15, 2008 at 7:09 PM, Eero Pajarre <[EMAIL PROTECTED]> wrote: > >> To be sure, you cannot create anything you want to outlive the current >> scope with the "local" keyword since it will be GCed. > > It may be that one of things which led to my confusion was that > with GUI objects you can let their "Lua variables" to go out of their scope > if they have been added to an other GUI object. This association is enough > for keeping them alive > > (and actually it appears that a visible frame is not collected, even if its > Lua > variable goes out of scope)
Ahh, there's the rub, all wxWindow derived classes are owned by their parents and the top level windows, like a wxFrame or wxDialog, are are expected to exist until the user explicitly closes them. When you look at the binding files you will see the %delete keyword in the %class declaration for all objects that will be garbage collected. This is the way it has to be to avoid double deletion or no deletion at all. You will also see the very rare cases of the %gc and %ungc tags used to enforce changes in ownership. http://wxlua.sourceforge.net/docs/wxluaref.html > But the fact that the timer is live (creating timer events), will not save it > from GC. We cannot possibly check for all special cases like this where some object might be "active" or not, the code base would balloon to the point of being unmaintainable or incomprehensible. > And of course after I realised that my timer will get collected I was able to > avoid that. It just took some time to realise... My wxLua main program > forces gc_step so often that my timer never had time to trigger, so I > thought that it was not working at all. > > btw. even after some reconsidering I think that the way how it works, > is the correct/better behaviour for timers Good, there are unfortunately a few seemingly oddities like wxWindows from a Lua standpoint, but the bottom line is that I've tried to be consistent with the C++ version. Any object taking or loosing ownership of another in the C++ wxWidgets docs also applies to wxLua and if it didn't your program would crash. The silent failure of your wxTimer is unfortunate, but it is behaving correctly. Regards, John ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
