In my program I use wxSpin's and a FileBrowserButton. Both type of
controls behave OK on Linux, but they behave diferently on Win32.
wxSpin: if I change the numeric value by editing the text entry and
pressing ENTER, on Linux I get an EVT_SPINCTRL. On Win32 I don't. Why's
that ? Is Linux or Win32 behaving correctly ? What should generate
wxSpin on ENTER ?
FileBrowserButton: on Win32, if I change the text of the control
programatically I get the changeCallback twice; on Linux, I get it only
once. This looks more like a bug on Win32.
I store the file path into a configuration file; when I load the
configuration file, I put the path in the text control of the
FileBrowserButton and then get the changeCallback called twice. I set it
like this when loading the configuration file (configuration is a
wxFileConfig):
self.fileBrowserButton.SetValue(config.Read("SWI File"))
In my program I use wxSpin's and a FileBrowserButton. Both type of
controls behave OK on Linux, but they behave diferently on Win32.
wxSpin: if I change the numeric value by editing the text entry and
pressing ENTER, on Linux I get an EVT_SPINCTRL. On Win32 I don't. Why's
that ? Is Linux or Win32 behaving correctly ? What should generate
wxSpin on ENTER ?
I don't know, you can perhaps ask on wx-users for an answer. BTW, it looks like both platforms send EVT_TEXT when the value is changed by hand in the text ctrl.
FileBrowserButton: on Win32, if I change the text of the control
programatically I get the changeCallback twice; on Linux, I get it only
once. This looks more like a bug on Win32.
Yes it is, but one you have to talk to Microsoft about. The issue is that with different versions of the comctl32.dll there are slightly different behaviours when the value of a text control is changed programatically. Some send the changed message, some don't, so wxWindows always sends it too since it would be better to get it twice rather then not at all. The usual workaround is to check the value of the control, if it is the same as the last time the event fired then don't do anything. If somebody wants to do a ptach for the FileBrowseButton to do this I'll gladly apply it.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Could this be fixed by having wxWindows listen for the changed message,
track some kind of flag, and then refrain from sending the message
itself?
···
On Thursday 24 April 2003 11:18 am, Robin Dunn wrote:
Yes it is, but one you have to talk to Microsoft about. The issue is
that with different versions of the comctl32.dll there are slightly
different behaviours when the value of a text control is changed
programatically. Some send the changed message, some don't, so
wxWindows always sends it too since it would be better to get it
twice rather then not at all. The usual workaround is to check the
value of the control, if it is the same as the last time the event
fired then don't do anything. If somebody wants to do a ptach for
the
FileBrowseButton to do this I'll gladly apply it.
Ionutz Borcoman wrote:
> Hi,
>
> In my program I use wxSpin's and a FileBrowserButton. Both type of
> controls behave OK on Linux, but they behave diferently on Win32.
>
> wxSpin: if I change the numeric value by editing the text entry and
> pressing ENTER, on Linux I get an EVT_SPINCTRL. On Win32 I don't. Why's
> that ? Is Linux or Win32 behaving correctly ? What should generate
> wxSpin on ENTER ?
I don't know, you can perhaps ask on wx-users for an answer. BTW, it
looks like both platforms send EVT_TEXT when the value is changed by
hand in the text ctrl.
Yep, that should work. I didn't try it, but went directly to
EVT_TEXT_ENTER that worked, too. I'm not very sure if this is supposed
to work in the future. It was not documented. Anyway, it would have been
better to have the same behavior on both platforms, aka emit the
EVT_SPINCTRL when the value changed (that includes typing something and
pressing ENTER; pressing ENTER multiple times shouldn't generate
EVT_SPINCTRL unless the value really changed since last ENTER).
> FileBrowserButton: on Win32, if I change the text of the control
> programatically I get the changeCallback twice; on Linux, I get it only
> once. This looks more like a bug on Win32.
Yes it is, but one you have to talk to Microsoft about. The issue is
that with different versions of the comctl32.dll there are slightly
different behaviours when the value of a text control is changed
programatically. Some send the changed message, some don't, so
wxWindows always sends it too since it would be better to get it twice
rather then not at all. The usual workaround is to check the value of
the control, if it is the same as the last time the event fired then
don't do anything. If somebody wants to do a ptach for the
FileBrowseButton to do this I'll gladly apply it.
Having different behaviors on different platforms defeats the purpose of
the library (this is more like an annoyance, as the workaround is
simple, but still ...)
On Thursday 24 April 2003 11:18 am, Robin Dunn wrote:
Yes it is, but one you have to talk to Microsoft about. The issue is
that with different versions of the comctl32.dll there are slightly
different behaviours when the value of a text control is changed
programatically. Some send the changed message, some don't, so
wxWindows always sends it too since it would be better to get it
twice rather then not at all. The usual workaround is to check the
value of the control, if it is the same as the last time the event
fired then don't do anything. If somebody wants to do a ptach for
the
FileBrowseButton to do this I'll gladly apply it.
Could this be fixed by having wxWindows listen for the changed message, track some kind of flag, and then refrain from sending the message itself?
Probably. Patches are welcome.
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!