On 3/9/2013 10:03, Daniel Jelinski wrote:
Makes sense, thanks. I briefly searched for such cases and
LISTVIEW_FindItemW() seems to be broken the same way.
er: 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 MOUSEM
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 whe
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 bu
On 2/24/2013 01:33, Daniel Jelinski wrote:
@@ -10178,6 +10139,19 @@ static LRESULT LISTVIEW_LButtonDown(LISTVIEW_INFO
*infoPtr, WORD wKey, INT x, IN
if (infoPtr->dwLvExStyle & LVS_EX_ONECLICKACTIVATE)
if(lvHitTestInfo.iItem != -1)
notify_itemactivate(infoPtr,&lvHitTestInfo);
On 2/21/2013 11:01, Daniel Jelinski wrote:
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.
Sure, I get it. The problem is that it's not a correct way to fix that.
Such hack is ok to attac
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 fixi
On 2/21/2013 02:19, Daniel Jelinski wrote:
/* disable per item notifications on LVS_OWNERDATA style
FIXME: single LVN_ODSTATECHANGED should be used */
bOldChange = infoPtr->bDoChangeNotify;
-if (infoPtr->dwStyle & LVS_OWNERDATA) infoPtr->bDoChangeNotify = FALSE;
+/*i
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=24327
Your paranoid android
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=24257
Your paranoid android
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=24256
Your paranoid android
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=24258
Your paranoid android
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 b
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
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=24025
Your paranoid android
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=24026
Your paranoid android
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_SetI
On 1/15/2013 01:53, Daniel Jelinski wrote:
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 ap
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 w
On 1/15/2013 01:43, Daniel Jelinski wrote:
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 somet
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
On 1/15/2013 01:15, Daniel Jelinski wrote:
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
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
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
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=23921
Your paranoid android
is not the same as MAKELPARAM(-1,-1) in 64bit listview */
+if(sizeof(LPARAM) == 8)
+{
+ret = SendMessage(hwnd, LVM_SETICONSPACING, 0, -1);
+todo_wine {
+expect(0x, LOWORD(ret));
+expect(0x, HIWORD(ret));
+}
+}
That means you should just use lParam =
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=23897
Your paranoid android
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=23861
Your paranoid android
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=23848
Your paranoid android
s not what you're asking for.
I mean to test that header gets image list after it's set for listview,
and that same handle is reused.
2013/1/5 Nikolay Sivov :
On 1/6/2013 02:25, Daniel Jelinski wrote:
This one needs tests. Also even if each patch applies cleanly, please send
them in
On 1/6/2013 02:25, Daniel Jelinski wrote:
This one needs tests. Also even if each patch applies cleanly, please
send them in series, it makes it easier to review.
nk 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 runni
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) ===
anoid android.
=== W2K8SE (32 bit listview) ===
Failure running script in VM: The specified guest user must be logged in
interactively to perform this operation
q.org/JobDetails.pl?Key=23728
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
This happens for all patches for this VM, so it's unrelated.
anoid android.
=== W2K8SE (32 bit listview) ===
Failure running script in VM: The specified guest user must be logged in
interactively to perform this operation
> ---
>>
>> 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 wa
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 t
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 do
nt 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
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
Vitaliy Margolen writes:
> I'm guessing AJ doesn't care much about such details. So NVM.
>
> Anyone want's to remove any requirements to wine tests? As long as
> they compile and pass on AJ's pc, is seems to be the only requirement.
The tests are supposed to succeed. Writing fancy failure messag
I'm guessing AJ doesn't care much about such details. So NVM.
Anyone want's to remove any requirements to wine tests? As long as they
compile and pass on AJ's pc, is seems to be the only requirement.
Vitaliy.
On 05/09/2011 08:42 AM, Nikolay Sivov wrote:
On 5/9/2011 17:39, Vitaliy Margolen wr
On 5/9/2011 17:39, Vitaliy Margolen wrote:
On 05/09/2011 01:09 AM, Nikolay Sivov wrote:
Fix for http://bugs.winehq.org/show_bug.cgi?id=25908
There are 3 separate changes in this patch:
-BOOL bSame;
+BOOL same;
Variable name rename.
I don't think it's a big deal.
The actual fix wi
On 05/09/2011 01:09 AM, Nikolay Sivov wrote:
Fix for http://bugs.winehq.org/show_bug.cgi?id=25908
There are 3 separate changes in this patch:
-BOOL bSame;
+BOOL same;
Variable name rename.
The actual fix with new test.
+ok(g_editbox_disp_info.item.pszText != NULL, "got %p\n",
Some minor things regarding listview.
On Wed, Apr 13, 2011 at 7:33 AM, Detlef Riekenberg wrote:
> ---
> dlls/inetcpl.cpl/security.c | 131
> +++
> 1 files changed, 131 insertions(+), 0 deletions(-)
>
> +static void add_zone_to_listvi
anoid android.
=== WNT4WSSP6 (32 bit listview) ===
listview.c:397: Test failed: buffer size 264
listview.c:397: Test failed: buffer size 264
listview.c:397: Test failed: buffer size 264
listview.c:397: Test failed: buffer size 264
listview.c:397: Test failed: buffer size 264
listview.c:397: Test f
anoid android.
=== WNT4WSSP6 (32 bit listview) ===
listview.c:397: Test failed: buffer size 264
listview.c:397: Test failed: buffer size 264
listview.c:397: Test failed: buffer size 264
listview.c:397: Test failed: buffer size 264
listview.c:397: Test failed: buffer size 264
listview.c:397: Test f
q.org/JobDetails.pl?Key=7103
Your paranoid android.
=== W7PRO (32 bit listview) ===
listview.c:4458: Test failed: NM_HOVER allow test: the msg sequence is not
complete: expected 0087 - actual
listview.c:4463: Test failed: NM_HOVER block test: the msg sequence is not
complete: expected 0087 - actual
droid.
=== W7PRO (32 bit listview) ===
listview.c:4458: Test failed: NM_HOVER allow test: the msg sequence is not
complete: expected 0087 - actual
listview.c:4463: Test failed: NM_HOVER block test: the msg sequence is not
complete: expected 0087 - actual
=== W7PROX64 (32 bit lis
can be found at
> http://testbot.winehq.org/JobDetails.pl?Key=5396
>
> Your paranoid android.
>
>
> === W2K8SE (32 bit listview) ===
> listview.c:4433: Test failed: NM_HOVER allow test: the msg sequence is not
> complete: expected 0087 - actual
> listview.c:4438: Test fa
droid.
=== W2K8SE (32 bit listview) ===
listview.c:4433: Test failed: NM_HOVER allow test: the msg sequence is not
complete: expected 0087 - actual
listview.c:4438: Test failed: NM_HOVER block test: the msg sequence is not
complete: expected 0087 - actual
=== W7PROX64 (32 bit lis
droid.
=== W98SE (32 bit listview) ===
listview.c:2214: Test failed: got 1
=== WNT4WSSP6 (32 bit listview) ===
listview.c:2214: Test failed: got 1
=== W2KPROSP4 (32 bit listview) ===
listview.c:2214: Test failed: got 1
=== WXPPROSP3 (32 bit listview) ===
listview.c:2214: Test failed:
droid.
=== W7PRO (32 bit listview) ===
listview.c:4393: Test failed: NM_HOVER allow test: the msg sequence is not
complete: expected 0087 - actual
listview.c:4398: Test failed: NM_HOVER block test: the msg sequence is not
complete: expected 0087 - actual
q.org/JobDetails.pl?Key=2163
Your paranoid android.
=== W7PRO (32 bit listview) ===
listview.c:4393: Test failed: NM_HOVER allow test: the msg sequence is not
complete: expected 0087 - actual
listview.c:4398: Test failed: NM_HOVER block test: the msg sequence is not
complete: expected 0087 - a
droid.
=== W7PRO (32 bit listview) ===
listview.c:4393: Test failed: NM_HOVER allow test: the msg sequence is not
complete: expected 0087 - actual
listview.c:4398: Test failed: NM_HOVER block test: the msg sequence is not
complete: expected 0087 - actual
On 5/18/2010 02:36, Andrew Eikum wrote:
The old code used the containing item's position to determine the
subitem's rect. Instead, we should be using the entire listview's
origin as the offset, since the item position can change as columns
are inserted and re-arranged, leading to broken listvie
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=1735
Your paranoid android.
On 02/18/2010 01:46 PM, Dmitry Timoshkov wrote:
Listview receives notifications not only from built-in header control,
but also from custom or subclassed application controls, there is no
need to assert(0) on application input, printing a FIXME is the maximum
we can do on an unknown input
On 2/18/2010 15:46, Dmitry Timoshkov wrote:
Listview receives notifications not only from built-in header control,
but also from custom or subclassed application controls, there is no
need to assert(0) on application input, printing a FIXME is the maximum
we can do on an unknown input.
The
Hello,
I am seeing something in listview.c that really make me feel like
there is something really wrong going on. So maybe it is something I am
having a lack of understanding in.
I have an application that is sending 'A' style notification codes to
the listview header. Spec
Jeff Latimer wrote:
On 06/12/09 18:56, Nikolay Sivov wrote:
Jeff Latimer wrote:
---
dlls/comctl32/listview.c |2 +-
dlls/comctl32/tests/listview.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Hi, Jeff.
This is obviously wrong. Test will fail on native systems after y
On 06/12/09 18:56, Nikolay Sivov wrote:
Jeff Latimer wrote:
---
dlls/comctl32/listview.c |2 +-
dlls/comctl32/tests/listview.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Hi, Jeff.
This is obviously wrong. Test will fail on native systems after your
patch.
Why do y
Jeff Latimer wrote:
---
dlls/comctl32/listview.c |2 +-
dlls/comctl32/tests/listview.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Hi, Jeff.
This is obviously wrong. Test will fail on native systems after your patch.
What is a problem with current code, any bugs repor
Nikolay Sivov schrieb:
> Hi, Andre.
>
> Could you please wait with that? I have some similar patches already sent...
>
> On 11/16/09, André Hentschel wrote:
>> Otherwise Apps crash on exit(e.g. uninstaller)
>> ---
>> dlls/comctl32/imagelist.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 d
Hi, Andre.
Could you please wait with that? I have some similar patches already sent...
On 11/16/09, André Hentschel wrote:
> Otherwise Apps crash on exit(e.g. uninstaller)
> ---
> dlls/comctl32/imagelist.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/com
Hi Nikolay,
I don't think you need such duplication. Why not to use a single
rectangle? Looks like you always offset it to listview origin,
so these rectangle differ in offset only, that's why you introduced
another iterator_* helper. If I'm right about that it's b
Owen Rudge wrote:
Hi Nikolay,
I don't think you need such duplication. Why not to use a single
rectangle? Looks like you always offset it to listview origin,
so these rectangle differ in offset only, that's why you introduced
another iterator_* helper. If I'm right about that
Hi Nikolay,
I don't think you need such duplication. Why not to use a single
rectangle? Looks like you always offset it to listview origin,
so these rectangle differ in offset only, that's why you introduced
another iterator_* helper. If I'm right about that it's b
Owen Rudge wrote:
This patch adds support for scrolling a listview when performing a
marquee selection. In Windows, a listview will scroll around when
dragging and highlighting icons, picking up speed as you move the
mouse further past the window.
Hi, Owen.
This patch is rather large, so
d not-on-item. Also you may want to look at message list for
ListView window (on wine it doesn't work and I mean native system here)
- after SetFocus() ListView get WM_SETFOCUS, it allows to determine when
we should to call SetFocus(), I'm not sure maybe NM_SETFOCUS is an
always
Hi Nikolay,
This doesn't look right. Try with ControlSpy and you'll see WM_SETFOCUS
sent just after LButton pressed on
client area (not on item, that's important). LButtonUp event used to set
focus item was under mouse pointer and it's
released without any mouse movements (or maybe drag thresho
Owen Rudge wrote:
This patch fixes an issue whereby a selection marquee would not
function correctly when the listview hadn't first been clicked on.
---
dlls/comctl32/listview.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
@@ -3631,6 +3631,9 @@ static LR
ith a single 'Default' item
only, that's what I tried with.
Then start marquee selection after selecting an item move pointer
somewhere outside the list - try to left and up. It crashes after
that for me in ListView code
This is indeed a bug, I should have validated that the co
inter somewhere outside the list - try to left and up. It crashes after that
for me in ListView code
This is indeed a bug, I should have validated that the coordinates
passed to the hit test were within the window bounds. I've submitted a
fix for this, which also fixes the selection recta
performing a listview marquee selection.
---
New bugs here:
- open regedit and select any branch from tree - list will display a
single item. Then start marquee selection after selecting an item move
pointer
somewhere outside the list - try to left and up. It crashes after that
for me in
Hi Nikolay,
Didn't test it much yet, but few issues from a start:
I'll look into these issues and try to submit a fix as soon as possible.
Cheers,
--
Owen Rudge
http://www.owenrudge.net/
(marquee) selection support in listview.
---
Hi, Owen.
Didn't test it much yet, but few issues from a start:
- when control doesn't have focus rectangle is visible, but it doesn't
select anything;
- during resizing rectangle and moving pointer outside client area
rectangle
:). Now we have 3 different names for a single thing.
D'oh! Let's try this one last time... ;)
--
Owen Rudge
http://www.owenrudge.net/
Owen Rudge wrote:
Minor update, rename some potentially confusing comments/variables.
---
dlls/comctl32/listview.c | 135
-
1 files changed, 120 insertions(+), 15 deletions(-)
+/* Draw focus rect if highlighting */
+if (infoPtr->bHighlight
Hi Nikolay,
Focus rectangle is an item focus bounds in current naming, so comment is
a bit confusing here.
Ah, yes, that seems sensible - I named it "focus rectangle" as that's
what the API function was called, but of course the way it's used would
lend itself better to different nomenclatur
Owen Rudge wrote:
This patch adds support for selecting multiple items in a
multi-selection listview using the mouse (by dragging and
highlighting). It has been reimplemented in a more efficient manner
compared to the previous patches.
---
dlls/comctl32/listview.c | 135
Owen Rudge wrote:
Hi Nikolay,
Why do you need this restoring code?
I tried to replicate the way that Windows did the selections. Testing
various manners of selection with Windows Explorer, that code was
needed for a relatively specific scenario:
If you're starting a selection box with som
Hi Nikolay,
Why do you need this restoring code?
I tried to replicate the way that Windows did the selections. Testing
various manners of selection with Windows Explorer, that code was needed
for a relatively specific scenario:
If you're starting a selection box with some items already sel
Owen Rudge wrote:
These patches add support for selecting multiple items in a
multi-selection listview using the mouse (by dragging and highlighting).
---
dlls/comctl32/listview.c | 172
++
1 files changed, 157 insertions(+), 15 deletions(-)
Hi
Alexandre Julliard wrote:
Nikolay Sivov writes:
diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c
index a65d832..9bca376 100644
--- a/dlls/comctl32/listview.c
+++ b/dlls/comctl32/listview.c
@@ -9740,6 +9740,8 @@ static LRESULT LISTVIEW_Paint(LISTVIEW_INFO *infoPtr, HDC
hdc)
Nikolay Sivov writes:
> diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c
> index a65d832..9bca376 100644
> --- a/dlls/comctl32/listview.c
> +++ b/dlls/comctl32/listview.c
> @@ -9740,6 +9740,8 @@ static LRESULT LISTVIEW_Paint(LISTVIEW_INFO *infoPtr,
> HDC hdc)
> {
> TRACE("(
Hi.
Yesterday I attached a patch to fix longstanding bug
http://bugs.winehq.org/show_bug.cgi?id=3231 .
It fixes this issue, and I hope doesn't produce any new ones. Now I need
to test it on
a wide range of applications you use every day.
If you spotted any new issues after it please let me kn
Paul Vriens wrote:
Nikolay Sivov wrote:
Changelog:
- Basic LVM_GETVIEWRECT tests
+todo_wine expect(104, rect.right);
+expect(0, rect.top);
+expect(73, rect.bottom);
The first and last one of these 3 introduces errors on several boxes
(see test.winehq.org). I guess these numbe
Nikolay Sivov wrote:
Changelog:
- Basic LVM_GETVIEWRECT tests
+todo_wine expect(104, rect.right);
+expect(0, rect.top);
+expect(73, rect.bottom);
The first and last one of these 3 introduces errors on several boxes
(see test.winehq.org). I guess these numbers can't be hardcode
Stefan Stranz wrote:
Fixes bug #13867
Original fix by GameZelda
A test needed for such changes. Especially for that part:
@@ -519,7 +519,7 @@ static inline int textcmpWT(LPCWSTR aw, LPCWSTR bt, BOOL
isW)
if (!aw) return bt ? -1 : 0;
if (!bt) return aw ? 1 : 0;
if (aw == LPSTR_TEXTC
Paul Vriens wrote:
Nikolay Sivov wrote:
Paul Vriens wrote:
Nikolay Sivov wrote:
Changelog:
- Additional tests for LVM_GETSUBITEMRECT
From 2f2cb8e54b81ff6be7229b7931945a3bb76f4bde Mon Sep 17 00:00:00
2001
From: Nikolay Sivov
Date: Wed, 22 Apr 2009 13:05:56 -0400
Subject: Additional test
Nikolay Sivov wrote:
Paul Vriens wrote:
Nikolay Sivov wrote:
Changelog:
- Additional tests for LVM_GETSUBITEMRECT
From 2f2cb8e54b81ff6be7229b7931945a3bb76f4bde Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Wed, 22 Apr 2009 13:05:56 -0400
Subject: Additional tests for LVM_GETSUBITEM
Paul Vriens wrote:
Nikolay Sivov wrote:
Changelog:
- Additional tests for LVM_GETSUBITEMRECT
From 2f2cb8e54b81ff6be7229b7931945a3bb76f4bde Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Wed, 22 Apr 2009 13:05:56 -0400
Subject: Additional tests for LVM_GETSUBITEMRECT
---
dlls/comctl
Nikolay Sivov wrote:
Changelog:
- Additional tests for LVM_GETSUBITEMRECT
From 2f2cb8e54b81ff6be7229b7931945a3bb76f4bde Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Wed, 22 Apr 2009 13:05:56 -0400
Subject: Additional tests for LVM_GETSUBITEMRECT
---
dlls/comctl32/tests/listview.c
On Mon, Jan 26, 2009 at 4:29 PM, Michael James wrote:
> Here are two simple fixes before I attempt anything more complex here.
>
> Michael James
>
> From d978eb3c3eff3b44fce6257892749c2c1c34277d Mon Sep 17 00:00:00 2001
> From: Michael James
> Date: Sun, 25 Jan 2009 20:09:33 -0800
> Subject: [PAT
Listview has a test to ensure that sending a LVM_SETIMAGELIST between
WM_NCCREATE and WM_CREATE works fine.
The problem is that this causes the conformance test to crash on my
Windows 98 OSR0 VM. Right on this line:
static LRESULT CALLBACK create_test_wndproc(HWND hwnd, UINT uMsg, WPARAM
På Torsdag 28 august 2008 , 00:29:03 skrev Alexander Nicolaysen Sørnes:
> Should be applied after Juan's regedit patch
>
>
> Alexander N. Sørnes
Sorry, mean't Lei's. No offence intended. :D
On Mon, Aug 18, 2008 at 4:08 PM, Lei Zhang <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This should fix bug 14908.
>
Any problems with this patch?
Hi Owen,
+ IDS_COLUMN_TITLE_1, "Name"
+ IDS_COLUMN_TITLE_2, "Publisher"
+ IDS_COLUMN_TITLE_3, "Version"
These seem like rather poor names for the string IDs. Why not e.g.
IDS_COLUMN_NAME or simply IDS_NAME?
+/* Definition of column headers for AddListViewColumns function */
+#define NUM_CO
1 - 100 of 203 matches
Mail list logo
