Just a note to avoid potential confusion -
Wx::NotifyEvent would be useless in this specific case as you need to
process it using $handler->ProcessEvent
Mark
On 25/01/2012 10:00, Mark Dootson wrote:
> 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
_______________________________________________
Padre-dev mailing list
Padre-dev@perlide.org
http://mail.perlide.org/mailman/listinfo/padre-dev
