wine-devel April 2009

wine-devel@winehq.org

118 participants
279 discussions

Re: comctl32/tab: Draw hottracked tab button properly (resent)
by Vitaliy Margolen 06 Apr '09

06 Apr '09

Nikolay Sivov wrote: > With patch this time. > > This makes hottracked tab button look like it does in native. > Bounding rectangle is still wrong but it's another problem, > anyway now it looks better. Maybe you should fix that rectangle first? There were few differences I recall in size of the update regions between Wine and native. The drawing errors could be the result of those differences. Vitaliy.

2 1

Patch regarding GetUserProfileDirectory
by Andreas Rosenberg 06 Apr '09

06 Apr '09

Hi! I sent a patch regarding GetUserProfileDirectory last Monday. I didn't receive any comments/critics as on my previous attempts. The patch doesn't appear in wine-cvs, so I suppose something is still not correct. Can anybody give me a clue, please? Regards Andreas

1 0

Re: RFC: Resource editing and validation
by Reece Dunn 06 Apr '09

06 Apr '09

2009/4/6 Warren Dumortier <nwarrenfl(a)gmail.com>: > Yeah, why not. > > But that was not really hard at all, if you use a calculator to > calculate x and y coords. I could easily change winecfg for my patch. > IMO it is not really needed as winecfg doesn't change a lot... The issue is not so much that winecfg changes a lot or not. All the other dialogs are affected across other resources. Sure, you can use a calculator. However, you still need to update all the controls in the dialog you are editing, to move them to their new positions. In addition to this, the controls on the various dialogs (e.g. on winecfg, but others such as the Browse For Network Share dialog are affected as well) are inconsistently positioned. The Browse For Network Share dialog does not have 50x14 sized command buttons (OK, Cancel) -- this makes them look squashed up, especially when using themes. On the winecfg desktop tab, the "Color:" and related labels are incorrectly spaced from the control below them. This causes them to look bunched up. Also, some of the buttons are not 14 DLUs high -- causing them to look scrunched up -- and the spacing between controls is 5 DLUs. As a result of all of this (and other layout rules), the dialog looks inconsistent and unprofessional. Having an editor that takes care of this means that you get a consistent and more professional look that will also work when you have theming turned on. It also means that you don't have to spend hours with a calculator adjusting control positions by hand. Doing that is very time consuming -- I know, as I have done this, but using Visual Studio dialog guidelines. When editing a dialog, I want something that does this for me, so I don't have to worry about positioning and spend a long time fiddling with guidelines or (x, y) coordinates -- especially when making several changes to the dialogs. I also want to revive my "Usability: WineCfg Part 1 -- Desktop Integration tab" thread, and expand this to other areas of the dialog and to wine as a whole. Having the tools and infrastructure in place to do this -- especially when you consider adjusting the dialogs across the different language resources -- makes the whole thing easier. - Reece

1 0

Re: urlmon/tests: Handle certificate verification error
by Alexandre Julliard 06 Apr '09

06 Apr '09

