Re: Add Intel GM45 detection
Jaime Rave wrote:
> --- a/dlls/wined3d/directx.c
> +++ b/dlls/wined3d/directx.c
> @@ -1109,7 +1109,8 @@ static const struct gpu_description
> gpu_description_table[] =
> {HW_VENDOR_INTEL, CARD_INTEL_I915G, "Intel(R)
> 82915G/GV/910GL Express Chipset Family", DRIVER_INTEL_GMA900, 64 },
> {HW_VENDOR_INTEL, CARD_INTEL_I915GM, "Mobile Intel(R)
> 915GM/GMS,910GML Express Chipset Family", DRIVER_INTEL_GMA900, 64 },
> {HW_VENDOR_INTEL, CARD_INTEL_I945GM, "Mobile Intel(R)
> 945GM Express Chipset Family", DRIVER_INTEL_GMA950, 64 },
> -{HW_VENDOR_INTEL, CARD_INTEL_X3100, "Mobile Intel(R)
> 965 Express Chipset Family",DRIVER_INTEL_GMA3000, 128}
> +{HW_VENDOR_INTEL, CARD_INTEL_X3100, "Mobile Intel(R)
> 965 Express Chipset Family",DRIVER_INTEL_GMA3000, 128},
> +{HW_VENDOR_INTEL, CARD_INTEL_GM45, "Mobile Intel(R)
> GM45 Express Chipset Family",DRIVER_INTEL_GMA3000, 512}
> };
Please keep the spacing consistent.
--
Dmitry.
Re: msxml3/tests: Skip tests if IXMLDOMDocument2 can't be obtained
On 9/16/2010 02:27, Nikolay Sivov wrote: This is supposed to fix test bot failures. Please ignore this one.
Re: WineAPI wiki progress (resent)
On 09/15/2010 10:47 PM, Max TenEyck Woodbury wrote: Actually, that was a mistake on my part. If you use: https://sourceforge.net/apps/mediawiki/wineapi/index.php you can skip the login. ARGH! Make that: http://sourceforge.net/apps/mediawiki/wineapi/index.php - Max
Re: WineAPI wiki progress (resent)
On 09/15/2010 10:56 AM, Francois Gouget wrote: On Wed, 15 Sep 2010, Max TenEyck Woodbury wrote: The previous version ended up as a reply to something inappropriate. The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php now has pages for the directories in the Wine Repository with classifications of the directory content. Please take a look at it and tell me if you think the content is useful and how it could be improved. The first thing is that it requires a SourceForge login which is just wrong for what's supposed to be a public resource. Hopefully that's temporary but it's likely to limit who can comment on it. Actually, that was a mistake on my part. If you use: https://sourceforge.net/apps/mediawiki/wineapi/index.php you can skip the login. I don't see the point of creating one page for every single Wine source file. That makes the WineAPI website very very Wine-specific and duplicates GitWeb functionality. My understanding is that this is supposed to provide documentation about the Windows APIs in a more open, collaborative and long-term way than MSDN. People who come for the documentation won't care whether CreateFile is implemented in file.c or kernel_main.c and that Wine has a Makefile.in file or an nls subfolder. A little off point, but it points up an alternative. The process of scanning the repository is all I have in place at this point and I really should label the pages generated so far as Wine specific. That way other projects could produce similar pages specific to their structure. There is not a page for every file, only those that I intend to analyze. If I don't plan to analyze it, I simply provide a link to the file in the repository. I have *not* gotten started on the extraction of the API information. I plan to label each page of that type with an 'API/' prefix so that it would be common to multiple projects. I needed to get the framework in place so that I could the results where it will be possible to find them. Now that is done, the real work begins... - Max
Re: WineAPI wiki progress (resent)
On 09/15/2010 10:25 AM, GOUJON Alexandre wrote: On 09/15/2010 03:32 PM, Max TenEyck Woodbury wrote: The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php now has pages for the directories in the Wine Repository with classifications of the directory content. Well, to be frank, I don't like the structure. Doxygen is able to produce colored and well structured pages but it's not perfect. Personally, I prefer something like this [1] and this [2] for the detail. I know frames are something awful but in this case, this is quite handy. But it's just my thoughts. I hope you'll get more feedback. Many thanks for your efforts --- (I bookmarked the [1] some years ago so ignore the deprecated "1.5.0") [1]: http://download.oracle.com/javase/1.5.0/docs/api/ [2]: http://download.oracle.com/javase/1.5.0/docs/api/java/applet/AppletContext.html Nice examples... I'm not sure it would be practical to do that with the way Sourceforge has its standard MediaWiki app configured, and frankly I've not gotten around to figuring out how to install and configure MediaWiki de novo. Another problem is getting the descriptive information. I know a way to do it, but it would put a hell of a load on the Sourceforge server. It would also be very evil to edit. With several hundred directories to scan, I'm not sure the extra effort to add it to the top level directory analysis pages is going to be useful. I wanted to direct that effort to the working directory pages. - Max
Re: d3dx9_36: Implement D3DXCreateMesh and initial ID3DXMesh methods. (try 3)
Henri Verbeet wrote:
>
> On 15 September 2010 01:55, Misha Koshelev wrote:
>> +while (count < MAX_FVF_DECL_SIZE && (count == 0 ||
>> declaration[count-1].Stream != 0xFF))
>> +{
>> +count++;
>> +}
> ...and similarly you'd want to use D3DXGetDeclLength() here, though I
> wonder if implementing DrawSubset() isn't going to require creating a
> vertex declaration anyway.
>
>> +if (!ref)
>> +{
>> +if (This->index_buffer)
>> IDirect3DIndexBuffer9_Release(This->index_buffer);
>> +if (This->vertex_buffer)
>> IDirect3DVertexBuffer9_Release(This->vertex_buffer);
>> +if (This->device) IDirect3DDevice9_Release(This->device);
>> +HeapFree(GetProcessHeap(), 0, This);
>> +}
> In which cases can these be NULL?
>
>
>
>
Thank you as always for your valuable feedback.
Could you possible clarify your statement
"though I wonder if implementing DrawSubset() isn't going to require
creating a
vertex declaration anyway."
My understanding from
http://msdn.microsoft.com/en-us/library/bb205736%28v=VS.85%29.aspx
and
http://www.xmission.com/~legalize/book/download/19-D3DX%20Mesh%20Objects.pdf
is that DrawSubset will simply draw a subset of the triangles in a mesh...
Thank you
Misha
--
View this message in context:
http://wine.1045685.n5.nabble.com/Re-d3dx9-36-Implement-D3DXCreateMesh-and-initial-ID3DXMesh-methods-try-3-tp2840400p2841567.html
Sent from the Wine - Devel mailing list archive at Nabble.com.
Re: msxml3/tests: Skip tests if IXMLDOMDocument2 can't be obtained
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=5250 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6259: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6259: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6259: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154
Re: [PATCH] [Server]: ensure we set proper errors when getting a NULL fd out of a handle
Eric Pouech writes: > (would hang for example server_get_unix_fd when an improper handle was > passed, as no error > was returned from server call) > Fix for #24394. The individual get_fd() functions are supposed to set the appropriate error when returning NULL. -- Alexandre Julliard julli...@winehq.org
Re: ddraw: Allow creating back buffer for DirectX 1 interfaces.
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=5248 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found
Re: msxml3: Implement property SelectionNamespaces for XPath (try #3/resend)
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=5247 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6236: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6236: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6236: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154
Re: intention of stubs with arch flag, specially in msvcp*
Am 15.09.2010 19:44, schrieb Alexandre Julliard:
> André Hentschel writes:
>
>> The last one silently gets ignored, but the one with the arch flag causes
>> winebuild
>> to put some extra assembler code into the dll.
>>
>> So is this intented?
>
> No. Try something like this:
>
> diff --git a/tools/winebuild/parser.c b/tools/winebuild/parser.c
> index bc483c9..755084e 100644
> --- a/tools/winebuild/parser.c
> +++ b/tools/winebuild/parser.c
> @@ -385,7 +385,11 @@ static int parse_spec_stub( ORDDEF *odp, DLLSPEC *spec )
> {
> odp->u.func.nb_args = 0;
> odp->link_name = xstrdup("");
> -odp->flags |= FLAG_CPU(CPU_x86) | FLAG_CPU(CPU_x86_64); /* don't bother
> generating stubs for Winelib */
> +/* don't bother generating stubs for Winelib */
> +if (odp->flags & FLAG_CPU_MASK)
> +odp->flags &= FLAG_CPU(CPU_x86) | FLAG_CPU(CPU_x86_64);
> +else
> +odp->flags |= FLAG_CPU(CPU_x86) | FLAG_CPU(CPU_x86_64);
> return 1;
> }
>
thx
it works on arm. so as it is your code i would be glad if you add it please.
but i guess you have to exclude other flag from the override, tell me if you
have no time and i'll do it.
--
Best Regards, André Hentschel
Re: [Patch 5/5] Add some more schannel tests
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=5246 Your paranoid android. === WNT4WSSP6 (32 bit schannel) === No test summary line found
Re: intention of stubs with arch flag, specially in msvcp*
André Hentschel writes:
> The last one silently gets ignored, but the one with the arch flag causes
> winebuild
> to put some extra assembler code into the dll.
>
> So is this intented?
No. Try something like this:
diff --git a/tools/winebuild/parser.c b/tools/winebuild/parser.c
index bc483c9..755084e 100644
--- a/tools/winebuild/parser.c
+++ b/tools/winebuild/parser.c
@@ -385,7 +385,11 @@ static int parse_spec_stub( ORDDEF *odp, DLLSPEC *spec )
{
odp->u.func.nb_args = 0;
odp->link_name = xstrdup("");
-odp->flags |= FLAG_CPU(CPU_x86) | FLAG_CPU(CPU_x86_64); /* don't bother
generating stubs for Winelib */
+/* don't bother generating stubs for Winelib */
+if (odp->flags & FLAG_CPU_MASK)
+odp->flags &= FLAG_CPU(CPU_x86) | FLAG_CPU(CPU_x86_64);
+else
+odp->flags |= FLAG_CPU(CPU_x86) | FLAG_CPU(CPU_x86_64);
return 1;
}
--
Alexandre Julliard
julli...@winehq.org
intention of stubs with arch flag, specially in msvcp*
Hi all, I used to think the arch flag is only used to say "this function is only available on win32" or to say the same for win64. We do that e.g. in msvcp* dlls. So i am not sure why those stubs like @ stub -arch=win32 function differ so heavy from stubs like @ stub function The last one silently gets ignored, but the one with the arch flag causes winebuild to put some extra assembler code into the dll. So is this intented? If so, i would add ARM code for that case.(And we also should for other platforms) -- Best Regards, André Hentschel
Re: Different Wine FAQs on winehq
2010/9/15 Frédéric Delanoy : > A STFW for wine faq gives as first result this page > > http://www.winehq.org/site/docs/wine-faq/index (old version of the FAQ) > > instead of > > http://wiki.winehq.org/FAQ (linked from home > support) > > The former contains some outdated information. Shouldn't it be > suppressed (after a check to see if does contain helpful information > not found elsewhere) ? Yes. I filed a bug a while back for it, see http://bugs.winehq.org/show_bug.cgi?id=16992 -- -Austin
Re: WineAPI wiki progress (resent)
On Wed, 15 Sep 2010, Max TenEyck Woodbury wrote: > The previous version ended up as a reply to something inappropriate. > > The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php > now has pages for the directories in the Wine Repository with > classifications of the directory content. Please take a look at it and > tell me if you think the content is useful and how it could be improved. The first thing is that it requires a SourceForge login which is just wrong for what's supposed to be a public resource. Hopefully that's temporary but it's likely to limit who can comment on it. I don't see the point of creating one page for every single Wine source file. That makes the WineAPI website very very Wine-specific and duplicates GitWeb functionality. My understanding is that this is supposed to provide documentation about the Windows APIs in a more open, collaborative and long-term way than MSDN. People who come for the documentation won't care whether CreateFile is implemented in file.c or kernel_main.c and that Wine has a Makefile.in file or an nls subfolder. -- Francois Gouget http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Re: [msxml3/tests] Step to the next item on failure as well
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=5243 Your paranoid android. === W98SE (32 bit domdoc) === domdoc.c:6233: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === WNT4WSSP6 (32 bit domdoc) === domdoc.c:6233: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154 === W2KPROSP4 (32 bit domdoc) === domdoc.c:6233: Test failed: failed to create CLSID_DOMDocument instance: 0x80040154
Re: WineAPI wiki progress (resent)
On 15 September 2010 15:25, GOUJON Alexandre wrote: > On 09/15/2010 03:32 PM, Max TenEyck Woodbury wrote: >> >> The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php >> now has pages for the directories in the Wine Repository with >> classifications of the directory content. > > Well, to be frank, I don't like the structure. > Doxygen is able to produce colored and well structured pages but it's not > perfect. > Personally, I prefer something like this [1] and this [2] for the detail. > I know frames are something awful but in this case, this is quite handy. > > But it's just my thoughts. > I hope you'll get more feedback. > > Many thanks for your efforts > --- > (I bookmarked the [1] some years ago so ignore the deprecated "1.5.0") > > [1]: http://download.oracle.com/javase/1.5.0/docs/api/ > [2]: > http://download.oracle.com/javase/1.5.0/docs/api/java/applet/AppletContext.html The Qt documentation is also very good in terms of layout and content. IIUC, they use Doxygen for most (all?) of the documentation. - Reece
Re: WineAPI wiki progress (resent)
On 09/15/2010 03:32 PM, Max TenEyck Woodbury wrote: The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php now has pages for the directories in the Wine Repository with classifications of the directory content. Well, to be frank, I don't like the structure. Doxygen is able to produce colored and well structured pages but it's not perfect. Personally, I prefer something like this [1] and this [2] for the detail. I know frames are something awful but in this case, this is quite handy. But it's just my thoughts. I hope you'll get more feedback. Many thanks for your efforts --- (I bookmarked the [1] some years ago so ignore the deprecated "1.5.0") [1]: http://download.oracle.com/javase/1.5.0/docs/api/ [2]: http://download.oracle.com/javase/1.5.0/docs/api/java/applet/AppletContext.html
Re: [4/4] msxml3: Properly set default value for SelectionLanguage property
On 09/15/2010 04:11 PM, Paul Vriens wrote: On 09/14/2010 07:20 AM, Nikolay Sivov wrote: Properly set default value for SelectionLanguage property Hi Nikolay, I wondered why there were only a few testbot reports on test.winehq.org. Looking at the reports on test.winehq.org (I have an account) shows that the reports are filled (12000+ lines) with: domdoc.c:5649: Tests skipped: can't create CLSID_DOMDocument40 instance This makes sure that the reports are not even considered valid: wine:/home/winehq/opt/winetest/queue/errvyhFy$ more error dissect:error:/home/winehq/opt/winetest/queue/errvyhFy: report reached file limit (runaway test?) Found it, there should be an 'entry++' in the failure case. -- Cheers, Paul.
Different Wine FAQs on winehq
A STFW for wine faq gives as first result this page http://www.winehq.org/site/docs/wine-faq/index (old version of the FAQ) instead of http://wiki.winehq.org/FAQ (linked from home > support) The former contains some outdated information. Shouldn't it be suppressed (after a check to see if does contain helpful information not found elsewhere) ? Frédéric
Re: [4/4] msxml3: Properly set default value for SelectionLanguage property
On 09/14/2010 07:20 AM, Nikolay Sivov wrote: Properly set default value for SelectionLanguage property Hi Nikolay, I wondered why there were only a few testbot reports on test.winehq.org. Looking at the reports on test.winehq.org (I have an account) shows that the reports are filled (12000+ lines) with: domdoc.c:5649: Tests skipped: can't create CLSID_DOMDocument40 instance This makes sure that the reports are not even considered valid: wine:/home/winehq/opt/winetest/queue/errvyhFy$ more error dissect:error:/home/winehq/opt/winetest/queue/errvyhFy: report reached file limit (runaway test?) -- Cheers, Paul.
Re: [PATCH] shell32: use flexible arrays to avoid fortify failures
Henri Verbeet wrote: > On 14 September 2010 15:44, Mike Frysinger wrote: >> note: i couldnt find a statement of what C standard wine aims for. if >> it is attempting pre-c99, then this will have to be done differently. >> perhaps introducing a project-wide define like "VARARRAY" which >> expands into [] for c99+ and [1] for older ... >> > Roughly C89, C99 features are generally out. Hi, In the wine wiki it is stated that "Wine adheres to standard C89/C90." http://wiki.winehq.org/SubmittingPatches#head-7a578af49f1d1ab7f36f4b1f98b7544bb55eea9a Marko
Re: user32: Fix VK_RETURN handling in IsDialogMessage for dialogs without an IDOK
Hello Dmitry,
Wednesday, September 15, 2010, 11:30:38 AM, you wrote:
> It's better, but since BN_CLICKED is 0, there is no need to introduce wParam.
I reduced the patch to two lines (it's not visible from the context,
but there's a "return TRUE" lower to make up for the removed one).
Hopefully it's not too cryptic now. Thanks for the feedback.
--
Best regards,
Vladimirmailto:thecybersha...@gmail.com
From bc01fe0d6148c7da9302f07d8063f62a41e19349 Mon Sep 17 00:00:00 2001
From: Vladimir Panteleev
Date: Tue, 14 Sep 2010 16:46:55 +0300
Subject: user32: Fix VK_RETURN handling in IsDialogMessage for dialogs without
an IDOK
This fixes #23453 (both the app and attached MFC test case), #21295
(but not #22544), and #23936. A test is included.
---
dlls/user32/dialog.c |6 ++
dlls/user32/tests/dialog.c | 24
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/dlls/user32/dialog.c b/dlls/user32/dialog.c
index aac8a4d..052fbff 100644
--- a/dlls/user32/dialog.c
+++ b/dlls/user32/dialog.c
@@ -1221,10 +1221,8 @@ BOOL WINAPI IsDialogMessageW( HWND hwndDlg, LPMSG msg )
else if (DC_HASDEFID == HIWORD(dw = SendMessageW (hwndDlg,
DM_GETDEFID, 0, 0)))
{
HWND hwndDef = GetDlgItem(hwndDlg, LOWORD(dw));
-if (!hwndDef || !IsWindowEnabled(hwndDef))
-return TRUE;
-SendMessageW( hwndDlg, WM_COMMAND, MAKEWPARAM( LOWORD(dw),
BN_CLICKED ),
-(LPARAM)GetDlgItem(hwndDlg, LOWORD(dw)));
+if (hwndDef ? IsWindowEnabled(hwndDef) : LOWORD(dw)==IDOK)
+SendMessageW( hwndDlg, WM_COMMAND, MAKEWPARAM(
LOWORD(dw), BN_CLICKED ), (LPARAM)hwndDef);
}
else
{
diff --git a/dlls/user32/tests/dialog.c b/dlls/user32/tests/dialog.c
index b7727da..736c99d 100644
--- a/dlls/user32/tests/dialog.c
+++ b/dlls/user32/tests/dialog.c
@@ -1000,6 +1000,28 @@ static INT_PTR CALLBACK TestDefButtonDlgProc (HWND hDlg,
UINT uiMsg,
return FALSE;
}
+static INT_PTR CALLBACK TestReturnKeyDlgProc (HWND hDlg, UINT uiMsg,
+WPARAM wParam, LPARAM lParam)
+{
+static int received_idok = 0;
+switch (uiMsg)
+{
+case WM_INITDIALOG:
+{
+MSG msg = {hDlg, WM_KEYDOWN, VK_RETURN, 0x011c0001};
+IsDialogMessage(hDlg, &msg);
+}
+ok(received_idok, "WM_COMMAND not received\n");
+EndDialog(hDlg, 0);
+return TRUE;
+case WM_COMMAND:
+ok(wParam==IDOK, "Expected IDOK\n");
+received_idok = 1;
+return TRUE;
+}
+return FALSE;
+}
+
static void test_DialogBoxParamA(void)
{
INT_PTR ret;
@@ -1044,6 +1066,8 @@ static void test_DialogBoxParamA(void)
ret = DialogBoxParamA(GetModuleHandle(NULL), "TEST_EMPTY_DIALOG", 0,
TestDefButtonDlgProc, 0);
ok(ret == IDOK, "Expected IDOK\n");
+
+DialogBoxParamA(GetModuleHandle(NULL), "TEST_EMPTY_DIALOG", 0,
TestReturnKeyDlgProc, 0);
}
static void test_DisabledDialogTest(void)
--
1.7.0.4
Re: user32: Fix VK_RETURN handling in IsDialogMessage for dialogs without an IDOK
Hello Dmitry,
Wednesday, September 15, 2010, 10:35:20 AM, you wrote:
> It would be cleaner to use an existing SendMessage() instead of
> introducing a duplicate.
How does this look? I took the opportunity to remove the duplicate
"GetDlgItem(hwndDlg, LOWORD(dw))".
--
Best regards,
Vladimirmailto:thecybersha...@gmail.com
From a549da33e3dc5020558e8c2f62f706974d40a78b Mon Sep 17 00:00:00 2001
From: Vladimir Panteleev
Date: Tue, 14 Sep 2010 16:46:55 +0300
Subject: user32: Fix VK_RETURN handling in IsDialogMessage for dialogs without
an IDOK
This fixes #23453 (both the app and attached MFC test case), #21295
(but not #22544), and #23936. A test is included.
---
dlls/user32/dialog.c | 10 +++---
dlls/user32/tests/dialog.c | 24
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/dlls/user32/dialog.c b/dlls/user32/dialog.c
index aac8a4d..8038719 100644
--- a/dlls/user32/dialog.c
+++ b/dlls/user32/dialog.c
@@ -1220,11 +1220,15 @@ BOOL WINAPI IsDialogMessageW( HWND hwndDlg, LPMSG msg )
}
else if (DC_HASDEFID == HIWORD(dw = SendMessageW (hwndDlg,
DM_GETDEFID, 0, 0)))
{
+WPARAM wParam;
HWND hwndDef = GetDlgItem(hwndDlg, LOWORD(dw));
-if (!hwndDef || !IsWindowEnabled(hwndDef))
+if (!hwndDef && LOWORD(dw)==IDOK)
+wParam = IDOK;
+else if (!hwndDef || !IsWindowEnabled(hwndDef))
return TRUE;
-SendMessageW( hwndDlg, WM_COMMAND, MAKEWPARAM( LOWORD(dw),
BN_CLICKED ),
-(LPARAM)GetDlgItem(hwndDlg, LOWORD(dw)));
+else
+wParam = MAKEWPARAM( LOWORD(dw), BN_CLICKED );
+SendMessageW( hwndDlg, WM_COMMAND, wParam,
(LPARAM)hwndDef);
}
else
{
diff --git a/dlls/user32/tests/dialog.c b/dlls/user32/tests/dialog.c
index b7727da..736c99d 100644
--- a/dlls/user32/tests/dialog.c
+++ b/dlls/user32/tests/dialog.c
@@ -1000,6 +1000,28 @@ static INT_PTR CALLBACK TestDefButtonDlgProc (HWND hDlg,
UINT uiMsg,
return FALSE;
}
+static INT_PTR CALLBACK TestReturnKeyDlgProc (HWND hDlg, UINT uiMsg,
+WPARAM wParam, LPARAM lParam)
+{
+static int received_idok = 0;
+switch (uiMsg)
+{
+case WM_INITDIALOG:
+{
+MSG msg = {hDlg, WM_KEYDOWN, VK_RETURN, 0x011c0001};
+IsDialogMessage(hDlg, &msg);
+}
+ok(received_idok, "WM_COMMAND not received\n");
+EndDialog(hDlg, 0);
+return TRUE;
+case WM_COMMAND:
+ok(wParam==IDOK, "Expected IDOK\n");
+received_idok = 1;
+return TRUE;
+}
+return FALSE;
+}
+
static void test_DialogBoxParamA(void)
{
INT_PTR ret;
@@ -1044,6 +1066,8 @@ static void test_DialogBoxParamA(void)
ret = DialogBoxParamA(GetModuleHandle(NULL), "TEST_EMPTY_DIALOG", 0,
TestDefButtonDlgProc, 0);
ok(ret == IDOK, "Expected IDOK\n");
+
+DialogBoxParamA(GetModuleHandle(NULL), "TEST_EMPTY_DIALOG", 0,
TestReturnKeyDlgProc, 0);
}
static void test_DisabledDialogTest(void)
--
1.7.0.4
WineAPI wiki progress (resent)
The previous version ended up as a reply to something inappropriate. The wiki at https://sourceforge.net/apps/mediawiki/wineapi/index.php now has pages for the directories in the Wine Repository with classifications of the directory content. Please take a look at it and tell me if you think the content is useful and how it could be improved. None of the analysis of the file content is in place. I plan to start with analysis of the '.spec' files. That should make some of the information on the API available. - Max
Re: [PATCH] ole32: check for interface NULL which happens with e.g. Abiword
On Wed, Sep 15, 2010 at 12:40:46PM +0100, Huw Davies wrote:
> On Wed, Sep 15, 2010 at 01:34:06PM +0200, Marcus Meissner wrote:
> > On Wed, Sep 15, 2010 at 12:22:57PM +0100, Huw Davies wrote:
> > > On Wed, Sep 15, 2010 at 08:04:51PM +0900, Dmitry Timoshkov wrote:
> > > > Marcus Meissner wrote:
> > > >
> > > > > + if (!unk) {
> > > > > + FIXME("hr was %d, but unk is NULL?\n", hr);
> > > > > + return E_FAIL;
> > > > > + }
> > > >
> > > > IDropTarget_QueryInterface() should be fixed instead.
> > >
> > > The implementation is in abiword, so that would be tricky.
> > >
> > > Marcus, you're leaking a stream in this error path. Better
> > > to do something like:
> > >if(FAILED(hr) || !unk)
> >
> > yeah, but what error to return :/
>
> Yeah, sorry. Something like:
> if(!unk) hr = E_NOINTERFACE;
> right after the QI call.
I ran testbot, https://testbot.winehq.org/JobDetails.pl?Key=5239
and it also has 0 as hr for the case.
So returning failure might not be right approach.
Abiword has this code btw:
STDMETHODIMP XAP_Win32DropTarget::QueryInterface(REFIID /*riid*/,
LPVOID FAR* /*ppvObj*/)
{
return S_OK;
}
The fun...
Would erroring out be right?
If an interface directly inherits IUnknown, do we need a QueryInterface or
could we just cast?
Ciao, Marcus
Re: [PATCH] ole32: check for interface NULL which happens with e.g. Abiword
On Wed, Sep 15, 2010 at 01:34:06PM +0200, Marcus Meissner wrote:
> On Wed, Sep 15, 2010 at 12:22:57PM +0100, Huw Davies wrote:
> > On Wed, Sep 15, 2010 at 08:04:51PM +0900, Dmitry Timoshkov wrote:
> > > Marcus Meissner wrote:
> > >
> > > > + if (!unk) {
> > > > + FIXME("hr was %d, but unk is NULL?\n", hr);
> > > > + return E_FAIL;
> > > > + }
> > >
> > > IDropTarget_QueryInterface() should be fixed instead.
> >
> > The implementation is in abiword, so that would be tricky.
> >
> > Marcus, you're leaking a stream in this error path. Better
> > to do something like:
> >if(FAILED(hr) || !unk)
>
> yeah, but what error to return :/
Yeah, sorry. Something like:
if(!unk) hr = E_NOINTERFACE;
right after the QI call.
Huw.
Re: [PATCH] ole32: check for interface NULL which happens with e.g. Abiword
On Wed, Sep 15, 2010 at 12:22:57PM +0100, Huw Davies wrote:
> On Wed, Sep 15, 2010 at 08:04:51PM +0900, Dmitry Timoshkov wrote:
> > Marcus Meissner wrote:
> >
> > > + if (!unk) {
> > > + FIXME("hr was %d, but unk is NULL?\n", hr);
> > > + return E_FAIL;
> > > + }
> >
> > IDropTarget_QueryInterface() should be fixed instead.
>
> The implementation is in abiword, so that would be tricky.
>
> Marcus, you're leaking a stream in this error path. Better
> to do something like:
>if(FAILED(hr) || !unk)
yeah, but what error to return :/
Ciao, Marcus
Re: [PATCH] ole32: check for interface NULL which happens with e.g. Abiword
On Wed, Sep 15, 2010 at 08:04:51PM +0900, Dmitry Timoshkov wrote:
> Marcus Meissner wrote:
>
> > + if (!unk) {
> > + FIXME("hr was %d, but unk is NULL?\n", hr);
> > + return E_FAIL;
> > + }
>
> IDropTarget_QueryInterface() should be fixed instead.
I am not sure where where the DropTarget object comes from.
If it comes out of the marshaler, then its too much magic ;)
IRC identified in the meantime:
commit 6d1ef3a6a64f0fabf05ce1bba5f0ec4373684786
13:15 < igorko> Author: Huw Davies
13:15 < igorko> Date: Thu Jul 22 13:37:19 2010 +0100
13:15 < igorko> ole32: Implement cross-process drag and drop.
13:16 < igorko> :04 04 ab88cc6bf0936bc4adc7bff0673415282613d919
13:16 < igorko> 065c727204a46d01708bc01f10484cad8527e1a2 Mdlls
Ciao, Marcus
Re: [PATCH] ole32: check for interface NULL which happens with e.g. Abiword
On Wed, Sep 15, 2010 at 08:04:51PM +0900, Dmitry Timoshkov wrote:
> Marcus Meissner wrote:
>
> > + if (!unk) {
> > + FIXME("hr was %d, but unk is NULL?\n", hr);
> > + return E_FAIL;
> > + }
>
> IDropTarget_QueryInterface() should be fixed instead.
The implementation is in abiword, so that would be tricky.
Marcus, you're leaking a stream in this error path. Better
to do something like:
if(FAILED(hr) || !unk)
Huw.
Re: [PATCH] ole32: check for interface NULL which happens with e.g. Abiword
Marcus Meissner wrote:
> + if (!unk) {
> + FIXME("hr was %d, but unk is NULL?\n", hr);
> + return E_FAIL;
> + }
IDropTarget_QueryInterface() should be fixed instead.
--
Dmitry.
Re: [PATCH] shell32: use flexible arrays to avoid fortify failures
On 15 September 2010 12:22, Henri Verbeet wrote: > On 14 September 2010 15:44, Mike Frysinger wrote: >> note: i couldnt find a statement of what C standard wine aims for. if >> it is attempting pre-c99, then this will have to be done differently. >> perhaps introducing a project-wide define like "VARARRAY" which >> expands into [] for c99+ and [1] for older ... >> > Roughly C89, C99 features are generally out. > Also, patches should go to wine-patc...@winehq.org, unless you're asking for review / comments.
Re: [PATCH] shell32: use flexible arrays to avoid fortify failures
On 14 September 2010 15:44, Mike Frysinger wrote: > note: i couldnt find a statement of what C standard wine aims for. if > it is attempting pre-c99, then this will have to be done differently. > perhaps introducing a project-wide define like "VARARRAY" which > expands into [] for c99+ and [1] for older ... > Roughly C89, C99 features are generally out.
Re: d3dx9_36: Implement D3DXCreateMesh and initial ID3DXMesh methods. (try 3)
On 15 September 2010 01:55, Misha Koshelev wrote:
> +while (count < MAX_FVF_DECL_SIZE && (count == 0 ||
> declaration[count-1].Stream != 0xFF))
> +{
> +count++;
> +}
...and similarly you'd want to use D3DXGetDeclLength() here, though I
wonder if implementing DrawSubset() isn't going to require creating a
vertex declaration anyway.
> +if (!ref)
> +{
> +if (This->index_buffer)
> IDirect3DIndexBuffer9_Release(This->index_buffer);
> +if (This->vertex_buffer)
> IDirect3DVertexBuffer9_Release(This->vertex_buffer);
> +if (This->device) IDirect3DDevice9_Release(This->device);
> +HeapFree(GetProcessHeap(), 0, This);
> +}
In which cases can these be NULL?
Re: user32: Fix VK_RETURN handling in IsDialogMessage for dialogs without an IDOK
Vladimir Panteleev wrote: > I reduced the patch to two lines (it's not visible from the context, > but there's a "return TRUE" lower to make up for the removed one). > Hopefully it's not too cryptic now. Thanks for the feedback. Looks good to me. -- Dmitry.
Re: user32: Fix VK_RETURN handling in IsDialogMessage for dialogs without an IDOK
Vladimir Panteleev wrote: > How does this look? I took the opportunity to remove the duplicate > "GetDlgItem(hwndDlg, LOWORD(dw))". It's better, but since BN_CLICKED is 0, there is no need to introduce wParam. -- Dmitry.
Re: user32: Fix VK_RETURN handling in IsDialogMessage for dialogs without an IDOK
Vladimir Panteleev wrote:
> diff --git a/dlls/user32/dialog.c b/dlls/user32/dialog.c
> index aac8a4d..ee99710 100644
> --- a/dlls/user32/dialog.c
> +++ b/dlls/user32/dialog.c
> @@ -1221,6 +1221,11 @@ BOOL WINAPI IsDialogMessageW( HWND hwndDlg, LPMSG msg )
> else if (DC_HASDEFID == HIWORD(dw = SendMessageW (hwndDlg,
> DM_GETDEFID, 0, 0)))
> {
> HWND hwndDef = GetDlgItem(hwndDlg, LOWORD(dw));
> +if (!hwndDef && LOWORD(dw)==IDOK)
> +{
> +SendMessageW( hwndDlg, WM_COMMAND, IDOK, 0 );
> +return TRUE;
> +}
> if (!hwndDef || !IsWindowEnabled(hwndDef))
> return TRUE;
> SendMessageW( hwndDlg, WM_COMMAND, MAKEWPARAM(
> LOWORD(dw), BN_CLICKED ),
It would be cleaner to use an existing SendMessage() instead of
introducing a duplicate.
--
Dmitry.
