> Short answer: don't do that. In wx API, it's nonsensical to create a
> child before the parent. If you think you have a good reason, you're
> probably mapping from your conceptual model to the UI model wrong.That will take a bit of doing, but I can work around it. I'm passing
the control to a panel that will be it's parent. I can kill off the
panel related arguments in the constructor, rename some others that
might conflict and pass the widget class and it's construction params
instead. The other alternative is to keep passing the widget as a
partial function (taking parent and returning the widget.)
I just don't understand why there's a need to construct the control
before the parent - the convention is to create the parent, and then
create the child, passing it the parent along the way. If the parent
needs to be aware of specific children, then they are normally created
by the parent itself, in it's constructor, rather than by an external.
The implication that I'm getting is that you're trying to "drive" the
UI creation from the outside and you're running into problems because
the parent needs a reference to a specific child. Background in
functional programming, perhaps?
wx is OO in design so you're kinda butting paradigm heads here.
Typically, a parent control is responsible for initializing itself as
well as it's children (although in small or quick & dirty apps you'll
just create everything in order from the top level).
ยทยทยท
On 11/20/06, Dan Eloff <dan.eloff@gmail.com> wrote:
On 11/20/06, Chris Mellon <arkanes@gmail.com> wrote:
-Dan