Re: [fltk.general] RFC: Tracking the focus widget - would this be useful ?

2013-01-06 Thread Greg Ercolano
On 01/04/13 05:22, Albrecht Schlosser wrote: > I'd like to know if there are more FLTK users who have the need > to track the widget that currently has the focus. I wouldn't be against it.. sounds reasonable. > I could imagine something like a callback that could be called > whenever the

Re: [fltk.general] scroll to focus in Fl_Scroll

2013-01-06 Thread Albrecht Schlosser
On 05.01.2013 23:01, Denton Thomas wrote: > Albrecht wrote: > >> 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_t

Re: [fltk.general] RFC: Tracking the focus widget - would this be useful ?

2013-01-06 Thread Albrecht Schlosser
On 06.01.2013 09:01, Greg Ercolano wrote: > On 01/04/13 05:22, Albrecht Schlosser wrote: >> I'd like to know if there are more FLTK users who have the need >> to track the widget that currently has the focus. > > I wouldn't be against it.. sounds reasonable. > >> I could imagine something lik

Re: [fltk.general] Mac OS: crash in lockFocus

2013-01-06 Thread Manolo Gouy
> Again thank you for your answers. I did not expect to receive so fast a > response, which is in par with the quality of your tools. > > However, I have eventually discovered what was wrong. When I load a FLTK > window, then a window of my own (within my COCOA application), then again a > FLTK

Re: [fltk.general] scroll to focus in Fl_Scroll

2013-01-06 Thread Denton Thomas
> No, sorry for being unclear. It's solely to detect that the current > focus_tracker_ variable value is invalid. This would enable you to > see when the current focus widget (inside your group) loses focus > and gets it again. Otherwise you wouldn't scroll the widget back > into the visible area i