| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]
STR #1804
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Unassigned |
|---|
| Summary: | "MOVE" in handle(int event) broken |
|---|
| Version: | 2.0-current |
|---|
| Created By: | Joe |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| Op System Ubuntu
Compiler gcc
In my handle(int event) routine, ENTER, LEAVE, PUSH, DRAG, RELEASE, work fine, but not MOVE. In r5555 MOVE works fine, and that version is what I continue to use. In r5940 and r5941 it is broken. Hope you can restore it in a later release
jperkins@pixor.com | |
| |
| Move definitively works on those releases as I'm using it.
What widgets are you seeing the problem with? | |
| |
| Move is used to report the position of a mouse over a bitmap of a photograph so that the color values can be reported in a status bar. The structure is:
Group
ScrollGroup
Widget --drawing
method -- handle(event)
PackedGroup -- status bar
The handle(event) method sends new positions of the mouse back to the status bar routines after factoring in the scroll position and magnification. | |
| |
| #4 | spitzak
13:14 Oct 17, 2007 |
| Make sure your handle() method returns non-zero for ENTER.
This is likely the bug, but if it isn't your widget, it may be one of the fltk widgets surrounding it. | |
| |
| Here is my handle routine - which works, but not with current versions:
int Drawing::handle(int event){
switch(event){
case fltk::ENTER: //sent when mouse is in widget
mouse_active=true;
return true; //to get fltk::MOVE & fltk::LEAVE events
case fltk::LEAVE:
mouse_active=false;
fltk::belowmouse();
return true;
case fltk::MOVE:
if(mouse_active){
mouse_x=(int)(fltk::event_x()*de->scaleX());
mouse_y=(int)((h()-1-fltk::event_y())*de->scaleY());
if(de->ShowCenter)
de->find_center(mouse_x, mouse_y);
if(de->ff_line_dir[0].on || de->ff_line_dir[1].on)
de->find_line_direc(mouse_x, mouse_y);
de->set_status_bar();
return true;
}
break;
case fltk::PUSH:{
if(mouse_active){
int button=fltk::event_key();
if(button==1)
de->train_line_start();
return true; //to get fltk::DRAG & fltk::RELEASE events
}
break;
}
case fltk::DRAG:{
if(mouse_active){
mouse_x=(int)(fltk::event_x()*de->scaleX());
mouse_y=(int)((h()-1-fltk::event_y())*de->scaleY());
int button=fltk::event_key();
if(button==1)
de->train_line_drag();
de->set_status_bar();
return true;
}
break;
}
case fltk::RELEASE:{
if(mouse_active){
int button=fltk::event_key(); //same as event_button()
if(button==1){
if(fltk::event_clicks())
de->edit_select();
else{
uint flag=fltk::event_state();
de->train_line_save(flag);
}
}
return true;
}
break;
}
default:
break;
}
return false;
} | |
| |
| MOVE as described works fine for me (I'm using it for the same thing you are).
What's mouse_active? My guess that's your bug.
Also, you are incorrectly returning bools instead of ints in your function (albeit that should be okay, except for warnings). | |
| |
| I wrote this routine several years ago - I do not know what "mouse_active" was for. Taking it out -- and returning ints -- does not change things in r5555, where the code works perfectly. Unfortunately my computer is running a neural net right now that should be finished tomorrow, but since it uses the fltk libs also, I can't try the newer fltk revision until the net train is finished. I may also try compiling the fltk with debug enabled and see if I can tell what the difference is between r5555 and the newer versions as far as MOVE is concerned.
Thanks for your attention to this matter! | |
| |
| Back to it. I tried the revised handle with r5941 - still does not work, as expected. I forgot to mention one fact though - the MOVE does work with r5941 but only in a narrow band along the right and bottom edges of the drawing.
I also did as I said I would, compiled r5555 in debug, broke on my MOVE handler, and discovered the source was in Widget.cxx. Comparing the code with the r5941 version revealed two changes since r5555. Restoring four lines of code from the r5555 version makes everything work fine - (for me anyway, I assume those changes were for a reason. Here are the changes starting at Line 740 of the r5941 Widget.cxx:
if(ret){ //added
// Set belowmouse only if handle() did not set it to some child:
if (!contains(fltk::belowmouse())) fltk::belowmouse(this);
} //added
break;
case LEAVE:
case DND_LEAVE:
clear_flag(HIGHLIGHT);
ret = handle(event);
break;
case DND_ENTER:
case DND_DRAG:
if (!takesevents()) break;
set_flag(HIGHLIGHT);
// figure out correct type of event:
event = (contains(fltk::belowmouse())) ? DND_DRAG : DND_ENTER;
// see if it wants the event:
ret = handle(event);
if(ret){ //added
// Set belowmouse only if handle() did not set it to some child:
if (!contains(fltk::belowmouse())) fltk::belowmouse(this);
} //added
Cheers! | |
| |
| One possible cause is that fltk2 has a bug in the move routine with widgets at the same level.
If you have:
Group
Widget1
Widget2
Widget3 --- move handle here
Widget3 is currently incorrectly getting the fltk::event_x() and fltk::event_y() offset by the position and space used by the previous widgets (widget1 and 2 in the example).
Try printing the values of fltk::event_x()/y() in your move routine. | |
| |
| #10 | Joe
16:36 Oct 18, 2007 |
| Without the "fix" there is nothing coming into the move routine, so no eventx/y. With the fix, the number is displayed (after scaling) in the status bar. It tracks perfectly. It also tracks perfectly with the middle button held down with or without the fix. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
