MouseDown
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 is an excerpt from the
code:
my $widget = Wx::StaticBitmap-new($panel, -1, ... );
Wx::Event::EVT_LEFT_UP( $widget, sub {
$_[1]-ResumePropagation(1);
$_[1]-Skip;
} );
Wx::Event::EVT_LEFT_UP( $panel, \action );
This works w/o problems.
Now I've added EVT_LEFT_DOWN in the same manner:
Wx::Event::EVT_LEFT_DOWN( $widget, sub {
$_[1]-ResumePropagation(1);
$_[1]-Skip;
} );
Wx::Event::EVT_LEFT_DOWN( $panel, \someotheraction );
This works on Linux, but I don't seem to get EVT_DOWN on Windows.
Before investigating this further, does this look familiar to anybody?
-- Johan
Re: MouseDown
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 event handler on to the child
widgets would represent the least changes to your code.
Example below.
Lifted from working code - there my be typo's though.
Hope this helps
#-- in panel constructor
use My::EvtHandler;
...
...
my $widget = Wx::StaticBitmap-new($panel, -1, ... );
My::EvtHandler-new($widget);
my $widget2 = Wx::TextCtrl-new($panel, -1, ... );
My::EvtHandler-new($widget2);
...
EVT_COMMAND($panel, -1, $My::EvtHandler::TRACK_MOUSE_EVENT, \mysub);
#--
package My::EvtHandler;
use strict;
use warnings
use Wx;
use Wx::Event qw( EVT_LEFT_DOWN );
use base qw (Wx::EvtHandler);
our $TRACK_MOUSE_EVENT = Wx::NewEventType;
sub new {
my ($class, $window) = @_;
my $handler = $class-SUPER::new;
$window-PushEventHandler( $handler );
EVT_LEFT_DOWN($window,sub { $handler-OnMouseLD( $window, $_[1] ); });
return $handler;
}
sub OnMouseLD {
my($handler, $window, $event) = @_;
$event-Skip(1);
my $id = $window-GetId;
my $newevent = Wx::CommandEvent-new($TRACK_MOUSE_EVENT, $id);
$window-ProcessEvent($newevent);
}
1;
On 08/02/2011 09:20, Johan Vromans wrote:
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 is an excerpt from the
code:
my $widget = Wx::StaticBitmap-new($panel, -1, ... );
Wx::Event::EVT_LEFT_UP( $widget, sub {
$_[1]-ResumePropagation(1);
$_[1]-Skip;
} );
Wx::Event::EVT_LEFT_UP( $panel, \action );
This works w/o problems.
Now I've added EVT_LEFT_DOWN in the same manner:
Wx::Event::EVT_LEFT_DOWN( $widget, sub {
$_[1]-ResumePropagation(1);
$_[1]-Skip;
} );
Wx::Event::EVT_LEFT_DOWN( $panel, \someotheraction );
This works on Linux, but I don't seem to get EVT_DOWN on Windows.
Before investigating this further, does this look familiar to anybody?
-- Johan
R: MouseDown
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 propagation explicitly. This is an excerpt from the
code:
my $widget = Wx::StaticBitmap-new($panel, -1, ... );
Wx::Event::EVT_LEFT_UP( $widget, sub {
$_[1]-ResumePropagation(1);
$_[1]-Skip;
} );
Wx::Event::EVT_LEFT_UP( $panel, \action );
This works w/o problems.
Now I've added EVT_LEFT_DOWN in the same manner:
Wx::Event::EVT_LEFT_DOWN( $widget, sub {
$_[1]-ResumePropagation(1);
$_[1]-Skip;
} );
Wx::Event::EVT_LEFT_DOWN( $panel, \someotheraction );
This works on Linux, but I don't seem to get EVT_DOWN on Windows.
Before investigating this further, does this look familiar to anybody?
Wx::StaticBitmap and Wx::StaticText are not meant to be active;
actually, I'm surprised that on Windows you get the mouse up events;
if you need a clickable image, it's better to use a Wx::Window directly.
HTH,
Mattia
Re: MouseDown
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 and mouse down events.
Following Mark's suggestions, I've changed the setup to:
$widget = Wx::StaticBitmap-new($panel, -1, ... );
My::EvtHandler-new($widget);
My::EvtHandler-new($panel);
Wx::Event::EVT_COMMAND($panel, -1,
$My::EvtHandler::TRACK_MOUSEUP_EVENT,
sub {
$_[0]-SetBackgroundColour($back);
... } );
Wx::Event::EVT_COMMAND($panel, -1,
$My::EvtHandler::TRACK_MOUSEDOWN_EVENT,
sub {
$_[0]-SetBackgroundColour($flash);
... } );
(My::EvtHandler at end.)
Now the events are fired when the StaticBitmap etc. is clicked, and also
when the click is elsewhere inside the panel.
On Linux, this does what it is supposed to do: it momentarily flashes
the background while the widget/panel is clicked, to provide visual
feedback.
On Windows, this doesn't work. In contrast to my earlier experiments the
events are triggered, but the background doesn't change.
When I change the event subroutines to:
$_[0]-SetBackgroundColour(...);
$_[0]-Layout;
The background changes, but only for the widget, not for the whole
panel. When I print $_[0] is does say Wx::Panel, so it must be the panel
receiving the event and I'd expect the panel to change it's colour.
So apparently, I'm still overlooking something.
Mattia if you need a clickable image, it's better to use a Wx::Window
Mattia directly.
Could you elaborate on that?
Finally, as promised:
snip
package My::EvtHandler;
use strict;
use warnings;
use Wx;
use Wx::Event qw( EVT_LEFT_DOWN EVT_LEFT_UP );
use base qw (Wx::EvtHandler);
our $TRACK_MOUSEUP_EVENT = Wx::NewEventType;
our $TRACK_MOUSEDOWN_EVENT = Wx::NewEventType;
sub new {
my ($class, $window) = @_;
my $handler = $class-SUPER::new;
$window-PushEventHandler( $handler );
EVT_LEFT_DOWN($window,sub { $handler-OnMouse( $window, $_[1] ); });
EVT_LEFT_UP($window,sub { $handler-OnMouse( $window, $_[1] ); });
return $handler;
}
sub OnMouse {
my($handler, $window, $event) = @_;
$event-Skip(1);
my $id = $window-GetId;
my $newevent = Wx::CommandEvent-new(
$event-LeftDown
? $TRACK_MOUSEDOWN_EVENT
: $TRACK_MOUSEUP_EVENT,
$id);
$window-ProcessEvent($newevent);
}
snip
-- Johan
Re: MouseDown
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
Re: MouseDown
[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
Padre: minor l10n inconsistency: Win32 and Mac
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 (though I have not checked). Windows requires a different handling. Does anyone have an idea what to do there? Where does Wx get the information which language to use for its default buttons on Windows? Any suggestion is welcome. Best regards, Z. PS: Sorry for the crossposting. -- MyMediaLite Recommender System Library: http://ismll.de/mymedialite
