| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #334
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | technical change : remove statics in fl_ask |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | pgriddev.yahoo |
|---|
| Assigned To: | AlbrechtS |
|---|
| Fix Version: | 1.4.0 |
|---|
| Fix Commit: | 130f864d1d3f02f854a5f4085a49318a03a8eea0 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | pgriddev.yahoo
07:46 Apr 05, 2004 |
| Currently all functions in fl_ask.cxx use a common static form.
This is not an issue as long as only one form is displayed at any time.
Even in multi-threaded apps, Fl::lock()/unlock() must wrap the call
to, say, fl_alert, so there is no problem.
But in the future someone might want to open several pop-ups
simultaneously (will require additional work, there are issues
between the locking scheme and modal windows). Anyway, since
I wrote the changes (thinking it was the way to solve another
multi-thread bug), I'm posting them here --see attached diff file,
and description of changes below.
The changes were tested briefly (have 2 threads make a call to
fl_alert) under win32 (Win2000 SP4) using Fl::lock()/Fl::unlock()
=======
code changes (more text to describe them than to implemenent them):
=======
- remove global static : message_form, message, icon, button[3], input
- create class Fl_Message containing the above
- change makeform() into Fl_Message constructor, create destructor
- make follwing functions Fl_Message methods, removing all calls to
makeform() :
- resizeform()
- innards()
- input_innards()
- alter the following functions to make use of Fl_Message:
- fl_message
- fl_alert
- fl_ask
- fl_choice
- fl_input
- fl_password
- for fl_message_icon(), additional changes were needed
- create a global static : Fl_box *icon_default_ (formerly icon)
- have fl_message_icon() create it if it does not exist (using the
same defaults as previously), then return it
- in Fl_Message constructor (formerly makeform()), set all
atttibutes of the icon member variable to those of the return
of fl_message_icon()
- remove prev_icon_label in innards, this is covered by the default
value in Fl_Message constructor
Not changed, but shouldn't fl_message_icon() be returning Fl_Box
instead of Fl_Widget ?
| |
| |
| #2 | AlbrechtS
10:56 Apr 06, 2004 |
| I think that this modification wouldn't work with more than one popup window (e.g. fl_ask). This is because innards() calls Fl::readqueue() and Fl::wait() until one of the buttons of the _corresponding_ fl_ask() window will be clicked. This would have to be rewritten, too, wouldn't it?
Albrecht | |
| |
| #3 | mike
12:40 Apr 06, 2004 |
| pgriddev:
Looks good, may need some cleanup; the fl_message_box() needs to return a widget so that the image/label can be changed as well as the boxtype. We may just use a semaphore for 1.1.x, however, as the new fl_message_box() implementation is not safe anyways...
The Fl_Message_Box class may see life as a real widget class in 1.2.
Albrecht:
Innards can monitor for the current widget, so his code is safe; longer term we probably want to move away from Fl::readqueue(), though, so the final implementation will likely be different.
Thanks all! | |
| |
| #4 | AlbrechtS
08:50 Apr 07, 2004 |
| Mike, you wrote:
> Innards can monitor for the current widget, so his code is safe;
I'm not sure if you understood me, and if I understood you ;-)
What I wanted to say is that innards() is a kind of _blocking_ call (though with FLTK event processing), and therefore there will never be two Fl_Message_xxx widgets be reading the (no_callback_)queue FL::readqueue() at the same time - I assume that readqueue() removes the widget from the queue.
Slightly confused ;-)
Albrecht | |
| |
| #5 | pgriddev.yahoo
11:56 Apr 07, 2004 |
| looks like I fell behind a bit...
--- michael :
about fl_message_icon() (there is no fl_message_box(), right ?), I don't
understand : Fl_Box is inherited from Fl_Widget, so image/label can
be changed, too ?
The return value would need locking yes, but it might be easier/cleaner
to return a copy and have a fl_message_icon(Fl_Widget/Fl_Box *w)
(and *there* the caller is supposed to have called Fl::lock() ) ?
--- michael & Albrecht :
like I said, it works for once instance, but there are issues to go
multiple-instances.
I don't think the main problem is in innards(), though. True, Fl::readqueue() might be called from the wrong thread and pop an event
meant for the other one, but then I guess that it would still be
possible to close the first message box, then the previously-starved
one (and Fl::wait() releases the lock, so no blocking there in
innards() ). That's why I thought I would propose the change : the rest
happens elsewhere (if I'm not wrong)
My concern is more with modal windows (since those popups are modal).
I don't know FLTK well enough yet, but I suspect that something there
is wrong when several modals are active in *different* threads.
This might or might no be related to my post in fltk-bugs about modal
windows. Maybe I'll try to have a deeper look in the next weeks, but
right now I can't help. In any case multiple popups don't work --if I
didn't mess up my testing again.
| |
| |
| #6 | ianmacarthur
04:53 May 02, 2008 |
| I'm very late to this thread - but here's my thoughts...
There's some discussion in the above about showing fl_ask style dialogs from more than one thread.
That's not going to work, is it? Only the "main" thread can safely call fl_ask (et al) because they create/destroy windows, and the current code can only safely do that (lock/unlock notwithstanding) from the main thread... I think.
The reason I think this is one of the guys here had a win32 program that tried to pop an fl_something dialog from a helper thread, and he was getting all sorts of weirdness. Moving the dialog box to the main thread fix it. | |
| |
| #7 | pgriddev.yahoo
00:35 May 05, 2008 |
| @ianmacarthur:
I got it to work with the change I posted (i.e. it is not mandatory to use the main thread), but I think ONLY after I also fixed FL_x::make() in Fl_win32.cxx: some Win32 calls are blocking (undocumented) and I had to alter as follow (can't remember if I ever posted that particular bit):
- insert the following in Fl_x::make():
parent = 0;
...== INSERT BEGIN ==...
if (w->modal()) {
parent = 0;
} else
...== INSERT END ==...
if (w->non_modal() && Fl_X::first && !fl_disable_transient_for) {
- replace call(s) to BringWindowToTop() by SetForegroundWindow()
This is all based on my notes + memory, I gave up on this STR given the lack of interest, and actually stopped using FLTK at the moment... (not because I don't find it good, only because I wanted native look & feel) | |
| |
| #8 | AlbrechtS
05:08 Jul 21, 2015 |
| I'm currently working on this STR. Lots have changed meanwhile, so the patch was taken as a starting point, but the implementation will be different.
I'm not sure if we can (and want to) get this into FLTK 1.3.4, but this should definitely go into FLTK 1.4.0. Hopefully.
See /also/ STR #2751 "Limit input field characters." which is related. My planned solution will include both issues.
http://www.fltk.org/str.php?L2751 | |
| |
| #9 | AlbrechtS
06:06 Dec 04, 2021 |
| 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 | |
| |
| #10 | AlbrechtS
09:42 Dec 04, 2021 |
| Correction: fixed finally in commit 130f864d1d3f02f854a5f4085a49318a03a8eea0
because of a name clash on macOS and Windows. | |
[ Return to Bugs & Features ]
|
| |
