Lost mouse button down event with multi-selection wxMSW tree control
Patrick Hartling
wxEVT_LEFT_DOWN events if the click is within the item icon area and
changes the icon based on state information. If I use multi-selection
with the wxMSW version of wxTreeCtrl, however, the tree item has to be
selected for the button down event to be received by my tree control
instances. That means that I always have to click the tree items
twice--but not so fast as to cause a double-click to be generated. I
have tested with wxMac and wxGTK as well, and this behavior only
occurs with wxMSW when multi-selection is enabled for tree controls.
Should I consider this a bug in wxWidgets 2.6.x, or is it a necessary
side effect of the way that multi-selection is emulated by the wxMSW
version of wxTreeCtrl? If it is a bug, can it be fixed as easily as
modifying line 2389 of src/msw/treectrl.cpp (from the 2.6.3 RC1
source) so that it does not set processed to true? I have not yet
tried this, but I will as soon as I get back to my Windows machine. If
it is a necessary side effect, does anyone have a recommendation about
how I might work around this need for clicking twice? Perhaps I could
handle wxEVT_LEFT_UP events and validate that the icon is in the
correct state?
-Patrick
--
Patrick L. Hartling
http://www.137.org/patrick/
---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-u...@lists.wxwidgets.org
For additional commands, e-mail: wx-use...@lists.wxwidgets.org
Vadim Zeitlin
PH> Should I consider this a bug in wxWidgets 2.6.x, or is it a necessary
PH> side effect of the way that multi-selection is emulated by the wxMSW
PH> version of wxTreeCtrl?
It is most likely the side effect of the current implementation but I
doubt it is necessary. We probably should generate a wxMouseEvent first and
then only select/unselect the item if the event wasn't handled by the user
code.
PH> If it is a bug, can it be fixed as easily as modifying line 2389 of
PH> src/msw/treectrl.cpp (from the 2.6.3 RC1 source) so that it does not
PH> set processed to true? I have not yet tried this, but I will as soon as
PH> I get back to my Windows machine.
I don't think this is a correct fix, it would result in an item being both
selected and its icon changed -- this probably wouldn't feel right for the
user. Instead I think we need to do what I described above, i.e. call the
base class MSWWindowProc() first and only execute wxTreeCtrl-specific code
if the event wasn't handled.
If you could make a patch implementing this, it would definitely be much
appreciated.
Thanks in advance,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Patrick Hartling
> On Mon, 20 Feb 2006 19:44:54 -0600 Patrick Hartling <patrick....@gmail.com> wrote:
>
> PH> Should I consider this a bug in wxWidgets 2.6.x, or is it a necessary
> PH> side effect of the way that multi-selection is emulated by the wxMSW
> PH> version of wxTreeCtrl?
>
> It is most likely the side effect of the current implementation but I
> doubt it is necessary. We probably should generate a wxMouseEvent first and
> then only select/unselect the item if the event wasn't handled by the user
> code.
I had not thought of doing it this way. That is an interesting idea.
> PH> If it is a bug, can it be fixed as easily as modifying line 2389 of
> PH> src/msw/treectrl.cpp (from the 2.6.3 RC1 source) so that it does not
> PH> set processed to true? I have not yet tried this, but I will as soon as
> PH> I get back to my Windows machine.
>
> I don't think this is a correct fix, it would result in an item being both
> selected and its icon changed -- this probably wouldn't feel right for the
> user.
This is how single selection wxTreeCtrl instances behave with wxMSW.
Should it be changed in both?
> Instead I think we need to do what I described above, i.e. call the
> base class MSWWindowProc() first and only execute wxTreeCtrl-specific code
> if the event wasn't handled.
>
> If you could make a patch implementing this, it would definitely be much
> appreciated.
I will see what I can do. It may take me a while as the priority of
this has decreased recently.
-Patrick
--
Patrick L. Hartling
http://www.137.org/patrick/
---------------------------------------------------------------------
Vadim Zeitlin
PH> On 2/27/06, Vadim Zeitlin <va...@wxwindows.org> wrote:
PH> > I don't think this is a correct fix, it would result in an item being both
PH> > selected and its icon changed -- this probably wouldn't feel right for the
PH> > user.
PH>
PH> This is how single selection wxTreeCtrl instances behave with wxMSW.
PH> Should it be changed in both?
To be honest I don't know, I'm not sure what would be the more usual
behaviour. Ideally we'd find a few other applications with similar
functionality and see how do they behave.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/