Hi,
I have an application that displays a panel, and the panel contains a
widget (bitmap). It's a touchscreen application, so the whole
panel is sensitive to being clicked (touched).
Apparently command events are not propagated from a widget to its
parent, so I force propagation explicitly. This
Hi,
Command Events are propagated to parent windows. EVT_LEFT_DOWN is not a
Command Event.
I have come across the issue of different mouse event behaviour across
operating systems before.
Assuming that what you want to catch in the panel is any user
interaction at all, I think pushing an
Da: jvrom...@squirrel.nl
Hi,
I have an application that displays a panel, and the panel contains a
widget (bitmap). It's a touchscreen application, so the whole
panel is sensitive to being clicked (touched).
Apparently command events are not propagated from a widget to its
parent, so I force
mattia.bar...@libero.it mattia.bar...@libero.it writes:
Wx::StaticBitmap and Wx::StaticText are not meant to be active;
actually, I'm surprised that on Windows you get the mouse up events;
When playing with Mark's suggestions I noticed that StaticText and
StaticBitmap get both the mouse up
Hi
On 08/02/2011 13:21, Johan Vromans wrote:
When I change the event subroutines to:
$_[0]-SetBackgroundColour(...);
$_[0]-Layout;
does changing the event subroutines to
$_[0]-SetBackgroundColour(...);
$_[0]-Refresh;
$_[0]-Update;
fix things?
Regards
Mark
[Quoting Mark Dootson, on February 8 2011, 13:37, in Re: MouseDown]
does changing the event subroutines to
$_[0]-SetBackgroundColour(...);
$_[0]-Refresh;
$_[0]-Update;
fix things?
YES! In fact, the Refresh is sufficient.
Thanks a lot!
-- Johan
Hi all,
I fixed (for Unix) a small issue with Padre that leads to the display
of the OK button and other things in the system/user language instead
of Padre's interface language.
The fix is here: http://padre.perlide.org/trac/changeset/13636
I guess this should also solve the issue on Mac OS X
