Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try2)
Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes:
@@ -85,6 +85,17 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND *prev_ret ) HWND previous = 0; UINT flags = 0; BOOL ret; + GUITHREADINFO info; + if(!GetGUIThreadInfo(GetCurrentThreadId(), &info)) + { + return FALSE; + } + + /* if in menu mode, reject all requests to change focus, except if the menu bit is set */ + if((info.flags & GUI_INMENUMODE) && !(gui_flags & GUI_INMENUMODE)) + { + return FALSE; + }
This should be handled on the server side. -- Alexandre Julliard julliard(a)winehq.org
Hello A. I was afraid you were going to say that! :-) My initial change actually did that, but then i ran into the problem that i need the request to fail, but not set an error-code. I could push/pop the current error code in user32 but that seemed a bit ugly. I could also single out that error code and then only translate the others. But what error code should be used then? Also seemed a bit ugly. Instead i have added a new member to the response to check if the request was "allowed". Seemed like the cleanest solution. Is this acceptable? I have attached a new patch which does this. Thanks, /pedro On Fri, 2010-01-08 at 10:06 +0100, Alexandre Julliard wrote:
Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes:
@@ -85,6 +85,17 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND *prev_ret ) HWND previous = 0; UINT flags = 0; BOOL ret; + GUITHREADINFO info; + if(!GetGUIThreadInfo(GetCurrentThreadId(), &info)) + { + return FALSE; + } + + /* if in menu mode, reject all requests to change focus, except if the menu bit is set */ + if((info.flags & GUI_INMENUMODE) && !(gui_flags & GUI_INMENUMODE)) + { + return FALSE; + }
This should be handled on the server side.
Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes:
Hello A.
I was afraid you were going to say that! :-)
My initial change actually did that, but then i ran into the problem that i need the request to fail, but not set an error-code. I could push/pop the current error code in user32 but that seemed a bit ugly. I could also single out that error code and then only translate the others. But what error code should be used then? Also seemed a bit ugly.
Simply use wine_server_call instead of wine_server_call_err. -- Alexandre Julliard julliard(a)winehq.org
Simply use wine_server_call instead of wine_server_call_err.
That is my point. That will not work. The existing the error codes *should* be translated, but this new one should not. So if i use wine_server_call i would have to filter which ones to translate manually. It would also give me the problem of which error code to emit from the wine-server, as real windows does not set an error code at all in this case (hence the problem). I think it would be a bit naughty emitting errors from the server and them removing them with a filter later. Does not seem clean. But if you want me to do this, then what NT error code should the server use? I imagine that no matter what unused error code i selected the response would be "this error code i not meant for that purpose" (which would probably be right as there is no error code for this purpose). I still feel that an extra field in the response in the cleanest (the way my patch did it). Sorry for being so verbal, but i know that you are touchy about the server :-) Thanks, /pedro
Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes:
Simply use wine_server_call instead of wine_server_call_err.
That is my point. That will not work. The existing the error codes *should* be translated, but this new one should not. So if i use wine_server_call i would have to filter which ones to translate manually.
Is there actually an app that depends on this? user32 functions don't handle last error consistently so it seems pretty unlikely that anything would depend on this.
But if you want me to do this, then what NT error code should the server use? I imagine that no matter what unused error code i selected the response would be "this error code i not meant for that purpose" (which would probably be right as there is no error code for this purpose).
If there's no appropriate code just use some generic error like "access denied" or "invalid parameter". -- Alexandre Julliard julliard(a)winehq.org
On Mon, 2010-01-11 at 14:00 -0600, Alexandre Julliard wrote:
Is there actually an app that depends on this?
http://bugs.winehq.org/show_bug.cgi?id=9369 This bug requires the function to fail, but you are probably right that no-one checks the error code. I will change the patch/test to be less pedantic. Thanks for the fast reply, /pedro
participants (2)
-
Alexandre Julliard -
Peter Dons Tychsen