FLTK logo

STR #2617

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 #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:

Receive EMails Don't Receive EMails

Trouble Report Files:

No files


Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

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'.