[fltk.commit] [Library] r9784 - branches/branch-1.3/documentation/src
Author: greg.ercolano Date: 2013-01-04 00:15:12 -0800 (Fri, 04 Jan 2013) New Revision: 9784 Log: Added Fl::run() to list of things not to call in child thread.. Modified: branches/branch-1.3/documentation/src/advanced.dox Modified: branches/branch-1.3/documentation/src/advanced.dox === --- branches/branch-1.3/documentation/src/advanced.dox 2012-12-29 15:54:35 UTC (rev 9783) +++ branches/branch-1.3/documentation/src/advanced.dox 2013-01-04 08:15:12 UTC (rev 9784) @@ -84,7 +84,7 @@ widgets derived from Fl_Window, including dialogs, file choosers, subwindows or those using Fl_Gl_Window. -\li Don't call Fl::wait(), Fl::flush() or any +\li Don't call Fl::run(), Fl::wait(), Fl::flush() or any related methods that will handle system messages \li Don't start or cancel timers ___ fltk-commit mailing list fltk-commit@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-commit
Re: [fltk.general] Time out Reentrance on Windows
Devs: shouldn't we add Fl::run() to that short list?
I'd vote yes, though we probably need someone who really understands that
code (Matthias?) to pitch in with an opinion...
Yes, absolutely. Fl::run() is basically: for(;;) { Fl::wait(); }
Done, r9784.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 04.01.2013 03:12, Denton Thomas wrote: Albrecht wrote: It's not perfect, and maybe some of the changes would turn out to be useless... just take it as a base for more own experiments. Thanks for all this, Albrecht. I'll certainly use those immediately. I appreciate it, as this is part of a current project. I'll keep testing re the style/redraw problem. I'm not sure what I'm doing wrong there - the box style changes just didn't appear on screen ... which was odd. I'll check out your patch to see how you've done it. You'll see that I did it by explicitly calling redraw() on the scroll widget (see the notes and the callback). You may need to call the parent's redraw method as well, if you have a frame box time somewhere, so that the redraw doesn't draw the background. As well, I caught a more glaring problem: if Fl::focus() is in a group inside of the Fl_Scroll, then it seems the Fl_Scroll::handle() method is not ever run ... so the focus tracking code can't run. I'll write a general test to make sure it's not my own Fl_Group subclass that's hogging the event chain, though. Oh, yes, that's certainly true. If navigation happens to succeed in a subgroup, then this subgroup does it all. No parent group will notice. You could maybe derive an own Fl_Group class to do this in conjunction with its parent YourScroll class, but this could be a never ending story, unless you know exactly what groups and widgets you need in your special case. In my case I'm using only simple widgets within the scroll and I handle it all in the child widgets, but this is a special case, since all /my/ child widgets are own classes anyway (and inherit from another common class as well - which is not generally recommended to do, but I did ...). Another issue I observed in your test case that I couldn't fix in my tests is this: click on the input field, then use SHIFT/TAB to go backwards into your group. This is not handled by the scroll widget. Go one more back with SHIFT/TAB, then forwards with TAB, and you'll see. Try also to move the scrollbar to scroll the last widget out of the visible area while the focus is on it or on the input widget, then use TAB and/or SHIFT/TAB. That's what I meant when I wrote that there's a problem when the focus leaves the scroll widget and comes back to it. Another small point: you tested that the same widget doesn't scroll if it gets the focus again, e.g. by mouse clicking. So, if you move the scroll area while one widget has the focus to move it partly out of the scroll area, then click on it again, it will stay where it is and doesn't scroll to be fully visible. This could be called a feature though... One last point: in your original test program I could sometimes make the input widget to get a red background. I hope this is fixed with my 2nd patch, but you should check this, if you intend to do something with the previous focus widget to make sure you don't modify a widget outside your scroll group. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 04.01.2013 10:05, Albrecht Schlosser wrote: the scroll widget (see the notes and the callback). You may need to call the parent's redraw method as well, if you have a frame box time somewhere, so that the redraw doesn't draw ... frame box TYPE ... (fingers faster than mind ;-) ) Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
Albrecht wrote:
Oh, yes, that's certainly true. If navigation happens to
succeed in a subgroup, then this subgroup does it all. No
parent group will notice. You could maybe derive an own
Fl_Group class to do this in conjunction with its parent
YourScroll class, but this could be a never ending story,
unless you know exactly what groups and widgets you need
in your special case.
Perhaps this is solve-able after all. New handle() below. I like this version a
bit better, if only because it meets your original suggestion for a simple
solution.
int handle(int event) {
int ret = Fl_Scroll::handle(event);
Fl_Widget* f_new = Fl::focus();
if(f_new (f_new != focus_tracker_) contains(f_new)) {
focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
scroll_to(scroll_to_focus_x_(), scroll_to_focus_y_());
redraw();
}
return ret;
}
I've deleted test_focus_() and scroll_to_focus_() functions as unused kruft.
All the rest remains untouched.
New handle() just checks if focus (1) has moved and (2) is somewhere in the
scroll group. I've done the membership test with contains(), which seems to
return true even if the focus widget is nested. So far, at least.
I found the problem you mentioned re catching key combinations/order,
especially w/ Shift+Tab, etc. If the above works, I can avoid the key problem
altogether by ignoring the event code. Otherwise it may be a bottomless pit of
testing the possible/accepted keycodes for changing focus. I -think- that the
test above will catch any method of changing to the focus widget. I also
-think- it's safe ... but I'll have to test some more.
The main oddity is that I've ditched testing whether the base handle() returned
1. If I rely on that, I can't see nested widgets. Ignoring the value seems
alright, but maybe this does something bad that I haven't caught yet.
Since the placement code seems to be working [knock on wood], I've cut the
color changes / debug. Thanks for identifying how the color change happened to
the input field - I hadn't figured that one out.
I'll post a new test unit when I've got it.
Denton
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 04.01.2013 12:36, Denton Thomas wrote:
Albrecht wrote:
Oh, yes, that's certainly true. If navigation happens to
succeed in a subgroup, then this subgroup does it all. No
parent group will notice. You could maybe derive an own
Fl_Group class to do this in conjunction with its parent
YourScroll class, but this could be a never ending story,
unless you know exactly what groups and widgets you need
in your special case.
Perhaps this is solve-able after all. New handle() below. I like this version
a bit better, if only because it meets your original suggestion for a simple
solution.
Yup, simplicity rocks ;-)
int handle(int event) {
int ret = Fl_Scroll::handle(event);
Fl_Widget* f_new = Fl::focus();
What about adding here:
if (!contains(f_new)) focus_tracker_ = 0; // focus in another group
if(f_new (f_new != focus_tracker_) contains(f_new)) {
focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
scroll_to(scroll_to_focus_x_(), scroll_to_focus_y_());
redraw();
}
return ret;
}
I've deleted test_focus_() and scroll_to_focus_() functions as unused kruft.
All the rest remains untouched.
New handle() just checks if focus (1) has moved and (2) is somewhere in the
scroll group. I've done the membership test with contains(), which seems to
return true even if the focus widget is nested. So far, at least.
That's how contains() is defined, it *should* (and will) find nested
widgets - and the container widget itself as well.
I found the problem you mentioned re catching key combinations/order,
especially w/ Shift+Tab, etc.
This was only a test case and had nothing to do with the keys
pressed per se. I only used it as a means to leave the scroll
group and return easily.
If the above works, I can avoid the key problem altogether by ignoring the
event code. Otherwise it may be a bottomless pit of testing the
possible/accepted keycodes for changing focus. I -think- that the test above
will catch any method of changing to the focus widget. I also -think- it's
safe ... but I'll have to test some more.
There's nothing that could be wrong with it, IMHO. Just comparing
previous focus (or maybe an ancient predecessor if you left the
groupt meanwhile) with current focus can't be wrong.
The main oddity is that I've ditched testing whether the base handle()
returned 1. If I rely on that, I can't see nested widgets. Ignoring the value
seems alright, but maybe this does something bad that I haven't caught yet.
This was probably the reason why leaving the group couldn't be
handled, since this would return 0 from Fl_Scroll's handle() -
which means that the parent group should handle it. However,
then the focus change would also happen after returning from
handle, so this would probably not work either. :-(
One drawback of not testing any event type and/or the return
value would be more CPU time to do your checks all the time,
even if there is an FL_MOVE event. However, maybe *this* is what
triggers your focus checks eventually and makes it all work now.
So, if you want to save some (or more) CPU cycles, I'd recommend
checking what is really needed, and then filter events and/or do
some basic, but simple checks first.
Note that there is FL/names.h with the fl_eventnames[] array that
makes it simple to debug events with something like
printf(event = %3d: %s\n,event,fl_eventnames[event]);
In my tests I usually omit repeating FL_MOVE events, since they
can be annoying. YMMV
Since the placement code seems to be working [knock on wood], I've cut the
color changes / debug. Thanks for identifying how the color change happened
to the input field - I hadn't figured that one out.
You're welcome.
I'll post a new test unit when I've got it.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] RFC: Tracking the focus widget - would this be useful ?
All, I'd like to know if there are more FLTK users who have the need to track the widget that currently has the focus. If this was a common problem, we could probably add something to FLTK to make this easier. It's not easy with current FLTK methods, as can be seen in the current discussion with the title scroll to focus in Fl_Scroll in fltk.general. http://www.fltk.org/newsgroups.php?gfltk.general+Q%22scroll+to+focus+in+Fl_Scroll%22 I could imagine something like a callback that could be called whenever the current focus widget (Fl::focus()) changes. This could be something like: Fl::register_focus[_tracking] (my_widget,callback,arg) to register interest in focus changes. In this case, each focus change would call the callback function like this: void callback (Fl_Widget *w, long or void * arg, Fl_Widget *focus) The last argument is just to avoid calling Fl::focus() each time the callback is called, but could also be removed. The first argument would be the widget (my_widget) the callback was registered for (this could also be NULL, if my_widget was NULL in the call to register_focus[...]. ... or something like that ... Any ideas, comments, wishes ? Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 04.01.2013 12:36, Denton Thomas wrote: New handle() below. I like this version a bit better, if only because it meets your original suggestion for a simple solution. Please see also my RFC in fltk.general: http://www.fltk.org/newsgroups.php?gfltk.general+v:35878 Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
