I have a toolbar button which is only valid when an item is selected.
I disable it initially and then enable it via EVT_TREE_SEL_CHANGED.
However, another button is used to delete items from the tree. When
it changes the selection, via SelectItem(), no event is sent to
disable the button.
What is the proper (reliable, synchronous :-)) way to detect whether
or not any tree items are selected so I can update the button status?
Thanks,
-D
···
--
Do not be afraid of those who kill the body but cannot kill the soul.
Rather be afraid of the One who can destroy both soul and body in hell.
Matthew 10:28
I have a toolbar button which is only valid when an item is selected.
I disable it initially and then enable it via EVT_TREE_SEL_CHANGED.
However, another button is used to delete items from the tree. When
it changes the selection, via SelectItem(), no event is sent to
disable the button.
What is the proper (reliable, synchronous :-)) way to detect whether
or not any tree items are selected so I can update the button status?
Create an event handler for EVT_UPDATE_UI with the ID the same as the button. In that handler do something like this:
This works, at least. Thanks! It does seem a bit heavy-handed,
though, to be checking every time the mouse moves a little. Isn't the
tree supposed to send the separate events anyways? Nonetheless, I
found the above technique to be a simple way of handling all the tool
enabling and disabling and it doesn't seem to noticably affect
performance on my devel system.
-D
···
On Mon, May 12, 2003 at 10:20:57PM -0700, Robin Dunn wrote:
Derrick 'dman' Hudson wrote:
>I have a toolbar button which is only valid when an item is selected.
>I disable it initially and then enable it via EVT_TREE_SEL_CHANGED.
>However, another button is used to delete items from the tree. When
>it changes the selection, via SelectItem(), no event is sent to
>disable the button.
>
>What is the proper (reliable, synchronous :-)) way to detect whether
>or not any tree items are selected so I can update the button status?
>
Create an event handler for EVT_UPDATE_UI with the ID the same as the
button. In that handler do something like this:
> Create an event handler for EVT_UPDATE_UI with the ID the same as the > button. In that handler do something like this:
> > def OnCheckTree(self, evt):
> item = self.tree.GetSelection()
> evt.Enable(item.Ok())
This works, at least. Thanks! It does seem a bit heavy-handed,
though, to be checking every time the mouse moves a little. Isn't the
tree supposed to send the separate events anyways? Nonetheless, I
found the above technique to be a simple way of handling all the tool
enabling and disabling and it doesn't seem to noticably affect
performance on my devel system.
It's happening in idle time, so most of the time it shouldn't be too bad, however if there are lots of items being handled this way in lots of windows, then you may start noticing it. There are some ideas floating around for how to lessen the overhead of update_ui and idle events for later releases so hopefully it should not be an issue in the future.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Actually, this only works on wxGTK. When I test on wxMSW (win2k) the
event handler is never called :-(. Not only that, but
EVT_TREE_SEL_CHANGING doesn't fire on wxGTK which is part of the
solution a developer using win2k came up with.
Why is the event firing so different on the different platforms?
Unless I'm missing something, differing event semantics really hampers
the task of cross-platform development.
TIA,
-D
···
On Mon, May 12, 2003 at 10:20:57PM -0700, Robin Dunn wrote:
Derrick 'dman' Hudson wrote:
>I have a toolbar button which is only valid when an item is selected.
>I disable it initially and then enable it via EVT_TREE_SEL_CHANGED.
>However, another button is used to delete items from the tree. When
>it changes the selection, via SelectItem(), no event is sent to
>disable the button.
>
>What is the proper (reliable, synchronous :-)) way to detect whether
>or not any tree items are selected so I can update the button status?
>
Create an event handler for EVT_UPDATE_UI with the ID the same as the
button. In that handler do something like this:
Actually, this only works on wxGTK. When I test on wxMSW (win2k) the
event handler is never called :-(. Not only that, but
EVT_TREE_SEL_CHANGING doesn't fire on wxGTK which is part of the
solution a developer using win2k came up with.
'coder2000' on #wxwindows identified a solution. I had registered the
event handler with the id of the top frame. It seemed best to react
to an update anywhere to avoid the potential for missing some update
which should cause the button to be changed. However, wxMSW doesn't
fire events when listening on the frame.
I should have thought of this having run into more-or-less the same
problem with a swing app at one time.
Why is the event firing so different on the different platforms?
Unless I'm missing something, differing event semantics really hampers
the task of cross-platform development.
I think this is still an issue hampering cross-platform development.
All (supported) platforms _ought_ to send events at the same times and
ought to work or fail correspondingly. (with the latter I'm
specifically thinking of the ToolBar.Realize() method which isn't
needed on GTK but is on MSW. That wasn't noticed until an MSW
platform was secured for testing)
Thanks for your time.
-D
···
On Wed, May 14, 2003 at 07:47:00PM -0400, Derrick 'dman' Hudson wrote:
--
Like a gold ring in a pig's snout
is a beautiful woman who shows no discretion.
Proverbs 11:22
> Actually, this only works on wxGTK. When I test on wxMSW (win2k) the
> event handler is never called :-(. Not only that, but
> EVT_TREE_SEL_CHANGING doesn't fire on wxGTK which is part of the
> solution a developer using win2k came up with.
'coder2000' on #wxwindows identified a solution. I had registered the
event handler with the id of the top frame. It seemed best to react
to an update anywhere to avoid the potential for missing some update
which should cause the button to be changed. However, wxMSW doesn't
fire events when listening on the frame.
Which event and what does your window hierarchy look like?
> Why is the event firing so different on the different platforms?
> Unless I'm missing something, differing event semantics really hampers
> the task of cross-platform development.
I think this is still an issue hampering cross-platform development.
All (supported) platforms _ought_ to send events at the same times and
That is the cost you pay for using native widgets in a cross platform library. You either end up with minor differences here and there or you have to exclude the functionality on all platforms. If platform A sends the same events in a different order than platform B there is not a whole lot that wxWindows can do to make them be the same, although in most cases it can be made "close enough". Even more difficult is if platform C doesn't send those events at all, or does send ones that have totally different meanings, and so wxWindows has to take the possibly limited info that the platform is giving it and try to synthesize events that simulate the same behaviour that exists on other platforms.
ought to work or fail correspondingly. (with the latter I'm
specifically thinking of the ToolBar.Realize() method which isn't
needed on GTK but is on MSW. That wasn't noticed until an MSW
platform was secured for testing)
Things like this are a little different category, but boil down to the same issues. Sometimes (but not often) things are required to done for some platforms but not others. The methods would be no-ops on the others.
···
On Wed, May 14, 2003 at 07:47:00PM -0400, Derrick 'dman' Hudson wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!