lmi
[Top][All Lists]
Advanced

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

Re: [lmi] [PATCH 1/2] Make InputSequenceEntry friendly to embedding in w


From: Václav Slavík
Subject: Re: [lmi] [PATCH 1/2] Make InputSequenceEntry friendly to embedding in wxDVC.
Date: Tue, 9 Aug 2011 11:16:03 +0200

Hi,

On 8 Aug 2011, at 20:26, Greg Chicares wrote:
> I'd really like to hear the answer, too--AFAICT, TransferDataFromWindow()
> shouldn't be called by wx (or at least by wxmsw) unless an Apply button
> is pressed or AcceptAndClose() is called.

The answer lies in LMI's MvcController::UponUpdateUI(), which is called at idle 
time and calls TransferDataFromWindow():

        lmi_wx.exe!wxWindowBase::TransferDataFromWindow()  Line 1982 + 0x12 
bytes       C++
>       lmi_wx.exe!MvcController::UponUpdateUI(wxUpdateUIEvent & event={...})  
> Line 801 + 0x12 bytes    C++
        lmi_wx.exe!wxAppConsoleBase::HandleEvent(wxEvtHandler * 
handler=0x0012cb50, void (wxEvent &)* func=0x0040813e, wxEvent & event={...})  
Line 591 + 0xf bytes     C++

Here's the relevant part of the code:

    // Exit immediately if nothing changed. The library calls this
    // function continually in idle time, and it's pointless to fret
    // over inputs that didn't change on this update because they've
    // already been handled. Complex processing of many inputs has
    // been observed to consume excessive CPU time when a malloc
    // debugger is running, so this optimization is significant.
    //
    // The early-exit condition cannot succeed until Assimilate() has
    // been called: therefore, Assimilate() is guaranteed to be called
    // here by the time the user can interact with the GUI.
    TransferDataFromWindow();

That also explains (but doesn't excuse) why I didn't notice this bug -- I must 
have tested it only with inline editing in CensusView, where my focus was.

I already mentioned one quick fix. Another would be to modify 
wxWindow::TransferDataFromWindow() so that it does *not* recursively descend 
into child *toplevel* windows, as it does now. That's the cause of this bug and 
I think it doesn't make much sense: I expect wxDialog::TransferDataFromWindow() 
to get everything from the dialog, but not from other toplevel windows that 
this one is transient for.

Regards,
Vaclav


reply via email to

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