December 2006 - Wine-Devel - list.winehq.org

Re: Vijay Kiran Kamuju : comctl32: MonthCalendar - Fix highlightingof current date.

by James Hawkins

On 12/27/06, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi, > > It might be because of the MULTISELECT style not being set. > Can you please test with the MULTISELECT set? > In the older version of the control spy test its set by default, and > in the new version its not set. > Can you please test that and also test by applying the other patch as well? > Currently I am tidying it up and putting some comments. > As the order of messages sent is a bit messed up. > Dimitry: > What do we need to setup, if we want a test framework for messages in > comctl32 similar to user32? > Lei and Dan, > This can also be a good exercise. > But I will try to do it myself first. > > Cheers, > VJ I wouldn't worry about it. I have a patch that adds message testing for comctl32. I'll send it in when I get back from vacation (couple of days, stuck in a blizzard). -- James Hawkins

Dec. 30, 2006

Re: riched20: block recursive notification

by Matt Finnicum

On 12/30/06, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > > This patch blocks riched20 from recursivly sending an EN_CHANGE > notification. > Fixes bug 6985. > > Thanks, > Clinton Stimpson > > ChangeLog > Block recursive EN_CHANGE notifications. If you're adding a new variable to the ME_TextEditor structure then you should probably also initialize it in ME_MakeEditor. Naming the variable "notify" is somewhat ambiguous, and there seems to be an established convention of naming int's with the 'n' prefix, like nNotifiy. You should probably comment to explain what the variable is for or attempt to name it something more self evident. Maybe a BOOL would be more appropriate, unless you're intending to extend this to other notify calls as well. Lastly, I don't see why this patch is needed - it only prevents the ME_SendOldNotify (which just calls SendMessageA) from triggering another call of that same EN_CHANGE notification. I don't see why calling SendMessageA would cause ME_UpdateRepaint to be called. Maybe the application you're working with, in processing the EN_CHANGE message, is sending another message to which we wrongly are sending an EN_CHANGE notification - so thus we should fix our message handling of that. A quick look at MSDN shows that "The EN_CHANGE notification message is sent when the user has taken an action that may have altered text in an edit control." - it seems that we may be sending them whenever any action (user or not) has altered text in the control. We really could use some tests to see what should generate EN_CHANGE messages. Another possibility is that we don't handle the case where (again, from MSDN) "The EN_CHANGE notification is not sent when the ES_MULTILINE style is used and the text is sent through WM_SETTEXT." - perhaps your application has ES_MULTILINE set and uses a WM_SETTEXT in response to the EN_CHANGE notification? Thanks for your help with richedit, --Matt Finnicum

Dec. 30, 2006

problems with installed wine

by Corey McClymonds

for almost a week now, wine has been acting weird. I compile wine and using it from the wine source tree, everything works perfectly. But if I make install it, then try to use it, all I get is a black screen that I have to alt-tab to get out of. On a note, it works fine if I run as root. I have blown away my .wine directory, it doesn't help. I compile from git. Corey McClymonds

Dec. 30, 2006

Re: wine-patch OleIconToCursor function

by Frank Richter

On 30.12.2006 18:54, Marcus Meissner wrote: >> +/*********************************************************************** >> + * OleIconToCursor (OLEAUT32.415) >> + */ >> +HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon) >> +{ >> + FIXME("(%p,%p), (olepro32.dll), partially implemented.\n",hinstExe,hIcon); >> + if (hIcon) >> + return CopyCursor(hIcon); >> + else >> + return NULL; >> + >> + /* FIXME >> + make a extended conversation from HICON to HCURSOR >> + */ >> +} According to http://msdn2.microsoft.com/en-us/library/ms694362.aspx, this function just does a simple CopyCursor() on Win32. And since there doesn't seem to be a need for further changes to that function, the FIXME trace as well as comment could both be removed. -f.r.

Dec. 30, 2006

Re: wine-patch OleIconToCursor function

