DefDlgProc* broken for (at least) WM_GETTEXT
The DefDlgProc16, DefDlgProcA and DefDlgProcW call CallWindowProc16, CallWindowProcA and CallWindowProcW to pass messages to the dialog procedures. The problem with this is that a dialog procedure is not a window procedure, despite having a similar signature. The dialog procedures return a BOOL rather than an LRESULT - the value that would be returned by a window procedure is returned by 'SetWindowLongPtrW( hwnd, DWLP_MSGRESULT, ... );' for a dialog procedure, and the return value of the dialog procedure is a BOOL indicating whether the message was processed. This causes problems for messages like WM_GETTEXT, where the return value of the message is needed for (and modified by) post-processing when calling across a W->A or A->W boundary. It seemed that the tidyest fix would be to create three new routines internal to dlls/user: "call_dialog_proc_a", "call_dialog_proc_w" and "call_dialog_proc16". These three routines would be substantially the same as CallWindowProcA, CallWindowProcW and CallWindowProc16, except that they would pass a flag to the 6 cross-call case handling routines to let the routine know it is calling a dialog procedure and needs to use the value for DWLP_MSGRESULT for its post-processing. The problem with this is that two of the cross-call handling routines (the 16->W and 16->A ones) are exported: __wine_call_wndproc_32A __wine_call_wndproc_32W They do not appear to be used anywhere outside of the file they are defined in, and it seems unlikely an app could ever have a legitimate use for them. Vitaliy suggested maybe they may have been inadvertently missed in a cleanup of cross-DLL calls. So, what I propose to do is: 1. make __wine_call_wndproc_32A and __wine_call_wndproc_32W static (and hence not exported) 2. Add a parameter to each of __wine_call_wndproc_32A, __wine_call_wndproc_32W, WINPROC_CallProc32WTo32A, WINPROC_CallProc32WTo16, WINPROC_CallProc32ATo16 and WINPROC_CallProc32ATo32W to indicate that the cross-call routine should get the LRESULT from (and set it into) the DWLP_MSGRESULT value. 3. Rename the existing CallWindowProc* routines to (static) call_window_proc*, add the flag parameter there as well, and create new CallWindowProc* and call_dialog_proc_* routines to call the renamed routines with the appropriate flag. Any objections?
Troy Rollo <wine(a)troy.rollo.name> writes:
They do not appear to be used anywhere outside of the file they are defined in, and it seems unlikely an app could ever have a legitimate use for them. Vitaliy suggested maybe they may have been inadvertently missed in a cleanup of cross-DLL calls.
So, what I propose to do is:
1. make __wine_call_wndproc_32A and __wine_call_wndproc_32W static (and hence not exported)
You can't do that, they need to be exported so that they can be called from 16-bit code (look at how 16->32 thunks are implemented). -- Alexandre Julliard julliard(a)winehq.org
On Thursday 13 October 2005 18:24, Alexandre Julliard wrote:
Troy Rollo <wine(a)troy.rollo.name> writes:
So, what I propose to do is:
1. make __wine_call_wndproc_32A and __wine_call_wndproc_32W static (and hence not exported)
You can't do that, they need to be exported so that they can be called from 16-bit code (look at how 16->32 thunks are implemented).
OK, well an alternative is to do the same with them as with the CallWindowProc* entry points (rename them, add the extra parameter to each, and add new entry points under the existing names calling the versions with the BOOL parameter).
Troy Rollo <wine(a)troy.rollo.name> writes:
OK, well an alternative is to do the same with them as with the CallWindowProc* entry points (rename them, add the extra parameter to each, and add new entry points under the existing names calling the versions with the BOOL parameter).
It's probably easier to add a parallel set of CallDlgProc functions, especially since this will require fewer changes to the assembly thunks. -- Alexandre Julliard julliard(a)winehq.org
On Fri, 14 Oct 2005 07:19, Troy Rollo wrote:
On Thursday 13 October 2005 19:22, Alexandre Julliard wrote:
It's probably easier to add a parallel set of CallDlgProc functions, especially since this will require fewer changes to the assembly thunks.
I'll submit it both ways and you can pick one.
When I got to implementing this it turned out that "my" way ended up including this as part of it, so I will only submit one since there isn't really a "different" way would do anything other than result in lots of duplicated code.
Troy Rollo <wine(a)troy.rollo.name> writes:
When I got to implementing this it turned out that "my" way ended up including this as part of it, so I will only submit one since there isn't really a "different" way would do anything other than result in lots of duplicated code.
I'm afraid I'll have to disagree. Sure it's a bit more code, but IMO it's cleaner than passing booleans around everywhere. Especially since you can then use correct types (DLGPROC instead of WNDPROC) and have the compiler make sure you are not mixing things you shouldn't. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Troy Rollo