Re: [fltk.general] fl_alert
On Wed, 13 Mar 2013 16:54:56 -0700, Greg Ercolano wrote: > BTW, does the FLTK test program "message" work for you? > If you recently built FLTK, run it.. the second dialog > (which starts with "Quantum fluctuations") uses fl_alert() > with %g as part of its format string. Yes it does. And today so does my instance of fl_alert. Windows reboot? The total program clean and rebuild (not the first time that I have cured funnies with a rebuild)? Sorry for the bother. Cheers Richard ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_alert
On 03/13/13 15:06, Greg Ercolano wrote: > On 03/13/13 14:35, Richard Sanders wrote: >> fl_alert seems to crash when supplied with a format field and the >> required parameters. I used the exact same as sprintf (that does not >> crash). This is for win64 and mingw64 with FLTK-1.3.2 (all compiled 64 >> bit). I have not tried in Linux or win32. >> >> This is not really bothersome because passing the sprintf pre >> formatted string works. >> >> Is this a coding bug or a document bug that needs to be fixed. > > Can we see some example code that crashes? > BTW, does the FLTK test program "message" work for you? If you recently built FLTK, run it.. the second dialog (which starts with "Quantum fluctuations") uses fl_alert() with %g as part of its format string. FWIW the following works OK with 1.3.2 on linux: #include #include #include int main(int argc, char* argv[]) { int i = 12; float f = 34.56; const char *s = "hello world"; fl_alert("Testing an int(%d) a float (%.2f) and a string (%s)",i,f,s); return Fl::run(); } ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_alert
On 03/13/13 14:35, Richard Sanders wrote: > fl_alert seems to crash when supplied with a format field and the > required parameters. I used the exact same as sprintf (that does not > crash). This is for win64 and mingw64 with FLTK-1.3.2 (all compiled 64 > bit). I have not tried in Linux or win32. > > This is not really bothersome because passing the sprintf pre > formatted string works. > > Is this a coding bug or a document bug that needs to be fixed. Can we see some example code that crashes? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] fl_alert
fl_alert seems to crash when supplied with a format field and the required parameters. I used the exact same as sprintf (that does not crash). This is for win64 and mingw64 with FLTK-1.3.2 (all compiled 64 bit). I have not tried in Linux or win32. This is not really bothersome because passing the sprintf pre formatted string works. Is this a coding bug or a document bug that needs to be fixed. Cheers Richard ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_alert() closes immediately
N. Cassetta wrote: > Thanks for immediate replies. Effectively, the easier way to patch it is > adding the when(FL_WHEN_NEVER). > I am happy because it was not an error of mine ;-) I'm glad that I could help. This issue is now fixed in the subversion repository for 1.1.10 (and 1.3.0) and will be in the next release candidate or the final release (and 1.3.0 snapshot). BTW: Thanks for the excellent testcase and problem description including FLTK version and platform. With this it was easy to reproduce and fix the problem. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_alert() closes immediately
Thanks for immediate replies. Effectively, the easier way to patch it is adding the when(FL_WHEN_NEVER). I am happy because it was not an error of mine ;-) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_alert() closes immediately
Albrecht Schlosser wrote: > Please see the attached diff file for FLTK 1.1.9 and try if > it solves your problem. BTW.: If you want a fast solution with FLTK 1.1.9 without patching the sources, you can also assign an empty callback (one that does nothing, but it must be assigned, not NULL) to your number buttons, or you can use Btnum[c]->when(FL_WHEN_NEVER); to disable the callback. I just tested the latter, and it works as expected. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_alert() closes immediately
Matthias Melcher wrote: > On 22.12.2009, at 07:36, N. Cassetta wrote: > >> Here's a (minimal) implementation of my problem. When I click the lower >> button, fl_alert() appears and suddenly closes as if a mouse click was still >> pending. > > MyBox::handle does not take care of mouse release events, so instead they are > sent to whatever other widget may take them, in this case the alert. No, sorry, the fl_alert() window pops up *after* the first window is deleted. Please take a look at my other reply. I'd like to apply this simple fix to 1.1.10 and 1.3.0 as a solution that fixes the _symptoms_ _properly_. The problem of pending callbacks in the Fl::readqueue() should probably be addressed differently. I'm thinking of scanning the queue and removing entries when deleting a widget in its destructor... Matthias, do you agree with this fix in 1.1.10, or should we maybe file an STR? If you agree, I'll do it later today... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_alert() closes immediately
N. Cassetta wrote: Here's a (minimal) implementation of my problem. When I click the lower button, fl_alert() appears and suddenly closes as if a mouse click was still pending. I use FLTK 1.1.9 with CodeBlocks (MinGW)and WinXP. Yes, it's true. You described *exactly* what's happening! Confirmed on Windows with FLTK 1.1.9, 1.1.10, and 1.3.0. In my configuration the number of "sudden death's" of the alert window depends on the number of clicks on the buttons labeled with 2,3,4, and 5, no matter of how often the other buttons are clicked. It doesn't happen at all, if you click the "Then here" button before the "First click here" button. The explanation of this effect is somewhat special ;-P The fact is that your number buttons don't have callbacks, and thus their events get queued in the internal queue of events for widgets without a callback. And this is the event queue that is used to read the events for the buttons in fl_alert() etc. Now, what's happening in your special case is that you delete the widgets before the alert window is created and shows for the first time, and therefore the button(s) internally used in fl_alert() and others get the *same* addresses as your previously deleted buttons. Then fl_alert() reads *their* events and mis-interprets them. The solution is easy, however: I just made a small test with fltk 1.1.10 by reading the event queue before popping up the fl_alert() window, and this solved the problem. Maybe we should use this to fix the problem in 1.1.10, but a long term solution would probably be different. Please see the attached diff file for FLTK 1.1.9 and try if it solves your problem. Albrecht Index: src/fl_ask.cxx === --- src/fl_ask.cxx (revision 6881) +++ src/fl_ask.cxx (working copy) @@ -207,6 +207,8 @@ else button[0]->shortcut(FL_Escape); + while (Fl::readqueue()) ; + message_form->show(); // deactivate Fl::grab(), because it is incompatible with Fl::readqueue() Fl_Window* g = Fl::grab(); ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_alert() closes immediately
On 22.12.2009, at 07:36, N. Cassetta wrote: > Here's a (minimal) implementation of my problem. When I click the lower > button, fl_alert() appears and suddenly closes as if a mouse click was still > pending. MyBox::handle does not take care of mouse release events, so instead they are sent to whatever other widget may take them, in this case the alert. I suggest that you take a look at src/Fl_Button.cxx to see how a mouse click should be handled. Wouldn't it be batter to derive MyBox from Fl_Botton? Matthias ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] fl_alert() closes immediately
Here's a (minimal) implementation of my problem. When I click the lower button, fl_alert() appears and suddenly closes as if a mouse click was still pending. I use FLTK 1.1.9 with CodeBlocks (MinGW)and WinXP. * #include #include #include #include #include #include class MyWin : public Fl_Window { public: MyWin(); int handle(int e); private : static void exit_cb(Fl_Widget* w, void *p); Fl_Toggle_Button* Btnum[10]; Fl_Button* Btnumok; }; MyWin::MyWin() : Fl_Window(400, 180, 118, 125) { char s[3]; for (int c = 0; c < 9; c++) { Btnum[c] = new Fl_Toggle_Button (10+34*(c%3), 2+32*(c/3), 30, 30); sprintf(s, "%d", c+1); Btnum[c]->copy_label(s); } Btnumok = new Fl_Button(10, 100, 46, 20, "Ok"); Btnumok->callback(exit_cb); end(); set_modal(); show(); } int MyWin::handle (int event) { int ret = Fl_Window::handle(event); if (event == FL_PUSH) { int num = find(Fl::pushed()); if (num > 8) return 1;// OK was pressed // else do something } return ret; } void MyWin::exit_cb(Fl_Widget* w, void* p) { // do something w->window()->hide(); } //** class MyBox : public Fl_Box { public: MyBox(int x, int y, int w, int h, char* l) : Fl_Box(x, y, w, h, l) {box(FL_UP_BOX); } protected : int handle(int event); }; int MyBox::handle (int event) { if (event == FL_PUSH) { MyWin* MW = new MyWin(); label ("Click numbers and then OK"); while (MW->shown()) Fl::wait(); delete MW; return 1; } return Fl_Box::handle(event); } //** void showalert_cb(Fl_Widget* w, void* p) { fl_alert("This disappears!"); } int main (int argc, char ** argv) { Fl_Window *window; Fl_Button *w; window = new Fl_Window (300, 180); new MyBox (20, 40, 200, 30, "First click here"); w = new Fl_Button(20, 100, 100, 30, "Then here"); w->callback(showalert_cb); window->show(); return(Fl::run()); } ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk