kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hi Sylwester,

Please keep in mind that wxUpdateUIEvents are generated in response to
wxCommandEvents which are typically generated by menu, toolbars, and
buttons.  Other control events will not fire a wxUpdateUIEvent so using
them will have no affect for things like checking a wxCheckBox control
or selecting an item in a list control.  Of course you could manually
send a wxCommandEvent to trigger an wxUpdateUIEvent but this is
overkill.  If you have a control in a dialog that needs to be disabled,
do that in the event handler for the control that determines the state
of the other control.  In your case, you should just call the function
that sets the dialog control states from TransferDataToWindow()
directly.  I cannot stress enough that you understand how event handling
works in wxWidgets.  If you have to, dig around in the wxWidgets code.
This is what I do when the wxWidgets documentation is lacking.

Cheers,

Wayne

On 10/12/19 5:08 AM, Sylwester Kocjan wrote:
> Hi Wayne,
> 
> In the light of below finding, is this review comment still valid?
> It belonged to my changes for initial conditions[1].
> 
> Dnia 27 czerwca 2019 21:04 Wayne Stambaugh <stambaughw@xxxxxxxxx>
> napisał(a):
>> Get rid of DIALOG_SIM_SETTINGS::disableCtrlOnCheckboxEvent() and use  the
>> appropriate wxUpdateUIEvent[1] handler to enable and/or disable any
>> controls.  Manually doing this will almost certainly lead to broken
>> control states.  We have done this poorly so many times in the past that
>> I am not allowing it in new code.
> 
> As I understand wxUpdateUIEvent is useful for scenarios like this or
> similar:
>> 1. Application wants to connect to target hardware.
>> 2. State of hardware changes - application updates status on GUI.
>> 3. Connectivity is lost - some functions on GUI become grayed.
> Thanks to wxUpdateUIEvent GUI update can be processed separate from
> application logic.
> 
> When we want to change state of controls depending on other controls
> we can use simply event handlers. The same logic can be applied to the
> multiple events or multiple controls, like in dialog_spice_model_base.fbp,
> field m_modelName, events OnCombobox and OnText.
> 
> Best regards,
> Sylwester
> 
> [1]:
> https://github.com/skocjan/kicad_initialconditions/tree/Sim_InitialConditions_SK
> 
> 
> On 18/09/2019 22:01, Wayne Stambaugh wrote:
>> Given the recent rash of odd dialog UI behavior, I did some digging and
>> it appears that we might be abusing wxUpdateUIEvent[1].  This event
>> handler was specifically designed for updating controls that respond to
>> command events such as menus, toolbars, buttons, etc.  Using them for
>> anything else is risky.  I would avoid using UI control object calls
>> inside a wxUpdaetUIEvent handler other than those provided by the
>> wxUpdateUIEvent object itself.  I'm pretty sure making changes to a
>> control inside a wxUpdateUIEvent handler can spawn an event loop where
>> the changes made to the control generate a new wxUpdateUIEvent.  A
>> better solution might be to use wxIdleEvent to do any dialog control
>> post processing as a one shot.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]:
>> https://docs.wxwidgets.org/3.0/classwx_update_u_i_event.html#aa25df58e7047f819f5dd0520eb2cc8ea
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp