October 2008 - Wine-devel - list.winehq.org

[PATCH] wordpad: Make the Replace function work and the Find/Replace dialogs behave like expected.
by Elias Benali 27 Oct '08

27 Oct '08

>From 6dc7a289ccf1567a87dfca66a86ace0f509621ff Mon Sep 17 00:00:00 2001 From: Elias Benali <elptr(a)users.sourceforge.net> Date: Sat, 25 Oct 2008 21:09:27 -0400 Subject: wordpad: Make the Replace function work and the Find/Replace dialogs behave like expected. The "Find What" field is filled from the current selection in the document, if any. --- programs/wordpad/wordpad.c | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/programs/wordpad/wordpad.c b/programs/wordpad/wordpad.c index d06b2d9..434b6fd 100644 --- a/programs/wordpad/wordpad.c +++ b/programs/wordpad/wordpad.c @@ -49,6 +49,10 @@ # define U3(x) (x) #endif +#ifndef MIN +# define MIN(a,b) ((a) < (b) ? (a) : (b)) +#endif + /* use LoadString */ static const WCHAR wszAppTitle[] = {'W','i','n','e',' ','W','o','r','d','p','a','d',0}; @@ -1281,12 +1285,29 @@ static LRESULT handle_findmsg(LPFINDREPLACEW pFr) static void dialog_find(LPFINDREPLACEW fr, BOOL replace) { static WCHAR findBuffer[MAX_STRING_LEN]; + static WCHAR replaceBuffer[MAX_STRING_LEN]; + CHARRANGE cr; + TEXTRANGE tr; + + SendMessage(hEditorWnd, EM_EXGETSEL, 0, (LPARAM)&cr); + if (cr.cpMax > cr.cpMin) { + cr.cpMax = cr.cpMin + MIN(sizeof(findBuffer)/sizeof(WCHAR)-1, cr.cpMax-cr.cpMin); + tr.chrg = cr; + tr.lpstrText = (LPSTR)findBuffer; + SendMessage(hEditorWnd, EM_GETTEXTRANGE, 0, (LPARAM)&tr); + } else + findBuffer[0] = '\0'; + + replaceBuffer[0] = '\0'; ZeroMemory(fr, sizeof(FINDREPLACEW)); fr->lStructSize = sizeof(FINDREPLACEW); fr->hwndOwner = hMainWnd; fr->Flags = FR_HIDEUPDOWN; fr->lpstrFindWhat = findBuffer; + fr->wFindWhatLen = sizeof(findBuffer); + fr->wReplaceWithLen = sizeof(replaceBuffer); /* ignored by FindTextW() */ + fr->lpstrReplaceWith = replaceBuffer; /* ignored by FindTextW() */ fr->lCustData = -1; fr->wFindWhatLen = MAX_STRING_LEN*sizeof(WCHAR); -- 1.6.0.2

3 2

Minimal subset of Wine that can do 'make test'?
by Dan Kegel 26 Oct '08

26 Oct '08

On the theory that having a really small subset of wine would help me bring up the new patchwatcher faster, I tried building just ntdll and its tests. I had to bring in a few dependencies... but the killer was wineboot. It brings in the kitchen sink. So much for that dream! I suppose a dummy wineboot might do the trick, but that's more work than I wanted to do for this experiment.

2 1

Fix showing console window at start of some app
by slawek 26 Oct '08

26 Oct '08

Bloodshed DevC++ will not running console application if I click run program or compile it. I was wondering why and decided to put some test we have terminal access inside Wine code. I was using create_process(inside kernell32.dll). I was put the test at top of the function. This is a test for it: #include <unistd.h> /* Another code there ....... */ static BOOL create_process(...) { /* Declarations */ if (!isatty(STDIN_FILENO)) flags|=CREATE_NEW_CONSOLE; /* END */ All will works(i we have run this program in a terminal, child process will show messages in it. but If we can't have access to terminal child process will be run inside new console Window). But this code makes some other issues. Graphics applications aren't touch by this patch, but app without Window will generate blank console Windows. If I start some application, like wine notepad, there's services.exe and wineboot.exe console Windows appear. Other think is possible some splash Window don't have destroyed property(but i must test it). Possible read subsystem information from file will fix thease problems(if file don't have subsystem record, it's must be gui application). At now there's no way to run wine cmd.exe, because we are using CreateProcess to test we have terminal access. I will to moved my code into lowest level code, but I don't know where and start program call CreateProcess(there's some information about this solution). Can I send patch to Wine?

1 0

re: Winelib and static-build
by Dan Kegel 26 Oct '08

26 Oct '08

Alan Nisota wrote: > I have a project (http://code.google.com/p/coreavc-for-linux) which is a > linux executable which provides access to Windows DirectShow filters > > The problem is that I normally provide a static binary so that users on > x86-64 can install it easily without needing a 32bit build environment... Offhand, I don't think winelib lends itself to use as a static library. We're rather heavily wedded to dynamic linking, more so than in the past. How bad would it be, really, to depend on the wine package? I'd be happy to help you think through the obstacles and see if that would work for you. (The Linux Standard Base people ask occasionally if Wine belongs in the LSB. If it were, you wouldn't have to worry about Wine being installed. Maybe next year Wine will be indispensable to make it to that state...) - Dan

3 8

Re: gdi32: added CreateFontIndirectEx[A/W]
by Paul Vriens 26 Oct '08

26 Oct '08

Nikolay Sivov wrote: > + if(!pCreateFontIndirectExA) > + trace("CreateFontIndirectExA not implemeted on this platform\n"); Could you turn that into a win_skip() ? -- Cheers, Paul.

1 0

Re: [msi/tests] Fix a test for systems with %TEMP% only one level deep
by James McKenzie 26 Oct '08

26 Oct '08

Paul Vriens wrote: > Hi, > > We were basically passing "C:" to SetCurrentDirectoryA and that doesn't > work. Probably needs it's own test in kernel32 or so. > > Changelog > Fix a test for systems with %TEMP% only one level deep > > ------------------------------------------------------------------------ > > Paul: Was this patch rejected or in update? Thank you. James McKenzie

2 1

RFC: Calling thiscall methods to start windowless richedit control tests
by Dylan Smith 26 Oct '08

26 Oct '08

I have created a couple of patches to start the windowless richedit control tests. Since this has been tried by two other people already, I thought I should get some comments before submitting them to wine-patches. Maarten Lankhorst initially tried to start these tests back in 2005: http://www.winehq.org/pipermail/wine-devel/2005-July/038185.html Austin Lund made some more progress on starting these tests. http://www.winehq.org/pipermail/wine-devel/2008-July/067001.html I kept the tests minimal because I want to other issues to be taken care of before adding tests. The main thing is that the tests compile and run properly on Windows and Linux without crashing. The main difficulty was wrapping c++ methods which use the thiscall calling convention. Austin Lund already got this to work, so I just modified what he had to avoid using the ebx register. The first patch has the code to wrap the ITextHost methods so they can be called with the thiscall calling convention, and the second patch has the wrapping code to call ITextServices functions that use the thiscall calling convention. Even though the assembly is fairly short, the conditional macro definitions for all the ITextServices methods does become verbose. Let me know if someone knows a more elegant way of doing this. The macros I created however conflict with the ones in include/textserv.h, however these aren't in the native public headers. Should these be removed from Wine's public headers, or should they be modified to handle the thiscall calling convention like I did in the second patch? In order to investigate what is happening in the tests, it is helpful to trace the calls to ITextHost methods by the richedit controls. I realized it would be too verbose to trace all these calls by default, so I wrapped them all with a check for winedebug > 1, since normally winedebug is 0 or 1. Does this seem like the best way to handle this? Because I can't use the normal TRACE channels from wine/debug.h, since it can't be included in the tests. I would also like someone to look at the conditional macro definitions of __ASM_FUNC and __ASM_NAME. I took these definitions from the generated include/config.h file from my normal linux build, and from my Windows cross compile build that uses mingw. I looked at configure and found there is another possible definition for __ASM_FUNC, so I know I am missing one of the cases, but I can't test for it like the configure script does. Does anyone know how to do this properly? Thanks again for everyone who has helped on this issue. I have tried to look at all the previous comments made, and use evolve some of the code that was already written.

1 0

DWORD help
by Andrew Fenn 26 Oct '08

26 Oct '08

I have written the following but when I have dwUserIndex as 0,1,2,3 or any number, doesn't really matter, it always returns ERROR_BAD_ARGUMENTS. DWORD XInputGetState(DWORD dwUserIndex, XINPUT_STATE* pState) { FIXME("Stub - Controller: %d \n", dwUserIndex); if (dwUserIndex >= 0 && dwUserIndex < 4) { return ERROR_DEVICE_NOT_CONNECTED; /* If controller is connected return ERROR_SUCCESS */ } return ERROR_BAD_ARGUMENTS; }

4 6

Re: [PATCH] [WinHelp]: fix for 15367
by James McKenzie 25 Oct '08

25 Oct '08

Eric Pouech wrote: > > A+ > --- > > Eric: Was this patch rejected or pending approval? James McKenzie

1 0

RFC: wineprefix manager
by Steven Edwards 25 Oct '08

25 Oct '08

Hello, Over the past few months I've been developing a tool that I had hoped to demo at wineconf before my laptop started acting up. It is a Wine Prefix Manager I developed for Bordeaux, At this time its still tied pretty closely to glib and GTK and riddled with my horrid programing errors. Attached you will find a screenshot of the concept we are using in Bordeaux I've spoken with Alexandre a bit about it and he expressed interested in possibly having it be a winelib application. This would pose some interesting design decisions as we would need to create a method of having a wine delay certain operations until after the program exited or be able to run a builtin winelib application outside of any given prefix. My development plan short term is pretty simple: 1. Develop this application in tools/wineprefixmanager and allow third parties to develop graphical interfaces using the toolkit of choice. This would allow a KDE, GTK or even winelib frontend to do prefix management 2. a. Extra wineprefixes would be stored in the ~/.wineprefixes folder. If a user wants to use multiple prefixes one must be set to default which would create a symbolic link to ~/.wine b. This implies the ability to import an existing ~/.wine 3. As Wine's ability to interact with the Desktop Environment of choice improves, so would the options for prefix management (as implied by the associate option in the example below) 4. As Wine develops better multiuser support, support for other locations for storage of Global prefixes will have to be taken in to account. Alexandre also raised the question about if this would even really be all that useful. Below are the possible command line options we could support: Possible command line options include --active set a selected prefix as active or default --associate restore file associations --backup backup a selected prefix to a compressed archive --configure invoke winecfg after creation --copy copy a selected prefix to another name --create create based on a template such as default, win2000, winxp, etc. --delete delete a selected prefix --execute execute a windows application for a given prefix --force force operation without prompting --import import from and existing .wine directory --restart simulate a windows reboot for a given prefix --restore restore prefix from existing archive --list display a list of the current prefixes --menu regenerate Desktop and Menu entries --target TARGET option for --backup --copy and --create If there are no major objections and or no better ideas then over the next few months I will start refactoring the mess that is the Bordeaux Cellar Manager, breaking it out in to a non-glib command line only application, removing Bordeaux only options, submitting it as a series of patches, etc. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 1