by Marcus Meissner

On Sat, Dec 30, 2006 at 04:49:27AM +0100, Bernard Ladenthin wrote: > Hello, > in the attachment is a small patch for the OleIconToCursor function. > The function works with this. I hope i can help with this and get a > response mail that this mail have received. I haven't any experiences > with git so it's a simply patch. > > I have tested it with the "Lexware Buchhalter 2005". > You can download it from http://server.ladenthin.net/bh2005.zip to see > that it works. Start with wine the "LxStart.exe" and turn over the > Text and Icon with the mouse, the icon is now the cursor. > > Best regards from Germany, > Bernard Ramon Ladenthin In general you do no need to edit Changelog yourself. Just add a note above the patch. Otherwise it looks fine to my eyes (and perhaps Alexandres too), thanks! Ciao, Marcus > diff --git a/ChangeLog b/ChangeLog > index 3b536b5..9723401 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2006-12-30 Bernard Ramon Ladenthin <bernard(a)ladenthin.net> > + > + * dlls/oleaut32/oleaut.c, dlls/oleaut32/stubs.c: > + oleaut32: Implement the function OleIconToCursor and remove the stub. > + > 2006-12-22 Dmitry Timoshkov <dmitry(a)codeweavers.com> > > * dlls/user32/tests/msg.c, dlls/winex11.drv/winpos.c: > diff --git a/dlls/oleaut32/oleaut.c b/dlls/oleaut32/oleaut.c > index d6a08a9..65a4174 100644 > --- a/dlls/oleaut32/oleaut.c > +++ b/dlls/oleaut32/oleaut.c > @@ -837,3 +837,19 @@ BOOL WINAPI DllMain(HINSTANCE hInstDll, > > return TRUE; > } > + > +/*********************************************************************** > + * OleIconToCursor (OLEAUT32.415) > + */ > +HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hIcon) > +{ > + FIXME("(%p,%p), (olepro32.dll), partially implemented.\n",hinstExe,hIcon); > + if (hIcon) > + return CopyCursor(hIcon); > + else > + return NULL; > + > + /* FIXME > + make a extended conversation from HICON to HCURSOR > + */ > +} > diff --git a/dlls/oleaut32/stubs.c b/dlls/oleaut32/stubs.c > index ac2d494..d87e76e 100644 > --- a/dlls/oleaut32/stubs.c > +++ b/dlls/oleaut32/stubs.c > @@ -33,15 +33,6 @@ > WINE_DEFAULT_DEBUG_CHANNEL(ole); > > /*********************************************************************** > - * OleIconToCursor (OLEAUT32.415) > - */ > -HCURSOR WINAPI OleIconToCursor( HINSTANCE hinstExe, HICON hicon) > -{ > - FIXME("(%p,%p), not implemented (olepro32.dll)\n",hinstExe,hicon); > - return S_OK; > -} > - > -/*********************************************************************** > * OleCreatePropertyFrameIndirect (OLEAUT32.416) > */ > HRESULT WINAPI OleCreatePropertyFrameIndirect( LPOCPFIPARAMS lpParams) >

Dec. 30, 2006

Reason for some process failures in kernel32 tests

by Paul Vriens

