On Tue, Nov 3, 2009 at 6:16 AM, John Labenski <jlaben...@gmail.com> wrote: > On Mon, Nov 2, 2009 at 5:12 PM, Mateusz Czaplinski <czapko...@gmail.com> > wrote: >> Hi, >> I'm having troubles with the following reduced sample program. When I >> [...] > > Top level windows such as wxFrames and wxDialogs do not require a > parent, but ALL child windows absolutely must have a parent window at > creation in order to set up the window hierarchy even if you plan to > reparent it. This is a requirement of wxWidgets. Some windows allow > for a two-step creation where you call the default constructor, > wxWindow(), and then call myWindow:Create(parent, id...), but this is > not particularly useful in a scripting language.
Ah, that makes it clear, thanks very much! I didn't manage to find any info on the Internet, and unfortunately I often have trouble when I try to find anything in the wxWidgets docs (actually, now I sometimes use the wxLua reference as a base in wxWidgets research...). Hope that some day they get it better... >> I'm in strong need to use Reparent(), as I'd like to create widgets >> first, and add them to the layout & proper parent later. In more > > The creation of windows is pretty fast and I would not bother to try > to create windows ahead of time, but rather store the layout and > creation code in a Lua table and call it as appropriate. Don't forget > to use wxWindow::Destroy() to delete the topmost old one and it will > take care of its children. On the other hand if you are creating > wxListCtrls with many items, that might be slowish and in that case I > would create the window and immediately call Show(false) to hide it. > Finally, you cannot reparent between top level windows if I remember > correctly. "Topmost old one"? Um, I'm not sure what you mean by that (unless you're referring to The Great Cthulhu ;P). But the idea of storing the widgets creation code as closures sounds very nice, might let me leave the code where it is, yet still postpone its realisation until I have the parent window - thanks for the idea, I didn't think of that. >> general terms, I'm setting up some classes and methods which would >> make it easier to use wxLua, in an IUP-like way. I intend to share > > Sounds interesting, I don't know much about IUP, but I would be > hesitant to try to force wxWidgets to behave like another toolkit. > It's much easier to swim with a stream than against it. There's not going to be much forcing, rather wrapping wxWidgets objects construction in (hopefully) simpler, more intuitive and more Lua-tonic structures, with the underlying widgets available in the ".wx" field whenever possible. But I don't want to do much advertising; should I succeed, I'll show it; should I fail, then I think there's no need to waste words now :) Greetz Mateusz Czaplinski ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
