STR #2617

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 | Post Text | Post File ]

STR #2617

Application:FLTK Library
Status:5 - New
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
Created By:hean01
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#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().

#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.  
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


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