March 2011 - Wine-Devel - list.winehq.org

Wine Gecko 1.2.0 released

by Jacek Caban

Hi all, The new Wine Gecko release is out and already used by Wine git version. Let me conclude shortly what has changed (more detailed updates can be found in my previous mails). It mostly means that you have to download it from Wine Sourceforge [1] and put it into the right directory [2] as always after each Gecko update. One important change is that there is msi file instead of cab file. Also starting with Wine 1.3.15, packages should be updated to depend on the new Gecko. Packagers may consider compiling Gecko themselves as building process no longer has ugly dependencies. Thanks to everyone who helped with the release! BTW, the nice thing is that accidentally we've released just after IE9. That's what I call a quick response :) Cheers, Jacek [1] https://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0/ [2] http://wiki.winehq.org/Gecko

March 15, 2011

Re: [2/4] kernel32: Create a temp file with full access rights.

by Dmitry Timoshkov

Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > > @@ -703,7 +703,7 @@ UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, LPWSTR > > do > > { > > sprintfW( p, formatW, unique ); > > - handle = CreateFileW( buffer, GENERIC_WRITE, 0, NULL, > > + handle = CreateFileW( buffer, GENERIC_READ|GENERIC_WRITE|GENERIC_EXECUTE, 0, NULL, > > CREATE_NEW, FILE_ATTRIBUTE_NORMAL, 0 ); > > if (handle != INVALID_HANDLE_VALUE) > > { /* We created it */ > Is it possible to add a test for that? The problem is that wineserver directly maps access bits into the unix file mode and then unix mode to file access rights. So the only way right now to propagate exec rights to unix mode is to specify GENERIC_EXECUTE in CreateFile, and it doesn't matter what Windows does here, it shouldn't change anything. -- Dmitry.

March 15, 2011

Re: mshtml: Report an error when navigation fails

by Piotr Caban

On 03/14/11 16:59, Piotr Caban wrote: > --- > dlls/mshtml/navigate.c | 110 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 110 insertions(+), 0 deletions(-) Please ignore this patch. It doesn't work as native do. Cheers, Piotr

March 15, 2011

Re: [PATCH 3/3] mshtml: Notify parser about script evaluation

by Jacek Caban

On 3/15/11 1:50 PM, Marvin wrote: > 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=9959 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed to apply TestBot doesn't understand the first patch in the series because it's not against wine.git. Anyway, all that's changed in tests is removing todo_wines, so it's safe to apply without TestBot coverage. Jacek

March 15, 2011

Re: [PATCH 3/3] mshtml: Notify parser about script evaluation

by 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=9959 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 15, 2011

Re: [2/4] kernel32: Create a temp file with full access rights.

by Nikolay Sivov

On 3/15/2011 14:07, Dmitry Timoshkov wrote: > Installer in the bug 26288 requests FILE_ALL_ACCESS permission on a temp file > it just created. > --- > dlls/kernel32/path.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/kernel32/path.c b/dlls/kernel32/path.c > index e72848c..beeb14c 100644 > --- a/dlls/kernel32/path.c > +++ b/dlls/kernel32/path.c > @@ -703,7 +703,7 @@ UINT WINAPI GetTempFileNameW( LPCWSTR path, LPCWSTR prefix, UINT unique, LPWSTR > do > { > sprintfW( p, formatW, unique ); > - handle = CreateFileW( buffer, GENERIC_WRITE, 0, NULL, > + handle = CreateFileW( buffer, GENERIC_READ|GENERIC_WRITE|GENERIC_EXECUTE, 0, NULL, > CREATE_NEW, FILE_ATTRIBUTE_NORMAL, 0 ); > if (handle != INVALID_HANDLE_VALUE) > { /* We created it */ Is it possible to add a test for that?

March 15, 2011

Re: [4/4] server: Do not limit execute file access to .exe and .com files.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > - if (len >= 4 && > - (!strcasecmp( name + len - 4, ".exe" ) || !strcasecmp( name + len - 4, ".com" ))) > - { > - if (mode & S_IRUSR) > - mode |= S_IXUSR; > - if (mode & S_IRGRP) > - mode |= S_IXGRP; > - if (mode & S_IROTH) > - mode |= S_IXOTH; > - } > + if (mode & S_IRUSR) > + mode |= S_IXUSR; > + if (mode & S_IRGRP) > + mode |= S_IXGRP; > + if (mode & S_IROTH) > + mode |= S_IXOTH; Please ignore this patch, I need to figure out at which point the exec permissions are dropped. Other patches in the sequence do not depend on this one (and actually are all independent changes). -- Dmitry.

March 15, 2011

Re: correct comctl32 implementation

by Nikolay Sivov

On 3/15/2011 05:25, Frank Richter wrote: > On 11.03.2011 10:28, Nikolay Sivov wrote: >> In version 6 all user32 controls are reimplemented with theme support in >> comctl32, while user32 classes are kept of course. This is done with >> specific entries in comctl32 manifest, on load comctl32 all builtin >> classes are re-registered to the ones from comctl32. I definitely want >> to see some solution for that, having themed comctl32 controls while >> scrollbars and buttons are drawn with default appearance makes theme >> support kind of useless. > Buttons: technically, I don't think you need SxS class redirection for > that. The issue with the current “subclassing” is that, well, the button > can't really be subclassed for theming - IIRC some state changes don't > trigger a “paint” message but only cause internal painting - this can't > be caught lass function and breaks theming. > What MS supposedly did was to simply copy'n'paste the controls code into > comctl32 and add theming. That would certainly allow properly themed > buttons. And SxS class redirection... We need a way to make comctl32 controls available, not always but only when it's requested to use version 6. Native does that with class redirection. I'm not sure it's ok to use comctl32 always for builtin classes. > Scroll bars, are, IIRC, a different beast - window scroll bars are not > controls but handled/drawn by DefWndProc. No idea how native themes > these. Maybe some mojo to override/hook into DefWndProc? That's not true. Scrollbar could be a normal control too. I have no idea how themes work with window scrollbars though. > -f.r. > > > >

March 15, 2011

Re: Two more summer of code ideas

by Juan Lang

Hi Dan, > I added sandboxing and message-mode pipes to http://wiki.winehq.org/SummerOfCode > > (Yes, it's literally a pipe dream :-) I think it's too much for the scope of a SoC project, personally. I think it should be possible with help from the kernel. For example, Steve French expressed willingness to expose the ability to create named pipes from a user-space program. He just wanted to know the appropriate interface, i.e. where in the filesystem they should live, how they should be created, and so on. The work is perhaps less coding oriented, and more about coordination and design. Coordination implies being gated on others' schedules, and that means it'd be at pretty high risk of not getting completed, no matter how motivated a student might be. --Juan

March 15, 2011

Two more summer of code ideas

by Dan Kegel

I added sandboxing and message-mode pipes to http://wiki.winehq.org/SummerOfCode (Yes, it's literally a pipe dream :-) - Dan

March 15, 2011

Re: correct comctl32 implementation

by Frank Richter

On 11.03.2011 10:28, Nikolay Sivov wrote: > In version 6 all user32 controls are reimplemented with theme support in > comctl32, while user32 classes are kept of course. This is done with > specific entries in comctl32 manifest, on load comctl32 all builtin > classes are re-registered to the ones from comctl32. I definitely want > to see some solution for that, having themed comctl32 controls while > scrollbars and buttons are drawn with default appearance makes theme > support kind of useless. Buttons: technically, I don't think you need SxS class redirection for that. The issue with the current “subclassing” is that, well, the button can't really be subclassed for theming - IIRC some state changes don't trigger a “paint” message but only cause internal painting - this can't be caught lass function and breaks theming. What MS supposedly did was to simply copy'n'paste the controls code into comctl32 and add theming. That would certainly allow properly themed buttons. And SxS class redirection... Scroll bars, are, IIRC, a different beast - window scroll bars are not controls but handled/drawn by DefWndProc. No idea how native themes these. Maybe some mojo to override/hook into DefWndProc? -f.r.

March 15, 2011

Re: comctl32: Update progress bar only if it moves

by Nikolay Sivov

On 3/15/2011 00:16, Maarten Lankhorst wrote: > --- > Hopefully helps a little with lord of the rings online installer. It > seems to be fanatical about updating the position, which may result in > too many unnecessary redraws. Patch is wrong. This is inefficient but it's how native control works, it invalidates progress bar no matter what if position is changed. I tested so far PBM_DELTAPOS, PBM_SETPOS, PBM_STEPIT. So this change can break subclass processing for example, when application expects WM_PAINT.

March 14, 2011

Re: d3dx9_36: Start effect parsing.

by Henri Verbeet

2011/3/14 Rico Schüller <kgbricola(a)web.de>: > Yes, it is the shader/effect version. I used the value because I was not > able to generate other targets for d3dx9 with the current sdk. > > I think a mask for the effect ((tag >> 16) == 0xfeff)) would be fine here. > There shouldn't be a huge difference between the versions (tag & 0xffff), > but I expect one. > Checking for a specific version should be ok if that's all we support at the moment. But I think something like "d3dx9_effect_version(9, 1)" would be much clearer than 0xfeff0901.

March 14, 2011

Re: d3dx9_36: Start effect parsing.

by Rico Schüller

Am 13.03.2011 22:59, schrieb Henri Verbeet: > 2011/3/13 Rico Schüller<kgbricola(a)web.de>: >> + if (tag != 0xfeff0901) > Looks like the kind of thing you'd want a constant or inline function > for. If I were to guess, the feff part means it's an effect (similar > to the ffff for d3d9 pixel shaders and the fffe for d3d9 vertex > shaders), and 0901 for version 9.1 (also similar to the d3d9 shader > version token). > Yes, it is the shader/effect version. I used the value because I was not able to generate other targets for d3dx9 with the current sdk. I think a mask for the effect ((tag >> 16) == 0xfeff)) would be fine here. There shouldn't be a huge difference between the versions (tag & 0xffff), but I expect one. I'll send an improved version. Cheers Rico

March 14, 2011

Re: [PATCH 5/5] shdocvw/tests: Added IShellBrowser, IBrowserService and IDocObjectService existance tests

by 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=9936 Your paranoid android. === WINEBUILD (build) === Make failed

March 14, 2011

Re: [PATCH 2/5] shdocvw: Added IShellBrowser interface stub

by Huw Davies

On Mon, Mar 14, 2011 at 05:03:37PM +0100, Piotr Caban wrote: > +static HRESULT WINAPI ShellBrowser_QueryInterface( > + IShellBrowser* iface, > + REFIID riid, > + void **ppvObject) > +{ > + ShellBrowser *This = impl_from_IShellBrowser(iface); > + *ppvObject = NULL; > + > + if(IsEqualGUID(&IID_IShellBrowser, riid)) > + *ppvObject = &This->IShellBrowser_iface; > + > + if(*ppvObject) { > + TRACE("%p %s %p\n", This, debugstr_guid(riid), ppvObject); > + IUnknown_AddRef((IUnknown*)*ppvObject); > + return S_OK; > + } > + You probably want to add support for IID_IUnknown here too. Huw.

March 14, 2011

Re: [PATCH 2/2] winmm: Parse MCI colon notation as in T:MM:SS:F

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > @@ -975,18 +975,31 @@ static WORD MCI_GetMessage(LPCWSTR lpCmd) > */ > static BOOL MCI_GetDWord(DWORD* data, LPWSTR* ptr) > { > - DWORD val; > - LPWSTR ret; > + DWORD val, total = 0; > + LPWSTR ret, src = *ptr; > + int shift = 0; > > - val = strtoulW(*ptr, &ret, 10); > + colonized: > + val = strtoulW(src, &ret, 10); > + if (ret == src) return FALSE; > > switch (*ret) { > case '\0': break; > + case '\t': > case ' ': ret++; break; > + case ':': { > + if ((val >= 256) || (shift >= 24)) return FALSE; > + total |= val << shift; > + shift += 8; > + src = ret + 1; > + goto colonized; > + } Please use a proper loop, not a goto. -- Alexandre Julliard julliard(a)winehq.org

March 14, 2011

Re: [PATCH 3/3] winecoreaudio: Fix 64-bits incompatibilities

by Alexandre Julliard

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > Dear 64bit users, > > here I turned a couple of DWORD into DWORD_PTR by analogy with other such patches. > I'm using a 32bit bit system where it makes no difference, so please check. > I'm wondering why, if such types make a difference on 64 bit, there > aren't crashes seen on testhq or otherwise reported. Why was this > not spotted earlier? 64-bit is not supported on Mac OS. -- Alexandre Julliard julliard(a)winehq.org

March 14, 2011

Re: Patch hw cursor Wine 1.3.15

by Jerome Leclanche

WoW has builtin hardware cursor since 4.x, making this patch pretty much useless; it was a hack in the first place. If you really want to post it somewhere, it should be in the appdb. J. Leclanche On Sun, Mar 13, 2011 at 10:54 PM, Valentino Dell'Aica <elettronik(a)gmail.com> wrote: > The patch is not mine. I've adapted it to work on wine 1.3.15. The purpose > of this patch is give a system cursor in WoW 3.3.5 > > 2011/3/13 Vitaliy Margolen <wine-devel(a)kievinfo.com> >> >> On 03/13/2011 02:31 PM, Valentino Dell'Aica wrote: >>> >>> Hi I've modified a patch for hw cursor in wine so it can work on wine >>> 1.3.15 >> >> You have number of problems with your patch formatting with are outlined >> here: http://wiki.wi >> nehq.org/SubmittingPatches >> >>> + hwgl = getenv("WINE_CURSOR"); >> >> Wine uses registry for things like this. It should be a static variable >> set once. >> >>> + WINE_FIXME("Out of memory.\n"); >> >> For wine libraries this should be "FIXME". Also just printing fixme isn't >> a good error handling. >> >> And can you explain why for every button press/release you >> creating/removing cursor? This is highly inefficient. And what are you >> trying to archive with it anyway? >> >> Vitaliy. > > > > -- > Valentino Dell'Aica > _______________________________________ > > Via Bella Venezia 3, 31043 Fontanelle (TV) > _______________________________________ > > There are three schools of magic. One: State a tautology, then ring the > changes on its corollaries; that's philosophy. Two: Record many facts. Try > to find a pattern. Then make a wrong guess at the next fact; that's science. > Three: Be aware that you live in a malevolent Universe controlled by > Murphy's Law, sometimes offset by Brewster's Factor; that's engineering. > > > > > >

March 14, 2011

Re: GSOC CMD parser.

by James McKenzie

On 3/12/11 6:18 PM, Joel Teichroeb wrote: > I'm quite interested in the idea on the wiki of improving the CMD > parser and fixing the bugs. I brought this up in the IRC and it was > mentioned that there was some discussion of using bison/flex for > parsing. I don't think that would be feasible for me to do in just > three months but I'm wondering if that is the direction that is wanted > for the CMD parser. I think that you have a good plan, but you should limit your scope of work to maybe one or two bugs and work on them. Taking on the 'whole' bug thing may prove to be overwhelming. As an example, I picked up a bug report from someone else and have been working on it, off and on, over three years. This was to add a complex function and it was implemented completely wrong and I realized this after much work. You might also want to look at finishing some of the missing tests and filing bugs for the missing functions. This depends on your 'c' programming skills and your ability to discover sources for CMD functions. Overall, I don't have the ability to say whether or not this would be a good GSOC candidate, but we do need someone to look into the CMD parser and figure out if there is a better way to implement it. James McKenzie

March 14, 2011

Re: riched20/tests: Beginnings of EM_SETMARGINS test

by 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=9910 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

March 14, 2011

riched20/tests: Beginnings of EM_SETMARGINS test. This patch is released into the Public Domain under the requirements of the LGPL version 2.1 or later. Released by James McKenzie jjmckenzie51@gmail.com

by James McKenzie

Just checking if gmail has a 'wrapping' problem or if this will actually go through. riched20/tests: Beginnings of EM_SETMARGINS test. This patch is released into the Public Domain under the requirements of the LGPL version 2.1 or later. Released by James McKenzie jjmckenzie51(a)gmail.com --- dlls/riched20/tests/editor.c | 215 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 215 insertions(+), 0 deletions(-) diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c index 7a4e032..31f3bdc 100644 --- a/dlls/riched20/tests/editor.c +++ b/dlls/riched20/tests/editor.c @@ -7034,6 +7034,220 @@ static void test_dialogmode(void) DestroyWindow(hwParent); } +static INT CALLBACK is_truetype_font_installed_proc(const LOGFONT *elf, const TEXTMETRIC *ntm, DWORD type, LPARAM lParam) +{ + if (type != TRUETYPE_FONTTYPE) return 1; + + return 0; +} + +static BOOL is_truetype_font_installed(const char *name) +{ + HDC hdc = GetDC(0); + BOOL ret = FALSE; + + if (!EnumFontFamiliesA(hdc, name, is_truetype_font_installed_proc, 0)) + ret = TRUE; + + ReleaseDC(0, hdc); + return ret; +} + +static INT CALLBACK is_font_installed_proc(const LOGFONT *elf, const TEXTMETRIC *ntm, DWORD type, LPARAM lParam) +{ + return 0; +} + +static BOOL is_font_installed(const char *name) +{ + HDC hdc = GetDC(0); + BOOL ret = FALSE; + + if(!EnumFontFamiliesA(hdc, name, is_font_installed_proc, 0)) + ret = TRUE; + + ReleaseDC(0, hdc); + return ret; +} + +static void test_em_setmargins(void) +{ + HWND hwndRichEdit; + RECT old_rect, new_rect; + + HDC hDC; + LOGFONTA lfA; + UINT ret; + int ry, i, j, k; + + HFONT testFont1A, hDC_font; + + /* Add various window sizes for USEFONTINFO tests */ + static const struct rect_parameters + { + int start_left, start_top, end_right, end_bottom; + } rect_param[] = + { + { 0, 0, 400, 80 }, + }; + + /* data for ANSI font tests */ + static const struct font_margins_data + { + const char face_name[LF_FACESIZE]; + int weight, height, ascent, descent, int_leading, ext_leading; + int ave_char_width, max_char_width, dpi; + } fmd[] = + { + { "Courier", FW_NORMAL, 13, 11, 2, 0, 0, 8, 8, 96 }, + { "System", FW_BOLD, 16, 13, 3, 3, 0, 7, 14, 96 }, + { "Arial", FW_NORMAL, 16, 13, 3, 3, 0, 6, 35, 96, }, + }; + + /* Test data for margins testing */ + static const struct margin_test_data + { + int left_margin, right_margin; + DWORD margin_type; + } mmt [] = + { + { 0, 0, EC_LEFTMARGIN }, /*Clear all margin settings */ + /*Left Margin tests*/ + { 10, 0, EC_LEFTMARGIN }, /*Set Left Margin to 10 */ + { EC_USEFONTINFO, 0, EC_LEFTMARGIN }, /*Test EC_USEFONTINFO as lparam with EC_LEFTMARGIN */ + { 0, 0, EC_LEFTMARGIN }, /*Clear margins for Right Margin tests */ + /*EC_USEFONTINFO as lpararm tests */ + { 10, 10, EC_USEFONTINFO }, /*Set margins to 10 with EC_USEFONTINFO, should return zero */ + { 0, EC_USEFONTINFO, EC_USEFONTINFO }, /*Set Right Margin to EC_USEFONTINFO under EC_USEFONTINFO, should + return zero except with TrueType Fonts, this should be the lagging spacing value for large fonts and large + edit windows*/ + { EC_USEFONTINFO, 0, EC_USEFONTINFO }, /*Set Left Margin to EC_USEFONTINFO under EC_USEFONTINFO, should return + zero except with TrueType Fonts, this should be the leading spacing value for large fonts and large edit + windows*/ + { EC_USEFONTINFO, EC_USEFONTINFO, EC_USEFONTINFO }, /*Set both margins to EC_USEFONTINFO under EC_USEFONTINFO, + should have same results for both left and right tests above */ + { 0, 0, EC_USEFONTINFO }, /*Clear Margins, if set */ + }; + + /* Run tests for number of rectangles */ + for ( k=0; k< (sizeof(rect_param)/sizeof(rect_param[0])); k++) + { + hwndRichEdit = CreateWindow(RICHEDIT_CLASS, NULL, ES_MULTILINE|WS_POPUP|WS_HSCROLL|WS_VSCROLL|WS_VISIBLE, + rect_param[k].start_left, rect_param[k].start_top, rect_param[k].end_right, + rect_param[k].end_bottom, NULL, NULL, hmoduleRichEdit, NULL); + ok(hwndRichEdit != NULL, "Error creating Richedit Window in EM_SETMARGINS test. error received: %d\n", + (int) GetLastError()); + if (!hwndRichEdit) + { + return; + } + + hDC = GetDC(hwndRichEdit); + ok (hDC != NULL, "Creation of hdc failed.\n"); + if (!hDC) + { + DestroyWindow(hwndRichEdit); + return; + } + + ry = GetDeviceCaps(hDC, LOGPIXELSY); + + ZeroMemory(&lfA, sizeof(lfA)); + ZeroMemory(&testFont1A, sizeof(HFONT)); + /*Initialize rect variable to be the size of the entire richedit window */ + old_rect.left = rect_param[k].start_left; + old_rect.right = rect_param[k].end_right; + old_rect.top = rect_param[k].start_top; + old_rect.bottom = rect_param[k].end_bottom; + SendMessageA(hwndRichEdit, EM_SETRECT, 0, (LPARAM)&old_rect); + SendMessageA(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&old_rect); + ok (rect_param[k].start_left == old_rect.left , "Richedit control window not created correctly. Canceling " + "test for window size of %d by %d\n", rect_param[k].end_right, rect_param[k].end_bottom); + if (rect_param[k].start_left != old_rect.left) continue; + + /* Run tests for number of ANSI fonts */ + for (i = 0; i < sizeof(fmd)/sizeof(fmd[0]); i++) + { + strcpy(lfA.lfFaceName, fmd[i].face_name); + lfA.lfHeight = fmd[i].height; + lfA.lfCharSet = DEFAULT_CHARSET; + lfA.lfWeight = fmd[i].weight; + ret = is_font_installed(lfA.lfFaceName); + /* If font cannot cannot be found, skip rest of tests */ + ok (ret != 0, "Font not found, test results are not predictable. Aborting test for font %s\n", + fmd[i].face_name); + if (ret) continue; + ret = is_truetype_font_installed(lfA.lfFaceName); + if (lfA.lfFaceName == "Arial") + { + ok (ret == 0, "Truetype font emulated, test results will not be consistent with Windows!\n"); + if (!ret) continue; + } + + testFont1A = CreateFontIndirectA (&lfA); + hDC_font = SelectObject(hDC, testFont1A); + /* looping through the all of the tests */ + for (j=0; j < sizeof (mmt)/sizeof (mmt[1]); j++) + { + SendMessageA(hwndRichEdit, EM_SETMARGINS, mmt[j].margin_type, MAKELONG (mmt[j].left_margin, + mmt[j].right_margin)); + ret=SendMessageA(hwndRichEdit, EM_GETRECT, 0, (LPARAM)&new_rect); + ok (ret == 0, "An error occurred getting new margins\n"); + switch (mmt[j].margin_type) + { + case EC_USEFONTINFO : + /* Per several web sources, using the EC_USEFONTINFO with a TrueType font should result in the + following: The Left Margin should be set to the 'C' value, that is the value used to set white + space after a character and the next printed character. This is also called leading spacing. + The Right Margin should be set to the 'A' value, that is the value use to set white space to the + current position before drawing the next character. This is also called lagging spacing. + During testing could not find a case where this was true for any version of riched20.dll */ + { + ok(new_rect.right == old_rect.right, "The right border moved in EC_USEFONTINFO Left/Right " + "margin change test to %d for font %s(%d)\n", old_rect.right - new_rect.right, + fmd[i].face_name, fmd[i].height); + ok(new_rect.left == old_rect.left, "The left border was moved in EC_USEFONTINFO Left/Right Margin " + "change test to %d for font %s(%d).\n", old_rect.left - new_rect.left, fmd[i].face_name, + fmd[i].height); + } + break; + case EC_LEFTMARGIN : + if (mmt[j].left_margin == 0 ) + { + ok(new_rect.left == old_rect.left, "The left border moved %d in the Left Margin " + "Zero test for font %s(%d).\n", new_rect.left - old_rect.left, fmd[i].face_name, fmd[i].height); + } + else + { + todo_wine { + ok(new_rect.left == old_rect.left + mmt[j].left_margin, "The left border moved %d and should be " + "%d in the Left margin change test for font %s(%d).\n", new_rect.left - old_rect.left, + mmt[j].left_margin, fmd[i].face_name, fmd[i].height); + } + } + ok(new_rect.right == old_rect.right, "The right border was moved %d in Left Margin change test for " + "font %s(%d).\n", new_rect.right - old_rect.right, fmd[i].face_name, fmd[i].height); + break; + case EC_LEFTMARGIN | EC_RIGHTMARGIN : + case EC_RIGHTMARGIN : + default: /* fall through if there is a data error or new margin type test */ + ok (0 == 1, "Check %s %d %d 0x%x\n", fmd[i].face_name, fmd[i].height, fmd[i].dpi, mmt[j].margin_type); + } + /* test if top or bottom margin moved. Test should not disturb them */ + ok(new_rect.top == old_rect.top, "The top border moved %d in the test.\n", + new_rect.top - old_rect.top); + ok(new_rect.bottom == old_rect.bottom, "The bottom border moved %d in the test\n", + new_rect.bottom - old_rect.bottom); + } + SelectObject(hDC, hDC_font); + DeleteObject(testFont1A); + } + DeleteObject(testFont1A); + ReleaseDC (hwndRichEdit, hDC); + DestroyWindow (hwndRichEdit); + } +} + START_TEST( editor ) { BOOL ret; @@ -7090,6 +7304,7 @@ START_TEST( editor ) test_WM_GETDLGCODE(); test_zoom(); test_dialogmode(); + test_em_setmargins(); /* Set the environment variable WINETEST_RICHED20 to keep windows * responsive and open for 30 seconds. This is useful for debugging. -- 1.7.4

March 13, 2011

Re: Patch hw cursor Wine 1.3.15

by Valentino Dell'Aica

The patch is not mine. I've adapted it to work on wine 1.3.15. The purpose of this patch is give a system cursor in WoW 3.3.5 2011/3/13 Vitaliy Margolen <wine-devel(a)kievinfo.com> > On 03/13/2011 02:31 PM, Valentino Dell'Aica wrote: > >> Hi I've modified a patch for hw cursor in wine so it can work on wine >> 1.3.15 >> > You have number of problems with your patch formatting with are outlined > here: http://wiki.wi <http://wiki.winehq.org/SubmittingPatches> > > nehq.org/SubmittingPatches <http://wiki.winehq.org/SubmittingPatches> > > + hwgl = getenv("WINE_CURSOR"); >> > Wine uses registry for things like this. It should be a static variable set > once. > > + WINE_FIXME("Out of memory.\n"); >> > For wine libraries this should be "FIXME". Also just printing fixme isn't a > good error handling. > > And can you explain why for every button press/release you > creating/removing cursor? This is highly inefficient. And what are you > trying to archive with it anyway? > > Vitaliy. > -- Valentino Dell'Aica _______________________________________ Via Bella Venezia 3, 31043 Fontanelle (TV) _______________________________________ There are three schools of magic. One: State a tautology, then ring the changes on its corollaries; that's philosophy. Two: Record many facts. Try to find a pattern. Then make a wrong guess at the next fact; that's science. Three: Be aware that you live in a malevolent Universe controlled by Murphy's Law, sometimes offset by Brewster's Factor; that's engineering.

March 13, 2011

Re: Patch hw cursor Wine 1.3.15

by Vitaliy Margolen

On 03/13/2011 02:31 PM, Valentino Dell'Aica wrote: > Hi I've modified a patch for hw cursor in wine so it can work on wine 1.3.15 You have number of problems with your patch formatting with are outlined here: http://wiki.winehq.org/SubmittingPatches > + hwgl = getenv("WINE_CURSOR"); Wine uses registry for things like this. It should be a static variable set once. > + WINE_FIXME("Out of memory.\n"); For wine libraries this should be "FIXME". Also just printing fixme isn't a good error handling. And can you explain why for every button press/release you creating/removing cursor? This is highly inefficient. And what are you trying to archive with it anyway? Vitaliy.

March 13, 2011

Re: d3dx9_36: Start effect parsing.

by Henri Verbeet

2011/3/13 Rico Schüller <kgbricola(a)web.de>: > + if (tag != 0xfeff0901) Looks like the kind of thing you'd want a constant or inline function for. If I were to guess, the feff part means it's an effect (similar to the ffff for d3d9 pixel shaders and the fffe for d3d9 vertex shaders), and 0901 for version 9.1 (also similar to the d3d9 shader version token).

March 13, 2011