Re: Determine whether window created yet [Was: [lmi] wx segfault iterating on GetChildren()]

[Greg Chicares]

On 2006-3-16 21:18 UTC, Greg Chicares wrote:
> On 2006-3-15 19:04 UTC, Vadim Zeitlin wrote:
>> On Wed, 15 Mar 2006 17:23:41 +0000 Greg Chicares <address@hidden> wrote:
>>
>> GC> Okay. I want to add a variable to a wxDialog-derived class:
>> GC>
>> GC>   /// is_fully_created_: True iff dialog construction has completed and
>> GC>   /// destruction has not yet begun.
>>
>>  This will work but, again, I think it's a bit sloppy to rely on such
>> generic flag. Usually you shouldn't need it and if/when you do there are
>> more often than not better things to test for. In particular in your case I
>> still think that a dynamic Connect() would be a better solution.
>
> I do listen and try to learn, especially when you say the same thing
> twice. I believe the lesson here is that
>
>   int foo()
>   {
>       if(!okay_to_call_foo()) return;
>       ...
>
> isn't as good as never calling foo when it's not okay; and an event
> can't be called before it's connected, so a dynamic Connect() is
> equivalent but more elegant.
[...]
> I've added the dynamic Connect() idea to a to-do list in the source so
> that I won't forget about it. I'm deferring it for now because it's a
> matter of elegance, and I'm giving priority to matters of correctness.

Done. This makes the MVC Controller considerably simpler.

The reason for doing it now is that it also makes it possible to
decouple the View from the Controller. Formerly, this entry
  EVT_UPDATE_UI(XRCID("dialog_containing_notebook"), XmlNotebook::UponUpdateUI)
in a static event table bound the View to the Controller in a
rather inflexible way. Now, code like
    ::Connect
        (this
        ,wxEVT_UPDATE_UI
        ,&XmlNotebook::UponUpdateUI
        ,XRCID("dialog_containing_notebook")
        );
can easily be changed, e.g.,
-         ,XRCID("dialog_containing_notebook")
+         ,XRCID(AbstractView::DialogName())
to allow changing the View dynamically. This happens to make it
possible to add a facility to switch GUI "skins" at runtime, but
that's just one beneficial effect of an improved design. What's
crucial now is that this makes it easier to integrate the 'lmi'
and 'skeleton' trunks.

Thanks again for your advice, Vadim.