Sheldon Gill wrote:
Christopher Armstrong wrote:
There are outstanding issues with the windows backend related to window
management. I believe some of these can be fixed by responding to
certain Win32 window messages that MSWindows posts out. I am referring
to the problems with window layering/levels/ordering and related focus
issues that seem to affect everything from windows going missing to
modal windows playing up.
Not to mention the click twice to edit problem ;)
What is this one exactly? Is it needing to focus a window before it
responds to mouse events?
application was given/lost the keyboard focus), WM_ACTIVATEAPP (your
application itself lost/gained the keyboard focus) and
WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED (called for a litany of window
resize/move/focus/Z-order events where the outcome can be "adjusted"). I
think these could help.
Win32 provides some window messages such as WM_ACTIVATE (a window in an
Probably, although correcting calls to SetWindowPos() should fix the
vast majority of problems.
It's not just that. A window can be brought to the front of the Z-order
by simply clicking on it in Windows; that's what is expected to happen.
Windows doesn't have any concept of window levels, except with modal
windows and "Always on top", which are just hacks anyway.
WM_WINDOWPOSCHANGING allows the programmer to intercept any sort of
move/size/z-order change event and modify the outcome, including
rejecting the change. This is needed to prevent windows going under
other windows when a dialog box is running modal, and to make sure menus
and their counterparts appear to "float". Currently, windows just get
reordered by normal Win32 ordering rules: user clicks on window, window
is brought to top of Z-Order. This needs to be fixed.
Cheers
Chris
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