Hi, I've been trying to tackle some of the issues we have when trying to run some process tests (through winetest.exe, see also http://test.winehq.org/data) process.c:775: Test failed: CreateProcess (./kernel32_test.exe tests/process.c C:\TEMP\wt44.tmp "a\"b\\" c\" d) failed : 2 process.c:777: Test failed: Child process termination process.c:781: Test failed: Arguments:argvA0 expected './kernel32_test.exe', got '(null)' process.c:790: Test failed: CreateProcess (.\kernel32_test.exe tests/process.c C:\TEMP\wt45.tmp "a\"b\\" c\" d) failed : 2 process.c:792: Test failed: Child process termination process.c:796: Test failed: Arguments:argvA0 expected '.\kernel32_test.exe', got '(null)' process.c:810: Test failed: CreateProcess (..\wct12/kernel32_test.exe tests/process.c C:\TEMP\wt46.tmp "a\"b\\" c\" d) failed : 2 process.c:812: Test failed: Child process termination process.c:816: Test failed: Arguments:argvA0 expected '..\wct12/kernel32_test.exe', got '(null)' The reason for this particular one is that I'm running winetest.exe started from a command-file on my desktop. This means that the current directory is the desktop directory. The winetest gui shows that the working directory is (in this case) c:\temp\wct12. This value is however not passed to the tests when CreateProcess is run: main.c: 291 if (!CreateProcessA (NULL, cmd, NULL, NULL, TRUE, 0, 292 NULL, NULL, &si, &pi)) { The above means that the kernel32_test.exe has a working directory that is not c:\temp\wct12 (in this case again) and thus cannot find the executable when referenced relatively. All the test-results that are shown on http://test.winehq.org show more-or-less the same behavior. How can I retrieve the correct working directory (as shown in the winetest gui) and pass that to the single tests? (I think that would solve these particular issues). Cheers and thanks for any pointers, Paul.

Dec. 30, 2006

Re: USB

by Damjan Jovanovic

On 12/30/06, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > A franklin eBookMan using the provided Windows Software. (By the way, it's bad practice to top-post bottom-posted emails.) What interface does the device provide? Is it a mass-storage device? Or some vendor-specific protocol? Do "lsusb -v" and see the class and subclass -if they're 0xFF (vendor-specific), you're probably out of luck, because: If the Windows software includes .SYS files, wine can't load those yet (although wine's NTOSKRNL.EXE is coming soon, right?) Since wine is largely designed for running Windows applications on Linux, a lot of the hardware support infrastructure (SETUPAPI, CFGMGR, ...) is still missing. At present, a Windows app cannot directly access the hardware, only indirectly (for example, it can save a file to a mass-storage device supported by Linux, or communicate through a USB ethernet controller supported by Linux). Now in Windows, applications don't access USB directly either (Windows only allows USB control packets from user-space, not bulk, interrupt or isochronous, and no app I know uses that interface anyway). What apps usually do is open a .SYS device driver (eg. \\.\USBSCAN0\2) and use ReadFile to send bulk data, WriteFile to receive bulk data, and DeviceIoControl for everything else. So in theory if you figure out the interface between the application and the driver in Windows, you can write a kernel module for Linux that does the same, and your app can communicate with the hardware. Wine currently doesn't do this at all, although I've written a semi-complete implementation of STI and USBSCAN.SYS this way, and it works with native TWAIN drivers. Damjan > Andrew > > > On 12/30/06, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > >> How do you get a Windows program access to the USB port ? > > > > What are you trying to do? What device are you accessing? > > > >> Andrew > > > > Damjan > > > > > > > -- > Andrew Ramage > > >

Dec. 30, 2006

Re: USB

by Damjan Jovanovic

On 12/30/06, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > How do you get a Windows program access to the USB port ? What are you trying to do? What device are you accessing? > Andrew Damjan

Dec. 30, 2006

USB

by Andrew Neil Ramage

How do you get a Windows program access to the USB port ? -- Andrew "Oh, bother," said the Borg. "We've assimilated Pooh."

Dec. 30, 2006

Re: bump: windows web server app fails to send more than 11680 bytes !?

by Kai Blin

On Saturday 30 December 2006 09:20, [IDC]Dragon wrote: > I'd like to humbly bump my bug report: > http://bugs.winehq.org/show_bug.cgi?id=6415 I've had a look at it and couldn't recreate the problem. What setup do you have? (I'm not running the web server on port 80, because that's where my apache is sitting, and I don't feel like running wine as root. I'd be surprised if that changes anything, though.) Looking at my +winsock trace, it seems to be looping over the WSASendTo just fine. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Dec. 30, 2006