Hi!
From time to time I'm testing our application (IQ-FMEA) with Wine.
Our GUI framework is checking the return codes of most API calls, so several incompatibilities between Windows and Wine are detected while many other programs simply ignore them.
So I found several things that differ between Wine & Windows.
############################# 1.)
If found out that InvalidateRect with a "zero extent rectangle" returns FALSE with Wine, while it returns TRUE in Windows. Wine builds from last year did not show this behavior.
Windows: InvalidateRect(hwnd, RECT(10,10,10,15), TRUE); returns TRUE;
Wine InvalidateRect(hwnd, RECT(10,10,10,15), TRUE); returns FALSE;
------------- Wine 20040914
BOOL WINAPI RedrawWindow( HWND hwnd, const RECT *rectUpdate, HRGN hrgnUpdate, UINT flags ) ... return TRUE; }
Wine 20050930
... ret = redraw_window_rects( hwnd, flags, rect, 1 ); ... return ret; }
static BOOL redraw_window_rects( HWND hwnd, UINT flags, const RECT *rects, UINT count ) { BOOL ret;
SERVER_START_REQ( redraw_window ) { req->window = hwnd; req->flags = flags; wine_server_add_data( req, rects, count * sizeof(RECT) ); ret = !wine_server_call_err( req ); } SERVER_END_REQ; return ret;
#################### 2.)
Then I discovered an incompatibility with LB_SELITEMRANGE:
SendMessage(hWndControl,LB_SELITEMRANGE,TRUE, MAKELPARAM(wFirst, wLast));
Windows accepts values for wLast that are greater than the list size and performs the operation with the (internally corrected) value - returning TRUE.
Wine does not accept a value for wLast if it is greater than the list size and returns FALSE (not performing the select operation, which caused subsequent failures in our application).
#################### 3.) There is also a different behavior of SetCapture(hWnd) in Wine. If an overlapped window has captured the mouse input and a new child window is being openend, Windows internally releases the capture. Wine maintains the capture - dialogs in our application may not be operated with the mouse, because the parent still gets all the mouse messages.
####################
I have to little knowledge about the wine server stuff to make a correct fix for issues 1 & 3. And I'm unsure about issue #2. It's a bug to pass to big values for wLast - but to be compatible with Windows, Wine should perform like Windows (perhaps log a warning?).
Regards Andy
On Tue, 01 Nov 2005 12:14:51 +0100, Andreas Rosenberg sonix2003@ctf-z.de wrote:
3.) There is also a different behavior of SetCapture(hWnd) in Wine. If an overlapped window has captured the mouse input and a new child window is being openend, Windows internally releases the capture. Wine maintains the capture - dialogs in our application may not be operated with the mouse, because the parent still gets all the mouse messages.
This seems to correlate with what I documented on Dragon Naturally Speaking. During the user training the mouse has no effect on the dlg and it is necessary to use Alt_letter combinations to continue.
Nice work on pinning it down so precisely.
"Andreas Rosenberg" sonix2003@ctf-z.de wrote:
From time to time I'm testing our application (IQ-FMEA) with Wine.
Our GUI framework is checking the return codes of most API calls, so several incompatibilities between Windows and Wine are detected while many other programs simply ignore them.
So I found several things that differ between Wine & Windows.
Many thanks for reporting this bugs! Please continue reporting anything you find that might prevent your apps to work correctly under Wine.
############################# 1.)
If found out that InvalidateRect with a "zero extent rectangle" returns FALSE with Wine, while it returns TRUE in Windows. Wine builds from last year did not show this behavior.
Windows: InvalidateRect(hwnd, RECT(10,10,10,15), TRUE); returns TRUE;
Wine InvalidateRect(hwnd, RECT(10,10,10,15), TRUE); returns FALSE;
A fix for this bug has been committed to CVS.
#################### 2.)
Then I discovered an incompatibility with LB_SELITEMRANGE:
SendMessage(hWndControl,LB_SELITEMRANGE,TRUE, MAKELPARAM(wFirst, wLast));
Windows accepts values for wLast that are greater than the list size and performs the operation with the (internally corrected) value - returning TRUE.
Wine does not accept a value for wLast if it is greater than the list size and returns FALSE (not performing the select operation, which caused subsequent failures in our application).
I just sent a patch to wine-patches which should fix this bug.
#################### 3.) There is also a different behavior of SetCapture(hWnd) in Wine. If an overlapped window has captured the mouse input and a new child window is being openend, Windows internally releases the capture. Wine maintains the capture - dialogs in our application may not be operated with the mouse, because the parent still gets all the mouse messages.
Could you please send a small test app demonstrating this behaviour?