Re: Prima::Outlines : a small bug related to event handling ?

I've done some further tests,
it seems the problem does really happens when you use a
Prima::MsgBox::message inside the event handler, otherwise
the behavior is the expected one.

So the best solution is avoid using message dialogs while testing
events, better output stuff on terminal.

-M.

Marco Masetti wrote:
> Hi all,
>
> I'm happily using Prima 1.21 on a Debian (etch) box.
>
> I've just encountered a funny behavior using Prima::StringOutline widget.
>
> The behavior can be reproduced using VB:
>
> 1) insert a Prima::StringOutline widget in the main form
> 2) configure at least one item (items property, right-clicking on
> mouse then...)
> 3) if you run it and play with the items all goes fine, but if you
> 4) define an onSelectItem event callback (just add a call to
> Prima::MsgBox::message to know you have been there...)
> 5) and run it selecting items, now it *seems* working fine, but you
> cannot any more exit the demo mode going back to edit mode, you cannot
> kill the window.
> Moreover this warning:
>
> Use of uninitialized value in numeric eq (==) at <Prima install
> path>/Outlines.pm line 507
>
> should appear on terminal each time you select an entry.
>
> Got it ? If not just stop reading and send a word to me, I'll check
> things better on my side. Otherwise proceed...
>
> This line belongs to the on_mousedown sub, as outlined below.
>
> I've done some tests using the debugger, discovering that, if you
> define a custom onSelectItem event handler, just after running line
> 504 of Prima/Outlines.pm, control pass to the event handler (???),
> then goes back to the set_focused_item sub in the same module and
> finally comes back again to the on_mousedown sub, but now the
> $self->{mouseTransaction} key is undefined (this causing the warning
> at line 507).
>
> At least this happens to me.
>
> Prima/Outlines.pm
> ---------------------------------------------------------------------------------------
>
> sub on_mousedown {
> .....
> 503 $self-> {mouseTransaction} =
> 504 (( $mod & ( km::Alt | ($self-> {multiSelect} ? 0 :
> km::Ctrl))) && $self-> {dragable}) ? 2 : 1;
> 505 $self-> focusedItem( $item >= 0 ? $item : 0);
> 506 $self-> {mouseTransaction} = 1 if $self-> focusedItem < 0;
> 507 if ( $self-> {mouseTransaction} == 2 ) {
> 508 $self-> {dragItem} = $self-> focusedItem;
> 509 $self-> {mousePtr} = $self-> pointer;
> 510 $self-> pointer( cr::Move);
> 511 }
> 512 $self-> capture(1);
> 513 }
> ----------------------------------------------------------------------------------------
>
>
> If I force a value > 0 at $self->{mouseTransaction} just after line
> 505, then control runs smoothly, but widget behavior is not right
> (event handler gets called twice, last outline item being always
> selected at the end of the event handling loop).
>
> If I force $self->{mouseTransaction}=0, event handler gets called
> forever.
>
> On documentation there is only one line on this key, described as a
> semaphore related to Prima::MouseScroller, so I guess that's way I'm
> having this weird behavior.
>
> Any clue ?
>
> -M.
>

-- 
--------------------------------------------------------------------
Ing. Marco Masetti
Project Manager - Research & Innovation
Softeco Sismat S.P.A.		
Via De Marini, 1 - WTC Tower
Tel: (+39) 010 6026.333		    http://www.softeco.it
Fax: (+39) 010 6026.350		    mailto://marco.masetti@softeco.it
---------------------------------------------------------------------