"Ge van Geldorp" <ge(a)gse.nl> writes: > Some W2K3 boxes have problems verifying the certificate during the https > test. Just retrying the verification once fixes this. > > Changelog: > urlmon/tests: Handle certificate verification error This is causing a failure here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so protocol.c && touch protocol.ok protocol.c:444: Test succeeded inside todo block: expected ReportProgress_SENDINGREQUEST make[2]: *** [protocol.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

User forum thread: "how can we improve WINE?"
by David Gerard 06 Apr '09

06 Apr '09

http://forum.winehq.org/viewtopic.php?t=4403 Some highly impractical ideas, but certainly having the users throw ideas around should inspire wine-devel (and Codeweavers) :-) - d.

7 15

Re: [1/3] secur32: Implement GetUserNameEx(NameSamCompatible)
by Alexandre Julliard 06 Apr '09

06 Apr '09

"Ge van Geldorp" <ge(a)gse.nl> writes: > @@ -1055,15 +1056,86 @@ BOOLEAN WINAPI GetComputerObjectNameW( > BOOLEAN WINAPI GetUserNameExA( > EXTENDED_NAME_FORMAT NameFormat, LPSTR lpNameBuffer, PULONG nSize) > { > - FIXME("%d %p %p\n", NameFormat, lpNameBuffer, nSize); > - return FALSE; > + BOOLEAN rc; > + LPWSTR bufferW = NULL; > + ULONG sizeW = *nSize; > + TRACE("(%d %p %p)\n", NameFormat, lpNameBuffer, nSize); > + if (lpNameBuffer) { > + bufferW = HeapAlloc(GetProcessHeap(), 0, sizeW * sizeof(WCHAR)); > + if (bufferW == NULL) { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; > + } > + } > + rc = GetUserNameExW(NameFormat, bufferW, &sizeW); > + if (rc && bufferW) { > + ULONG len = WideCharToMultiByte(CP_ACP, 0, bufferW, -1, NULL, 0, NULL, NULL); > + WideCharToMultiByte(CP_ACP, 0, bufferW, -1, lpNameBuffer, *nSize, NULL, NULL); > + *nSize = len; > + } You need to check for buffer overflows and return the appropriate error, preferably with test cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

GSoC students, check that you're subscribed to updates to your proposal
by Kai Blin 06 Apr '09

06 Apr '09

Hi folks, it seems that the current GSoC webapp does not subscribe you to updates on your proposals automatically. Please log in there and make sure that you're subscribed. Otherwise you might miss comments by the mentors, which will reflect negatively on your proposal. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Re: [urlmon/tests] Fix a test by using a better default registry key
by Nicolas Le Cam 06 Apr '09

06 Apr '09

Hi Paul, > dlls/urlmon/tests/misc.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/dlls/urlmon/tests/misc.c b/dlls/urlmon/tests/misc.c > index 7702e1e..b77924e 100644 > --- a/dlls/urlmon/tests/misc.c > +++ b/dlls/urlmon/tests/misc.c > @@ -851,7 +851,10 @@ static void test_url_action(IInternetSecurityManager > *secmgr, IInternetZoneManag > HKEY hkey; > HRESULT hres; > > - res = RegOpenKeyA(HKEY_LOCAL_MACHINE, > + /* FIXME: HKEY_CURRENT_USER is most of the time the default but this > can be changed on a system. > + * The test should should be changed to cope with that, if need be. Should should ? > + */ > + res = RegOpenKeyA(HKEY_CURRENT_USER, > "Software\\Microsoft\\Windows\\CurrentVersion\\Internet > Settings\\Zones\\3", &hkey); > if(res != ERROR_SUCCESS) { > ok(0, "Could not open zone key\n"); -- Nicolas Le Cam

1 0

Re: [1/10] d3d8, d3d9: Don't rely on the wined3d buffer type
by Henri Verbeet 06 Apr '09

06 Apr '09

2009/4/4 Stefan Dösinger <stefan(a)codeweavers.com>: > + pDesc->Usage = pDesc->Usage; > + pDesc->Pool = pDesc->Pool; > + pDesc->Size = pDesc->Size; This is just silly.

2 1

Re: [5/5] WineD3D: Merge buffer creation methods
by Henri Verbeet 05 Apr '09

05 Apr '09

2009/4/4 Stefan Dösinger <stefan(a)codeweavers.com>: > - hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, &wined3d_desc, > - data ? data->pSysMem : NULL, (IUnknown *)object, &object->wined3d_buffer); > + hr = IWineD3DDevice_CreateBuffer(This->wined3d_device, 0 /* fvf */, > + WINED3DFMT_VERTEXDATA, WINED3DPOOL_DEFAULT, &wined3d_desc, > + data ? data->pSysMem : NULL, (IUnknown *)object, 0 /* SharedHandle */, &object->wined3d_buffer); Please don't introduce things like "SharedHandle" into CreateBuffer(). We should get rid of that for the other wined3d methods as well actually, it's never used anywhere, and it will probably be quite a while before we will, if ever. (DXGI and D3D9 in Vista actually allow this to be used, but I don't think it's very useful to have this at the moment). > + memset(&wined3d_desc, 0, sizeof(wined3d_desc)); > + wined3d_desc.byte_width = Size; > + wined3d_desc.usage = Usage & WINED3DUSAGE_MASK; That's not what the "usage" field was meant for. I don't think you should involve the d3d10 style CreateBuffer() in this at this point. However, if you do, it should be a separate patch for merging CreateVertexBuffer() and CreateIndexBuffer(), and *after* you've removed the format and FVF parameters. In that case you should use wined3d_buffer_desc properly, ie. pay attention to cpu_access_flags, etc. and using bind_flags instead of buffer_type_hint.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2009