Dmitry Timoshkov dmitry@baikal.ru writes:
Hello,
Changelog: Dmitry Timoshkov dmitry@codeweavers.com Add support for CS_NOCLOSE.
This is implemented already in MENU_InitSysMenuPopup; if it doesn't work right it should be fixed there.
"Alexandre Julliard" julliard@winehq.org wrote:
This is implemented already in MENU_InitSysMenuPopup; if it doesn't work right it should be fixed there.
Windows doesn't use SetWindowPos to update the disabled Close button, but draws the button directly. So you can apply the patch and ignore only the last chunk of it:
--- cvs/hq/wine/windows/win.c Wed Jun 25 15:59:24 2003 +++ wine/windows/win.c Sat Aug 2 22:43:41 2003 @@ -1169,6 +1169,10 @@ static HWND WIN_CreateWindowEx( CREATEST return 0; }
+ /* Disable the 'Close' system menu item in the case of CS_NOCLOSE */ + if ((GetWindowLongW(hwnd, GWL_STYLE) & WS_SYSMENU) && (GetClassLongW(hwnd, GCL_STYLE) & CS_NOCLOSE)) + EnableMenuItem(GetSystemMenu(hwnd, FALSE), SC_CLOSE, MF_GRAYED); + /* Notify the parent window only */
send_parent_notify( hwnd, WM_CREATE );
I'll try to investigate why existing code in MENU_InitSysMenuPopup doesn't work.
"Dmitry Timoshkov" dmitry@baikal.ru writes:
Windows doesn't use SetWindowPos to update the disabled Close button, but draws the button directly.
Actually that doesn't look right either, we shouldn't bypass the normal painting code IMO; but RedrawWindow(RDW_FRAME) would probably work better than SetWindowPos.
"Alexandre Julliard" julliard@winehq.org wrote:
Windows doesn't use SetWindowPos to update the disabled Close button, but draws the button directly.
Actually that doesn't look right either, we shouldn't bypass the normal painting code IMO; but RedrawWindow(RDW_FRAME) would probably work better than SetWindowPos.
Probably RedrawWindow(RDW_FRAME) would be better, but under Windows a window doesn't receive WM_NCPAINT in that case either.
"Alexandre Julliard" julliard@winehq.org wrote:
Actually that doesn't look right either, we shouldn't bypass the normal painting code IMO; but RedrawWindow(RDW_FRAME) would probably work better than SetWindowPos.
Here is an updated patch which works for me and also removes WM_SYSCOMMAND/SC_CLOSE filtering based on the CS_NOCLOSE test in DefWindowProc. My test under win2k shows that Windows sends WM_SYSCOMMAND/SC_CLOSE and then WM_CLOSE regardless whether CS_NOCLOSE is set or not.
Alexandre, I understand that you want to separate the drawing code from such cases and prevent a possible breakage of win31/etc. drawing code. But that's how it's done in Windows. It's up to you, if you wish, to replace the NC_DrawCloseButton95 call by RedrawWindow(RDW_FRAME) if you still think that it's cleaner to do.
"Dmitry Timoshkov" dmitry@baikal.ru wrote:
My test under win2k shows that Windows sends WM_SYSCOMMAND/SC_CLOSE and then WM_CLOSE regardless whether CS_NOCLOSE is set or not.
Wrong. Please ignore that chunk of the patch. If other parts are OK I'll resend the whole thing.
"Dmitry Timoshkov" dmitry@baikal.ru writes:
Alexandre, I understand that you want to separate the drawing code from such cases and prevent a possible breakage of win31/etc. drawing code. But that's how it's done in Windows. It's up to you, if you wish, to replace the NC_DrawCloseButton95 call by RedrawWindow(RDW_FRAME) if you still think that it's cleaner to do.
I think it's much better, drawing directly will cause a lot of problems, especially when called from another thread context. Unless you really have an app that depends on not getting a WM_NCPAINT here I see no reason not to use the normal mechanisms.
"Alexandre Julliard" julliard@winehq.org wrote:
I think it's much better, drawing directly will cause a lot of problems, especially when called from another thread context. Unless you really have an app that depends on not getting a WM_NCPAINT here I see no reason not to use the normal mechanisms.
OK, here is another patch. But it now exposes a bug in Wine's RedrawWindow() implementation. Under win2k RedrawWindow(RDW_FRAME | RDW_INVALIDATE) causes a window to receive only WM_NCPAINT, while under Wine it redraws the whole window.