>
> >
> > I think, subclassing is not enough to stop loosing the FOCUS. (Subclasses
> > can have only replace() method. Others are not virtual)
> >
>
> I think you just have to return non-zero from
> your subclass' handle() when stealing the focus
> back. Like this.
>
> Hope it helps,
> Stan
>
> #include <FL/Fl_Double_Window.H>
> #include <FL/Fl_Input.H>
> #include <FL/Enumerations.H>
> #include <FL/Fl.H>
> #include <cstring>
>
> class RoachHotel : public Fl_Input {
> public:
> RoachHotel(int x, int y, int w, int h, char const* label = 0)
> : Fl_Input(x, y, w, h, label)
> {;}
> int handle(int event)
> {
> if(event == FL_UNFOCUS) {
> if(!ok()) {
> take_focus();
> return 1;
> }
> }
> return Fl_Input::handle(event);
> }
> private:
> bool ok() const
> {
> char const* v = value();
> return !v || std::strcmp(v, "roach");
> }
> };
>
> int main()
> {
> Fl_Double_Window win(300, 300);
> new RoachHotel(100, 100, 100, 20);
> new RoachHotel(100, 120, 100, 20);
> new RoachHotel(100, 140, 100, 20);
> new RoachHotel(100, 160, 100, 20);
> win.end();
> win.show();
> return Fl::run();
> }
> ~
>
Thanks, for your replay
Yes, it works. The problem was calling take_focus twice. (In handle() method
and the callback function).
Sorry , for so much simple mistake :)
On 31 Jul 2007, at 17:38, Cavit Cahit VURAL wrote:
>>
>> I think we need a bit more detail; what happens to cause the input
>> widget to lose the focus in the first place?
>
> User clicks another Input on window or presses the Tab key or ....
> The cause is not important
Well, with respect, I think knowing *why* the input widget lost the
focus in the first place is absolutely the crux of the problem.
You say the focus is lost because the user chose to click on another
input, yet you do not want to allow the focus to move to the widget
the user has selected? That sounds like seriously bad UI design - why
would you want to do that?
If the user *must* enter valid data into an input field before being
allowed to proceed, then would it not be better to have the widgets
callback fire when the user leaves the widget? In the callback, you
can scan whether the input is valid, and if it is not you could
either pop a dialog box warning of the invalid input, or at that
point, from the callback, throw the focus back to the invalid input
widget - rather than trying to throw it back from the handle
method... Any good?
But I do not know exactly what you are trying to do, so I may be
missing the point.
I need a valid data , like a word "roach". If user enters unvalid data, i am
ready to give an error message at callback. But until to leave the Input, he
still can enter , so i need an extra checking just at leaving.
Thanks for your help, but it was a very simple mistake. Sorry :)
Regards
CC Vural
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
