Hi,

As an alternative approach, you may wish to just add events to the Wx 
event queue. It is a handy way to return from an event handler and 
process something later.

.................................

our $OPENFILE_ID = Wx::NewEventID;

..................................

sub OnTreeItemActivated {
   .....
   my $newevent = Wx::CommandEvent->new($OPENFILE_ID, $treectrl->GetId);
   $newevent->SetString('path to file');

   $somehandler->AddPendingEvent($newevent);

}

... in Some Handler .....

   EVT_COMMAND($somehandler, -1, $OPENFILE_ID, &OnEvtOpenFile);

sub OnEvtOpenFile {
    ......

    my $filepath = $event->GetString;
    .. open file and set focus

    $event->Skip(0);


Using this approach you can also utilise Wx::NotifyEvent which allows a 
veto in the handler if the occasion requires.

Command events get propagated up the window hierarchy so assuming you 
have some custom TreeCtrl you would probably create events in that and 
handle in the containing frame / panel.

e.g.

.. within TreeCtrl
my $newevent = Wx::CommandEvent->new($OPENFILE_ID, $self->GetId);
$newevent->SetString('path to file');
$self->AddPendingEvent($newevent);

.. within containing Frame / panel

EVT_COMMAND($self, $treectrl, $OPENFILE_ID, &OnEvtOpenFile);


Hope it helps.

Mark



On 25/01/2012 00:18, Adam Kennedy wrote:
> Hi gang
>
> This is mostly a heads up for anyone hacking on Padre anywhere we use
> a Wx::TreeCtrl object.
>
> There appears to be some kind of subtle bug in Wx which causes a bunch
> of code to not like it is supposed to.
>
> If you have bound events for EVT_TREE_ITEM_ACTIVATED, then no matter
> what you will also get a spurious additional event firing after it,
> that event being (for some reason) EVT_LEFT_UP.
>
> This is a bit weird, since EVT_LEFT_UP doesn't actually fire when it
> normally should.
>
> The result of the spurious EVT_LEFT_UP is that you cannot make the
> focus leave the item being clicked.
>
> If you do, the EVT_LEFT_UP will act as a focus grab and pull focus
> back to the tree. One workaround to this in the FindInFiles handler
> was to then bind EVT_IDLE and focus back to the editor it had just
> opened.
>
> This really sucks though, because the focus bounces back and forth
> twice, spawning double the syntax check and vcs tasks and causing mild
> task overloading.
>
> The idea of delaying the handler till EVT_IDLE is a good one though,
> but since it's a one off fix and involves unbinding EVT_IDLE at the
> end this would clash with any other idle-time functionality we want to
> add for objects.
>
> So instead of hard-coding in EVT_IDLE hooks I'm going to be working on
> a Padre::Wx::Role::Idle over the next few days.
>
> The idea will be that you get a set of idle_* method that let you
> delay arbitrary calls until idle time by something like
>
> idle_call( 'method_name', 'param', ... )
>
> The idle role will track a queue of things to do at idle time, and
> then bind/unbind the idle handler whenever that queue goes empty or
> non-empty.
>
> This is definitely something I want fixed before the next release, as
> it's breaking all three tree objects that open files (directory tree,
> found in files, changed in files) and prevents the use of any tree
> control that results in a change of focus.
>
> Adam
> _______________________________________________
> Padre-dev mailing list
> Padre-dev@perlide.org
> http://mail.perlide.org/mailman/listinfo/padre-dev

_______________________________________________
Padre-dev mailing list
Padre-dev@perlide.org
http://mail.perlide.org/mailman/listinfo/padre-dev

Reply via email to