Re: comctl32/imagelist: use proper color format for merged image lists (try 2)
Hello,
No surprises in mask behavior - the result is always masked. On the
other hand, merging ILC_COLOR16 with ILC_COLORDDB (which is 32bit)
results in 16bit image:
https://testbot.winehq.org/JobDetails.pl?Key=24624
All other merges (including reverse of the above = ILC_COLORDDB with
ILC_COLOR16) use the greater of the color depths from source
imagelists.
Any idea what might be happening there?
Regards,
Daniel
2013/3/5 Alexandre Julliard :
> Daniel Jelinski writes:
>
>> +static void test_merge_colors(void)
>> +{
>> +HIMAGELIST himl[5], hmerge;
>> +int sizes[] = { ILC_COLOR4, ILC_COLOR8, ILC_COLOR16, ILC_COLOR24,
>> ILC_COLOR32 };
>
> You should also test COLORDDB, and probably the mask behavior too.
>
> --
> Alexandre Julliard
> julli...@winehq.org
Re: comctl32/listview: fix mouse message sequences
2013/2/25 Nikolay Sivov : > On 2/24/2013 17:52, Daniel Jelinski wrote: >> >> 2013/2/24 Nikolay Sivov : >>> >>> This doesn't look very clean. I mean invoking *up handler from a *down >>> one. >>> Is this something that could be resolved with message loop like rbutton >>> dragging was fixed? >> >> TrackMouse contains the message loop. It returns FALSE when it >> receives LBUTTONUP (or any other button message), > > Okay, so why not let corresponding message handler to process it normally? Short answer: because that's how native behaves. They don't call DispatchMessage on button messages received in message loop, so neither do we. According to this MSDN page: http://msdn.microsoft.com/en-us/library/windows/desktop/bb774734%28v=vs.85%29.aspx Listview window procedure does not handle MOUSEMOVE and *BUTTONUP messages. My experience with +message logs seems to confirm that. Every time when any action happens in response to *BUTTONUP, it is contained in some kind of message loop. My long term goal is to remove these handlers from wine's implementation as well. I wanted to remove call to LISTVIEW_LButtonUp from window proc already, but unfortunately marquee selection still depends on it.
Re: comctl32/listview: fix mouse message sequences
2013/2/24 Nikolay Sivov : > This doesn't look very clean. I mean invoking *up handler from a *down one. > Is this something that could be resolved with message loop like rbutton > dragging was fixed? TrackMouse contains the message loop. It returns FALSE when it receives LBUTTONUP (or any other button message), so calling LButtonUp here is almost exactly what happened before. I'm not sure if inlining the call would help here. Regards, Daniel
Re: comctl32/listview: fix selection in ownerdata listview
Hello Nikolay, I didn't have time to write and test a proper fix yet, and I'm not sure when I will. I thought this hack may be better than what we have now. If you want to fix this, please do. If not, I'll get back to it later. Regards, Daniel 2013/2/21, Nikolay Sivov : > What's a problem in fixing this properly? This change could break > something potentially, it was disabled for a purpose of fixing some real > application as I remember.
Re: [1/5] comctl32/tests: more tests for icon spacing calculation
Hello,
Thanks for reviewing. What's the preferred way of checking whether the
code is compiled for 32 or 64bit?
Regards,
Daniel
2013/1/24 Alexandre Julliard :
> Daniel Jelinski writes:
>
>> +#ifdef _WIN64
>> +/* NOTE: -1 is not treated the same as (DWORD)-1 by 64bit listview */
>> +ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, (DWORD)-1);
>> +todo_wine {
>> +expect(100, LOWORD(ret));
>> +expect(0x, HIWORD(ret));
>> +}
>> +ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, 0xBAADF00DDEADBEEFLL);
>
> Please avoid ifdefs and long long constants.
>
> --
> Alexandre Julliard
> julli...@winehq.org
Re: [3/5] comctl32/listview: always use large icon size when calculating icon spacing
Looks like the testbot is still having problems... 2013/1/20 Marvin : > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=24024 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed to apply
Re: gdi32/tests: GetTextExtentPoint should give repeatable results
2013/1/15 Alexandre Julliard : > Daniel Jelinski writes: > >> These are tests for bug 32529. Since commit >> ebaf5ea17623268fb1c0f68b1cf9a5984bd4e46e >> (Don't load bitmap glyphs when using subpixel rendering in GetGlyphOutline) >> GetTextExtentPoint returns different results before and after glyphs are >> loaded, >> at least for wine's Tahoma. > > I don't see that here: > > ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p > gdi32_test.exe.so font.c && touch font.ok > font.c:4818: Test succeeded inside todo block: extents different: first 76, > second 76 That is strange, I checked with yesterday's git and got an error (75/70 if I remember correctly). I'll try to check which font is used. Regards, Daniel
Re: comctl32/listview: fix icon spacing calculation [try 2]
2013/1/14 Nikolay Sivov : > It's a way it's used in ListView_SetIconSpacing() (which could be broken in > its own way of course). > I think it's ok to ignore this 64 bit case for now, especially while we > don't get daily test runs. Are you saying that I should drop this? -return LISTVIEW_SetIconSpacing(infoPtr, (short)LOWORD(lParam), (short)HIWORD(lParam)); +if(lParam == -1) + return LISTVIEW_SetIconSpacing(infoPtr, -1, -1); +return LISTVIEW_SetIconSpacing(infoPtr, LOWORD(lParam), HIWORD(lParam)); This would net us 2 more todo_wine tests. Also, what's up with the daily test runs? Will they be fixed any time soon?
Re: comctl32/listview: fix icon spacing calculation [try 2]
2013/1/14 Nikolay Sivov : > This message actually is supposed to be used with MAKELONG(), so it's not > truncated in such way. Probably (MSDN doesn't say a word about the preferred macro for this function, unless you count user comments), however if any app actually calls MAKELPARAM, at least it will get the same result as on Windows.
Re: comctl32/listview: fix icon spacing calculation [try 2]
2013/1/14 Nikolay Sivov : > So on 64bit you want to distinguish two cases: > - ~0 value of lParam - you use it to reset to default values; > - all other values including 0x that will result in the same call > with both args being -1. Unless I got something wrong, all other values including 0x will result in a call with both args being 65535. Since parameters are INTs now, 65535 != -1. The tests show that: SendMessage(hwnd, LVM_SETICONSPACING, 0, MAKELPARAM(-1,-1)); results in default spacing on 32bit and (65535,65535) on 64bit. MAKELPARAM(-1,-1) == (DWORD)-1 MAKELONG(-1,-1) == -1
testbot
Hello, the testbot does not revert patches submitted through testbot.winehq.org after testing. As a result it is almost impossible to test another patch affecting the same area in code as a previous one. Could anyone please fix it? Or at least add git reset to cron... Regards, Daniel
Re: comctl32/listview: fix icon spacing calculation [try 2]
2013/1/14 Nikolay Sivov : > On 1/15/2013 00:53, Daniel Jelinski wrote: > >> +if(lParam == -1) >> + return LISTVIEW_SetIconSpacing(infoPtr, -1, -1); >> +return LISTVIEW_SetIconSpacing(infoPtr, LOWORD(lParam), >> HIWORD(lParam)); > > Why do you need to handle this case specially? If it's -1 for 64bit comctl32 > it should give you the same values with HIWORD/LOWORD as it does for 32bit. On 64bit the behavior with lParam=0x is different from that with lParam=-1. HIWORD/LOWORD values are the same, so without this special case they would behave the same way.
Re: comctl32/listview: fix calculating item height
Interesting: https://testbot.winehq.org/JobDetails.pl?Key=23746&log_206=1#k206 Looks like testbot tried to do the entire test suite, even though I changed only one test file. 2013/1/5 Marvin : > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=23746 > > Your paranoid android. > > > === W2K8SE (32 bit listview) === > Failure running script in VM: The specified guest user must be logged in > interactively to perform this operation
Re: [9/9] server: Add support for named pipe message mode.
Hello, FWIW, Adam Martinson's named pipe series looks good to me. I tested it with MS SQL Server, which uses message mode pipes, and did not run into any problems. In current git I can't connect to server using named pipes, because as soon as SetNamedPipeHandleState returns false, client application aborts. (However, just changing SNPHS to return true is enough to get it working). I don't think patches 3 and 9 of this series can be split much more, except maybe for moving asserts into a separate file. Yes, reviewing them may cause headaches. The series is supposed to fix bugs 17273 (patch 8/9) and 17195 (patch 9/9). AFAICT the author is willing to make any adjustments necessary to get the patches merged. Patches 1-5 should not cause any problems if applied without the following. Patches 6-8 may cause regressions if applied without patch 9. Regards, Daniel
Re: Ubuntu 12.10 - anyone?
Thanks for all of your answers. Playing with wine in 11.10 is becoming near impossible because of the infamous xcb bug. I'd rather not mess with files outside /home, so I guess I'll be checking how well x86+PAE works. -- Daniel
Ubuntu 12.10 - anyone?
Hello, Is it possible to compile 32bit wine in 64bit ubuntu 12.10? I heard there were problems in 12.04 - were they resolved? Regards, Daniel
Re: [3/4] comctl32: fix notifications and return value when collapsing already collapsed node (rebased)
Hello, Nikolay. Thanks for reminder. Attached it now. 2012/10/15 Nikolay Sivov : > Hi, Daniel. > > You forgot a patch. >
Re: comctl32/listview: update dwStyle before checking for scrollbar
2012/9/22 Daniel Jelinski : > 2012/9/22 Nikolay Sivov : >> And apparently we have code in WM_STYLECHANGED handler to deal with scroll >> bars: >> >> --- >> if (((lpss->styleOld & WS_HSCROLL) != 0)&& >> ((lpss->styleNew & WS_HSCROLL) == 0)) >>ShowScrollBar(infoPtr->hwndSelf, SB_HORZ, FALSE); >> >> if (((lpss->styleOld & WS_VSCROLL) != 0)&& >> ((lpss->styleNew & WS_VSCROLL) == 0)) >>ShowScrollBar(infoPtr->hwndSelf, SB_VERT, FALSE); >> --- >> >> these lines were edited 10 years ago last time, sure it could be a noop >> but that raises a question why it's here. > > Dead code. I meant to remove these in the next patch, since there are > no bugs against scrollbars in listview. I guess user32 was way less > capable back then. Now that I think about it, it's not exactly dead code - it will be executed when someone tries to hide scrollbars by setting window style. Needs a more thorough review. Regards, Daniel
Re: comctl32/listview: update dwStyle before checking for scrollbar
2012/9/22 Nikolay Sivov : > I see. Now a question is how scroll bars are enabled/disabled in a case > you're trying to fix, > and a message test should be added for listview after that. What I'm seeing > - ControlSpy > running on XP shows style change messages after I toggle scrollbar bits, but > we don't have its source so > who knows what it does. Do you toggle these bits using SetWindowLong or SetScrollInfo? Wine uses SetScrollInfo, which is probably the reason why we don't get these messages. My first try at this bug was updating cached dwStyle in LISTVIEW_UpdateScroll: http://source.winehq.org/source/dlls/comctl32/listview.c#L2058 However, that was not sufficient for a sample application I created in Delphi - seems that Delphi creates the scrollbar elsewhere. Probably the code could be rewritten to not depend on WS_HSCROLL and WS_VSRCOLL being correct: http://source.winehq.org/source/dlls/comctl32/listview.c#L10881 is the only line that depends on it. > And apparently we have code in WM_STYLECHANGED handler to deal with scroll > bars: > > --- > if (((lpss->styleOld & WS_HSCROLL) != 0)&& > ((lpss->styleNew & WS_HSCROLL) == 0)) >ShowScrollBar(infoPtr->hwndSelf, SB_HORZ, FALSE); > > if (((lpss->styleOld & WS_VSCROLL) != 0)&& > ((lpss->styleNew & WS_VSCROLL) == 0)) >ShowScrollBar(infoPtr->hwndSelf, SB_VERT, FALSE); > --- > > these lines were edited 10 years ago last time, sure it could be a noop > but that raises a question why it's here. Dead code. I meant to remove these in the next patch, since there are no bugs against scrollbars in listview. I guess user32 was way less capable back then. Regards, Daniel
Re: comctl32/listview: update dwStyle before checking for scrollbar
Hello Nikolay, I'm not sure. There are some tests: http://source.winehq.org/source/dlls/user32/tests/msg.c#L1613 Comments indicate that some systems send WM_STYLECHANGED to windows with non-client area, and no systems send it to windows without it. I haven't figured out yet if the comment is true or to which category ListView belongs. Out of curiosity I checked which systems send WM_STYLECHANGED: http://testbot.winehq.org/JobDetails.pl?Key=21701 Vista and Windows 7 do send it, others do not, neither does Wine. Judging by the code it doesn't look like a quick fix to me (but I wouldn't mind if someone proved me wrong here). Regards, Daniel PS. I guess I should have used GetWindowLong instead on GetWindowLongPtr. Not sure if I should bother with resending now. 2012/9/22 Nikolay Sivov : > On 9/21/2012 23:07, Daniel Jelinski wrote: > >> dwStyle is updated only in WM_STYLECHANGED, which is not sent >> when displaying and hiding scrollbars. >> Fixes the issue where there was a large margin between items >> and horizontal scrollbar (e.g. in file open dialog). > > Are you sure it's really not supposed to be sent when WS_HSCROLL/WS_VSCROLL > bits are changed? > A quick test with ControlSpy shows style changing messages when I set/reset > these. So it's possible there's a bug > outside of comctl32.
Re: user32: search more aggressively for a window under a tooltip
2012/7/23 Alexandre Julliard : > Daniel Jelinski writes: > >> 2012/7/23, Alexandre Julliard : >>> You can't assume that the other Wine window is directly underneath the >>> transparent one, there may be some other X windows in between that >>> should receive the click instead. >> >> I just determined that in such cases Windows (at least 2008) silently >> eats the event - no windows get any click events. I can send the >> application (VS, C++) I used for testing. >> >> Should I update the patch to reflect that? > > Sure, and please add a test case too. > I just noticed that my patch for HTTRANSPARENT was rejected again. Were the tests not convincing enough? Regards, Daniel
Re: vcomp.dll, vcomp90.dll missing on testbot?
Hello, FWIW, comctl32 version 6 is accessible only with manifest, and there are tests that reference it. Here's an example: http://source.winehq.org/source/dlls/comctl32/tests/treeview.c#L1966 -- Daniel
What happened to testbot?
It seems that WINEBUILD has taken a break two days ago, no tasks involving building have been completed since then. Regards, Daniel
Re: user32: search more aggressively for a window under a tooltip
2012/7/23, Alexandre Julliard : > You can't assume that the other Wine window is directly underneath the > transparent one, there may be some other X windows in between that > should receive the click instead. I just determined that in such cases Windows (at least 2008) silently eats the event - no windows get any click events. I can send the application (VS, C++) I used for testing. Should I update the patch to reflect that? Daniel
Re: user32: search more aggressively for a window under a tooltip
Hello, When you say that this can't be fixed, do you mean that we can't properly route a mouse event if the window is transparent and it covers a window from another process? Well I'm not sure if Windows does that either. However, we don't need any X11 support to forward the message to another window on the same thread, and the applications in question need only that. If we can make these applications work, why don't we? Daniel 2012/7/23, Alexandre Julliard : > Daniel Jelinski writes: > >> Hello, >> Check out the description of HTTRANSPARENT on [1]. If MSDN is right >> here, then the code after applying my patch is still not correct, but >> at least closer to correct than it is now. >> As for a test case, do you prefer a minimalistic test case with one >> test that would be todo_wine without this patch and ok without it, or >> a massive test involving several overlapping windows belonging to >> different threads? > > This can't be fixed properly under X11, which is why the bug is marked > WONTFIX. Test cases won't help. > > -- > Alexandre Julliard > julli...@winehq.org >
Re: user32: search more aggressively for a window under a tooltip
Hello, Check out the description of HTTRANSPARENT on [1]. If MSDN is right here, then the code after applying my patch is still not correct, but at least closer to correct than it is now. As for a test case, do you prefer a minimalistic test case with one test that would be todo_wine without this patch and ok without it, or a massive test involving several overlapping windows belonging to different threads? Daniel [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms645618%28v=vs.85%29.aspx 2012/7/21 Dmitry Timoshkov : > Daniel Jelinski wrote: > >> Fixes bug 9512 and bug 8914, tested with Delphi and DVD Profiler. >> Still not perfect - according to MSDN the function should never return >> a window belonging to another thread. > > This kind of change requires a test case, and I suspect it's plain wrong. > > -- > Dmitry.
[1/2] comctl32: Fix message sequence when right-clicking a treeview
Resend from last month
From e9d9c543589ea2120ac39962d9820699b220a576 Mon Sep 17 00:00:00 2001
From: Daniel Jelinski
Date: Thu, 19 Apr 2012 22:02:25 +0200
Subject: comctl32: Fix message sequence when right-clicking a treeview
The message sequence obtained from testing native comctl32 was:
- first send NM_RCLICK
- then only if NM_RCLICK returned 0, send WM_CONTEXTMENU to parent
- send the above messages also when click was in empty area
This fixes the issue described in bug 19222.
---
dlls/comctl32/treeview.c | 36 ++--
1 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/dlls/comctl32/treeview.c b/dlls/comctl32/treeview.c
index 8c93f8c..9a14ba9 100644
--- a/dlls/comctl32/treeview.c
+++ b/dlls/comctl32/treeview.c
@@ -208,7 +208,6 @@ static VOID TREEVIEW_Invalidate(const TREEVIEW_INFO *,
const TREEVIEW_ITEM *);
static LRESULT TREEVIEW_DoSelectItem(TREEVIEW_INFO *, INT, HTREEITEM, INT);
static VOID TREEVIEW_SetFirstVisible(TREEVIEW_INFO *, TREEVIEW_ITEM *, BOOL);
static LRESULT TREEVIEW_EnsureVisible(TREEVIEW_INFO *, HTREEITEM, BOOL);
-static LRESULT TREEVIEW_RButtonUp(const TREEVIEW_INFO *, const POINT *);
static LRESULT TREEVIEW_EndEditLabelNow(TREEVIEW_INFO *infoPtr, BOOL bCancel);
static VOID TREEVIEW_UpdateScrollBars(TREEVIEW_INFO *infoPtr);
static LRESULT TREEVIEW_HScroll(TREEVIEW_INFO *, WPARAM);
@@ -4043,8 +4042,6 @@ TREEVIEW_TrackMouse(const TREEVIEW_INFO *infoPtr, POINT
pt)
else if (msg.message >= WM_LBUTTONDOWN &&
msg.message <= WM_RBUTTONDBLCLK)
{
- if (msg.message == WM_RBUTTONUP)
- TREEVIEW_RButtonUp(infoPtr, &pt);
break;
}
@@ -4259,31 +4256,18 @@ TREEVIEW_RButtonDown(TREEVIEW_INFO *infoPtr, LPARAM
lParam)
}
else
{
- SetFocus(infoPtr->hwnd);
- TREEVIEW_SendSimpleNotify(infoPtr, NM_RCLICK);
-}
-
-return 0;
-}
-
-static LRESULT
-TREEVIEW_RButtonUp(const TREEVIEW_INFO *infoPtr, const POINT *pPt)
-{
-TVHITTESTINFO ht;
-
-ht.pt = *pPt;
-
-TREEVIEW_HitTest(infoPtr, &ht);
-
-if (ht.hItem)
-{
-/* Change to screen coordinate for WM_CONTEXTMENU */
-ClientToScreen(infoPtr->hwnd, &ht.pt);
+SetFocus(infoPtr->hwnd);
+if (!TREEVIEW_SendSimpleNotify(infoPtr, NM_RCLICK))
+{
+/* Change to screen coordinate for WM_CONTEXTMENU */
+ClientToScreen(infoPtr->hwnd, &ht.pt);
-/* Send a WM_CONTEXTMENU message in response to the RBUTTONUP */
-SendMessageW(infoPtr->hwnd, WM_CONTEXTMENU,
-(WPARAM)infoPtr->hwnd, MAKELPARAM(ht.pt.x, ht.pt.y));
+/* Send a WM_CONTEXTMENU message in response to the RBUTTONUP */
+SendMessageW(infoPtr->hwndNotify, WM_CONTEXTMENU,
+(WPARAM)infoPtr->hwnd, MAKELPARAM(ht.pt.x, ht.pt.y));
+}
}
+
return 0;
}
--
1.7.5.4
ODBC on 64bit system
Hello all, Is it possible to run a 32bit application using 64bit ODBC drivers? I already checked that standard 32bit wine compilation does not work - but will it work with WoW64? I am trying to get an application to connect to SQL Server via tdsodbc, but unfortunately tdsodbc:i386 in ubuntu 11.10 is broken... Regards, Daniel
Re: Is it safe yet for developers to upgrade to Ubuntu 12.04?
I don't know about compiling, but there are several other reasons to keep waiting, listed here: http://forum.winehq.org/viewtopic.php?t=15802 Regards, Daniel 2012/6/25, Erich E. Hoover : > I know that for a while there were some packaging problems that meant that > upgrading to 12.04 made compiling 32-bit Wine on a 64-bit PC extremely > difficult. Is this still the case? I'd like to upgrade to the new OS > version, but I'm not willing to sacrifice the ability to build Wine in > order to do so. Thanks in advance! > > Erich Hoover > ehoo...@mines.edu >
Re: atl80: prefer native, if present
2012/6/18, Alexandre Julliard : > Daniel Jelinski writes: > >> From 7243b3594c9c0b13770ede1ab32d4dd1329b1dd4 Mon Sep 17 00:00:00 2001 >> From: Daniel Jelinski >> Date: Sun, 17 Jun 2012 17:37:15 +0200 >> Subject: atl80: prefer native, if present >> >> --- >> dlls/atl80/atl80.c | 11 +++ >> 1 files changed, 11 insertions(+), 0 deletions(-) > > There's no reason to do that, most of the dll is already implemented. It hides at least bug [1] from the end user, since the application comes with a bundled atl80 and works fine with it. It would probably also hide [2], since that application was reported to work under wine-1.4, so probably installs atl80 as well. Leaving it as-is means that users will need to set atl80 to native in order to get these applications to run properly, at least for the time being. Regards, Daniel [1] http://bugs.winehq.org/show_bug.cgi?id=30444 [2] http://bugs.winehq.org/show_bug.cgi?id=30906
Re: comctl: allow label edit only if treeview style allows editing
2012/6/4 Dan Kegel : > I had the same problem, and wrote a little script to skip the bad tests. > It was written for buildbot, but can be run standalone. > Try downloading > http://winezeug.googlecode.com/svn/trunk/buildbot/dotests.sh > and > http://winezeug.googlecode.com/svn/trunk/buildbot/dotests_blacklist.txt > then run > sh dotests.sh goodtests > That will skip all the tests known to hang or fail. (The list might be > a bit out of date, but it's easy to add new tests to the blacklist.) Now that's much better! Thank you. I slightly modified the script and found that 5 tests from the good list fail with native comctl. Good indicator of areas that need more love :) -- Regards, Daniel
Re: comctl: allow label edit only if treeview style allows editing
2012/6/4 Alexandre Julliard : > Daniel Jelinski writes: > >> From 21d26b76560f0c15a3d302883efa2d41d940a093 Mon Sep 17 00:00:00 2001 >> From: Daniel Jelinski >> Date: Sat, 2 Jun 2012 07:23:32 +0200 >> Subject: comctl: allow label edit only if treeview style allows editing >> >> Native comctl behaves this way - noticed when debugging regedit > > It breaks the tests: > > ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p > shell32_test.exe.so brsfolder.c && touch brsfolder.ok > brsfolder.c:225: Test failed: The new folder did not get the name foo > brsfolder.c:232: Test failed: SHBrowseForFolder did not return the pidl for > the new folder. Expected > 'Z:\home\julliard\wine\wine\dlls\shell32\tests\test_click_make_new_folder_button\foo' > got > 'Z:\home\julliard\wine\wine\dlls\shell32\tests\test_click_make_new_folder_button\New > Folder' > make: *** [brsfolder.ok] Error 2 Ah, thank you for this information. I'll look into it. I stopped doing make test on my machine some time ago, when I found out that some tests do consistently fail on my machine (clean prefix or not), and others consistently hang, thus preventing make test -k. I don't install wine-gecko, maybe that's the reason. -- Regards, Daniel
stub for SetThreadStackGuarantee
Hello, SQL Server Management Studio 2005 needs SetThreadStackGuarantee to either be absent or return TRUE - otherwise it refuses to run at all. Is there a reason for this stub to return FALSE? Regards, Daniel
Re: Testing regedit
2012/5/24 Austin English : > On Wed, May 23, 2012 at 12:24 PM, Daniel Jelinski > wrote: >> Hello, >> I just noticed that wine's regedit has a few interesting bugs that >> appear when running with native comctl32. Can I/should I file them in >> the bugzilla? >> >> Regards, >> Daniel > > What sort of bugs? In general, any bugs found with native dlls are suspect.. > > -- > -Austin One found with both native and builtin comctl32 - if you right-click a key and select New, the new one is created under the node that was last selected, not under the one that was right-clicked. This is different form windows regedit and can be confusing. Two others present with Windows comctl, but work correctly with wine's: - you can't edit names of keys - even when you add a new key - if you add a subkey to a key that did not have any subkeys before, the new subkey is not visible and the parent key is not expandable. After restarting regedit the keys are present and visible. Regards, Daniel
Testing regedit
Hello, I just noticed that wine's regedit has a few interesting bugs that appear when running with native comctl32. Can I/should I file them in the bugzilla? Regards, Daniel
Re: comctl32: Fix message sequence when right-clicking a treeview
Are there any tests I could use as a base? 2012/5/15 Nikolay Sivov : > On 5/15/2012 21:30, Daniel Jelinski wrote: >> >> Patch dropped out of the pending list, resending. > > Please add a test for this fix. >
Re: [1/2] comctl32/tests: Added tests for mouse events handling (try 3)
Hello, I see that my patch hasn't been accepted yet. Well if some explanation could help it through, here goes: Bug 19222 makes using MS SQL Server management studio a pain. The application displays database structure in a tree view, and most actions are executed from a context menu displayed by right-clicking on a relevant position in the tree view. Unfortunately Wine suffers from a bug - right click displays the menu, but selecting any option from the menu causes another menu to be displayed at the current mouse position. Selecting an option from this second menu works as expected. Also opening the popup menu by pressing context menu key on the keyboard works properly. The usual suspect in such cases is that incorrect messages are sent, or messages are sent in incorrect order. I tried to run the application with native comctl, but unfortunately it refused to work - probably comctl version 6.0 is required, while winetricks installs version 5.80. So I created my own application in Delphi. It dispayed the same problem with builtin comctl and worked correctly with native. Then I tested it with WINEDEBUG=+message. The outstanding differences were: - on native comctl treeview sent two messages to the main window - first WM_NOTIFY (NM_RCLICK) and then WM_CONTEXTMENU - on builtin comctl treeview sent first WM_CONTEXTMENU to self, which then got propagated to main window, and then WM_NOTIFY(NM_RCLICK). There was something peculiar - WM_RBUTTONUP never appeared in the logs. I checked to see why and found a function TREEVIEW_TrackMouse. This function is called by WM_RBUTTONDOWN handler and it captures all events from the message queue until it finds either WM_RBUTTONUP or WM_MOUSEMOVE with coordinates sufficiently far from the origin of the click. There was also a comment stating that "This is quite unusual piece of code, but that's how it's implemented in Windows.". Given the absence of WM_RBUTTONUP in message logs I consider this assertion to be true. With this knowledge I proceeded to write tests. I wanted to emulate right button down/up sequence. I couldn't send both messages by SendMessage, because SendMessage sends messages directly to the window procedure, and WM_RBUTTONUP has to be delivered by message queue. I also didn't want to push both messages to the queue - this would net me several more irrelevant messages like WM_PAINT and could cause failures if someone moved the (physical) mouse during the test. This is why I chose to post WM_RBUTTONUP and then send WM_RBUTTONDOWN. Later, thanks to our friendly bot Marvin, I found out that older versions of comctl sent WM_PAINT messages during the button down/button up sequence, bypassing the message queue. It took me several tries to find out which messages are sent, but now the patch works correctly on all tested comctl versions. Then I corrected Wine to pass the tests. I tested both applications (Microsoft's and mine) to see if they work correctly when the correct messages are sent. They do. If there is anything else I can do to help this patch get accepted, let me know. I'd like to have a clean git origin before I start fixing other treeview problems. Thanks for your patience, Daniel
Re: Regression testing
2012/4/12 Scott Ritchie : > On 4/12/12 1:23 AM, Daniel Jeliński wrote: >> >> Hello all, >> I am trying to get Microsoft SQL Server Management Studio to work >> flawlessly under Wine. For the most part I create and triage related bug >> reports, but recently I also started tinkering with code, specifically >> with comctl library, which I am most familiar with. >> >> Back on subject. I thought I found a regression - on Wine 1.4 package >> downloaded from launchpad the "New query" button works fine, while on my >> compiled Wine it produces an error. So I did: >> >> git reset --hard wine-1.4 >> make >> >> and, surprisingly, I still had the problem with the compiled version. >> However after some combination of deleting leftover files, running make >> clean, make depend and make the button started working, so I started >> bisecting, hoping for the best. At some point I started getting bad >> versions, and every subsequent compile was bad - even after I ended >> bisecting and returned to wine-1.4, the button still did not work (and >> it still works under packaged Wine - I use the same install for all >> tests). This time make clean && make depend && make did not help. >> > > Packaged Wine might be different for a few reasons: > > 1) It is a hybrid 32+64 build, which you can't get in one step on Ubuntu > 12.04 anymore > 2) It uses GCC-4.5 (12.04 default is 4.6) > 3) It has one small patch for fonts (shouldn't matter in your case) > 4) It's built in a clean environment on the build daemon > 5) It's installed and run out of tree. > > Thanks, > Scott Ritchie I eventually compiled a wine version that behaves like the packaged one - git clean did the trick. Also I'm still on 11.10 (waiting for a final release of 12.04). By the way I've got the results of bisection. The first bad commit was "atl80: New dll.". I guess this won't be an easy fix... Daniel
Re: Regression testing
Marcus, Alexey, thank you for your ideas. I just did several builds to see how to make things work. Here's what I got: make clean && make - does not work (the problem persists) make distclean && ./configure && make - same as above git clean -xdf && ./configure && make - this one finally worked. I'm not sure what's the difference between the above, but I'm going to stick to git clean for the time being. Thanks again Daniel
Re: [1/2] comctl32/tests: Added tests for mouse events handling (try 3)
2012/4/8 Dmitry Timoshkov :
> Daniel Jelinski wrote:
>
>> Skipping tests on WinNT - older versions of comctl send a different
>> set of events.
>
> Then you need to figure out what is different, and make the tests pass
> there as well (there is 'optional' flag for that), otherwise you risk
> breaking applications written for NT.
Okay, I'll do that. I thought that since comctl is supposed to be
backwards compatible, I'll write the tests to just pass on the newer
version.
>> + /* WM_RBUTTONDOWN does not return until it gets another mouse event.
>> + Make sure it gets one by posting WM_RBUTTONUP to message queue */
>> + PostMessageA(hTree, WM_RBUTTONUP, 0, (LPARAM)0x10001);
>> + /* this sequence should NOT send WM_CONTEXTMENU */
>> + SendMessageA(hTree, WM_RBUTTONDOWN, 2, (LPARAM)0x10001);
>> +
>> + /* ditch the first sequence as it processed more messages than we need.
>> Redo */
>> + flush_sequences(sequences, NUM_MSG_SEQUENCES);
>> +
>> + PostMessageA(hTree, WM_RBUTTONUP, 0, (LPARAM)0x10001);
>> + SendMessageA(hTree, WM_RBUTTONDOWN, 2, (LPARAM)0x10001);
>
> This can't work. If you use PostMessage you need to flush message queue before
> testing the sequence. Using SendMessage after PostMessage doesn't guarantee
> that a posted message is handled before a sent one, you may try generating
> hardware messages instead.
I want the posted message to be handled after the sent one, and I get
exactly that. The event handler for WM_RBUTTONDOWN captures all
messages until it finds one of the mouse-related events, so I needed
to post WM_RBUTTONUP first to make sure that SendMessage returns.
Hardware messages are an alternative, but I couldn't find any relevant
examples, so I followed the path of least resistance.
The first PostMessage/SendMessage sequence flushes the message queue,
or at least its interesting part. There are probably better ways
(PeekMessage/DispatchMessage loop comes to mind), but this one just
works.
>
>> +
>> + if(sequences[PARENT_SEQ_INDEX]->sequence->message == 0x133)
>> + {
>> + win_skip("Comctl32 versions prior to 5.80 send different set of
>> events");
>> + return;
>> + }
>
> Please use symbolic names for messages instead of magic numbers.
Ok, can do.
Best regards,
Daniel
