FLTK logo

STR #3242

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | SVN ⇄ GIT ]

STR #3242

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Re-enable nested (aka "recursive") common dialogs
Version:1.4-feature
Created By:AlbrechtS
Assigned To:AlbrechtS
Fix Version:1.4.0
Fix Commit:130f864d1d3f02f854a5f4085a49318a03a8eea0
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 AlbrechtS
08:08 Jul 29, 2015
Fl_Dialog_r10820.patch
39k
 
 
#2 AlbrechtS
06:26 Aug 13, 2015
Fl_Dialog_r10831.patch
39k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#1 AlbrechtS
08:08 Jul 29, 2015
The standard dialogs fl_ask() and friends can not be called in a nested (recursive) way, because they share a common static message window and Fl_Input::value() for string returns. See STR #334 for a report and a proposed fix.
http://www.fltk.org/str.php?L334

Also, the fl_input() and fl_password() functions should be able to limit the input size in characters, as proposed in STR #2751, see
http://www.fltk.org/str.php?L2751

Note: I used priority HIGH because this should be solved in FLTK 1.3.4, particularly the blocking of nested dialogs since FLTK 1.1.10.

---

The attached patch Fl_Dialog_r10820.patch fixes these issues, but is still work in progress. It is API and ABI compatible.

---

FYI: I decided to add the hidden/private/undocumented class Fl_Dialog_13x (Fl_Dialog for 1.3.x) as a preliminary class and discourage its use except for the common dialogs in FLTK 1.3.4. My intention is to add one or more Fl_Dialog_Something classes to 1.4.0 eventually. My vision is to have a base class (maybe Fl_Dialog or Fl_Dialog_Window) with all the basic methods (some private, protected, and/or virtual) and maybe Fl_Message or Fl_Dialog_Message for the common dialogs with their specialized innards. The base class is intended to be subclassed by users. That's all to be discussed later. Currently we need a solution that is less complicated and doesn't break the API or ABI.

---

One open question is how to extend the API to return a private string (buffer) for fl_input() and fl_password() since these are currently shared by using the shared (static) message window's Fl_Input::value() buffer. The proposed patch overloads these methods by using an additional maxchar argument and returns a private buffer that must be free()'d by the application.

I started a thread in fltk.coredev ("RFC: fl_input() and fl_password() API extensions - help needed") that describes the issue, and I asked for proposals for the API extension. All comments and suggestions are appreciated.
https://groups.google.com/forum/#!topic/fltkcoredev/dlAC5qXxBew

Tests and bug reports welcome as well.
 
 
#2 AlbrechtS
06:26 Aug 13, 2015
Please see attached file Fl_Dialog_r10831.patch for a new version of the previous patch.

Basically I changed only the method names of the new methods: instead of overloading fl_input() and fl_password() the new method names are fl_input_str() and fl_password_str() resp., as proposed by Greg in fltk.coredev. Other changes are documentation only.

I used only these minimal changes to keep the API as close as possible to the old API. Further API extensions are planned for FLTK 1.4.0.

Note that although there *are* new methods, all old code is expected to work w/o changes. The only *intended* difference should be that there can be multiple popups open at the same time (in FLTK 1.3.3 and older the second popup would be blocked).

I believe that this patch is ready to be committed. If there is no objection within the next 2-3 days I'll go ahead and commit it.

Test results and feedback from usage with "real" apps would be very much appreciated.
 
 
#4 AlbrechtS
05:48 Jan 30, 2016
Moved from 1.3-feature to 1.4-feature.

FLTK 1.4.0 will have a better dialog class and support nested (aka "recursive") dialogs.
 
 
#5 AlbrechtS
06:03 Dec 04, 2021
Fixed in Git repository.

Commit b6de09cff2465db3c0a6e6a013b825462bc9a0e7 fixes three STR's and one open issue:

- STR   334: technical change : remove statics in fl_ask
- STR  3242: Re-enable nested (aka "recursive") common dialogs
- STR  2751: Limit input field characters in fl_ask, fl_input and friends
- Issue 282: fl_choice() doesn't tell you if the dialog was closed
 
 
#6 AlbrechtS
09:44 Dec 04, 2021
Correction: fixed finally in commit 130f864d1d3f02f854a5f4085a49318a03a8eea0
because of a name clash on macOS and Windows.
 
     

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.