| [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #2617
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 2 - Specific to an operating system |
Subsystem: | Core Library |
Summary: | Inconsistent behavior for Fl_Window on win32 |
Version: | 1.4-feature |
Created By: | hean01 |
Assigned To: | matt |
Fix Version: | Will Not Fix |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | hean01 04:42 May 03, 2011 |
| There is a inconsistent behavior when an modal window is closed the win32 implementation is calling BringWindowToTop() on the previous window in stack and a VM_SHOWWINDOW event is pushed into message queue for the actual window.
This will result in that a window's implementation of show() will be called even if it's already shown and will introduce problems when user uses show() for example: initialization of dialog data.
One solution to this could be a check inplemented in WndProc() to filter out dispatching of show events if window alread is in the state of the request.
/Henrik Andersson | |
|
#2 | AlbrechtS 09:42 May 03, 2011 |
| I wouldn't call this behavior "inconsistent", and it is even documented (somewhere) that it is harmless to call show() more than once to bring a window in front (the Window Manager may, however, decide not to do that, anyway).
If you really want to initialize dialog data only in the first call of show(), then you can (and IMHO *should*) guard this part of the code with a static variable and modify and check this variable to see if this has been done before.
If I misunderstood you, please elaborate on what you mean exactly with "inconsistent", and why you think that this behavior should be changed. | |
|
#3 | hean01 23:15 May 03, 2011 |
| Oh, I missed to define inconsistency,the case is that X doesn't generate and dispatches a show() call when window is bring to front but the win32 implementation does.
So it's inconsistent behavior between platform in this case and IMHO the win32 shouldn't generate a show().
/Henrik | |
|
#4 | AlbrechtS 02:42 May 04, 2011 |
| I lowered the priority to Low ("undocumented side-effect"), what it seems to be. This should definitely not block the release of FLTK 1.3.0.
To Henrik: Okay, we should probably investigate this. However, this is something that is likely to *be* different (inconsistent) on different platforms, but anyway...
It would be a great help if you could post a small demo program (complete, compileable source code) to this STR that shows the effect, preferably with that type of show() function that you implemented (did you derive your own window class from Fl_Window?). | |
|
#5 | matt 00:53 May 09, 2011 |
| FL_SHOW events can come at any time. They are usually associated to a window being displayed or raised, but they are only guaranteed to be sent if FLTK raises a window. On MSWindows, FLTK must raise windows after closing modal windows to keep stacking order correct due to a bug in some MSWindows desktop managers. | |
|
#6 | matt 04:29 Jan 20, 2023 |
| Maybe to clarify, Fl_Window::show() is not only used to show a window for the first time or after a hide, but also to raise the window to the top of the stack. Overriding show() to unconditionally initialise data is a bad idea.
file:///Users/matt/dev/fltk-1.4.git/build/Xcode/documentation/html/classFl__Wind ow.html#aa773a3f4d474e4f91d62064c1c829c1b | |
[ Return to Bugs & Features ]
|
| |