lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] wxDialog::OnOK() removed from wx


From: Greg Chicares
Subject: Re: [lmi] wxDialog::OnOK() removed from wx
Date: Tue, 10 Oct 2006 00:25:25 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2006-10-3 17:52 UTC, Vadim Zeitlin wrote:
> On Mon, 02 Oct 2006 12:06:57 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> The exact behavior desired in MvcController::UponOK() is:
> GC>  - if validation fails, then do nothing;
> GC>  - else,
> GC>    - first, validate, transfer data, and close the dialog;
> GC>    - then, display the data after the dialog has closed.
> GC> Sorry, I just can't see how to do that without either calling
> GC> wxDialog::OnOK() or writing its (former) body inline.
> 
>  To implement exactly the same behaviour I see only one possibility:
> override the (virtual) wxDialog::EndModal() in MvcController like this:
> 
>       virtual void MvcController::EndModal(int retCode)
>       {
>               wxDialog::EndModal(retCode);
> 
>               if ( retCode == wxID_OK )
>                       ... display results ...
>       }

Thank you. That's exactly what I needed to show me that the
original approach was wrongheaded.

> Also, if MvcController is always used as it's custom for a normal modal
> dialog, i.e. as a local variable inside some function, we could forget
> about overriding anything (except Validate() or TransferDataFromWindow(),
> of course) and simply do the "display results" in MvcController dtor. But I
> don't know if this is appropriate.

I agree. In fact, that's the way wxID_OK is treated in the 'lmi'
trunk. The 'skeleton' trunk wants to be a standalone library
that 'lmi' could link to instead of incorporating its code.
(Eventually, that is.)

Somehow a wxID_OK handler seemed "natural" enough to me, but
overriding EndModal() is plainly unnatural in this case.

>  I didn't make a patch because I don't know which of the above alternatives
> do you prefer or even if you consider them both unacceptable for some
> reason. But please let me know what do you think and I'll make one a.s.a.p.

No need: I've already committed changes to both trunks, so this
impediment to wx-2.7 compatibility should no longer exist.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]