- Wine-devel - list.winehq.org

Re: int 33
by Andreas Mohr 26 Jan '02

26 Jan '02

On Sat, Jan 26, 2002 at 05:34:33PM +0200, Nog wrote: > With this patch I can get into the copy protection screen in monkey > island 2 but the keyboard still doesn't work. > > Changelog: > * dlls/winedos/int33.c > Implement function number 0x5 (Return mouse button press information) > > nog > > P.S. Does anyone know how the Mouse motion counters (function 0xb) work? >From Ralf Brown's Intlist: --------M-33000B----------------------------- INT 33 - MS MOUSE v1.0+ - READ MOTION COUNTERS AX = 000Bh Return: CX = number of mickeys mouse moved horizontally since last call DX = number of mickeys mouse moved vertically Notes: a mickey is the smallest increment the mouse can sense positive values indicate down/right SeeAlso: AX=0003h,AX=001Bh,AX=0027h -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re: int 33
by Nog 26 Jan '02

26 Jan '02

Sorry forgot the file. Nog wrote: > With this patch I can get into the copy protection screen in monkey > island 2 but the keyboard still doesn't work. > > Changelog: > * dlls/winedos/int33.c > Implement function number 0x5 (Return mouse button press > information) > > nog > > P.S. Does anyone know how the Mouse motion counters (function 0xb) work? > > > > > Index: dlls/winedos/int33.c =================================================================== RCS file: /home/wine/wine/dlls/winedos/int33.c,v retrieving revision 1.1 diff -u -r1.1 int33.c --- dlls/winedos/int33.c 2001/12/04 19:54:45 1.1 +++ dlls/winedos/int33.c 2002/01/26 15:17:29 @@ -19,6 +19,7 @@ static struct { DWORD x, y, but; + WORD lbcount, rbcount, rlastx, rlasty, llastx, llasty; FARPROC16 callback; WORD callmask; } mouse_info; @@ -52,6 +53,22 @@ case 0x04: FIXME("Position mouse cursor\n"); break; + case 0x05: + TRACE("Return Mouse button press Information for %s mouse button\n", + BX_reg(context) ? "right" : "left"); + if (BX_reg(context)) { + BX_reg(context) = mouse_info.rbcount; + mouse_info.rbcount = 0; + CX_reg(context) = mouse_info.rlastx; + DX_reg(context) = mouse_info.rlasty; + } else { + BX_reg(context) = mouse_info.lbcount; + mouse_info.lbcount = 0; + CX_reg(context) = mouse_info.llastx; + DX_reg(context) = mouse_info.llasty; + } + AX_reg(context) = mouse_info.but; + break; case 0x07: FIXME("Define horizontal mouse cursor range\n"); break; @@ -106,7 +123,8 @@ if (!VGA_GetMode(&Height,&Width,NULL)) { /* may need to do some coordinate scaling */ - SX = 640/Width; + if (Width) + SX = 640/Width; if (!SX) SX=1; } mouse_info.x = LOWORD(lParam) * SX; @@ -119,6 +137,9 @@ case WM_LBUTTONDBLCLK: mouse_info.but |= 0x01; mask |= 0x02; + mouse_info.llastx = mouse_info.x; + mouse_info.llasty = mouse_info.y; + mouse_info.lbcount++; break; case WM_LBUTTONUP: mouse_info.but &= ~0x01; @@ -128,6 +149,9 @@ case WM_RBUTTONDBLCLK: mouse_info.but |= 0x02; mask |= 0x08; + mouse_info.rlastx = mouse_info.x; + mouse_info.rlasty = mouse_info.y; + mouse_info.rbcount++; break; case WM_RBUTTONUP: mouse_info.but &= ~0x02;

1 0

Filename parsing
by Duane Clark 26 Jan '02

26 Jan '02

Modified files: dlls/commdlg : file.c Log message: Codeweavers Add SHGDN_FORPARSING flag when looking for filenames. Index: dlls/commdlg/filedlg95.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/filedlg95.c,v retrieving revision 1.62 diff -u -r1.62 filedlg95.c --- dlls/commdlg/filedlg95.c 2001/12/04 19:39:33 1.62 +++ dlls/commdlg/filedlg95.c 2002/01/26 14:54:17 @@ -2374,7 +2374,7 @@ { /* get the total length of the selected file names*/ lpstrTemp[0] = '\0'; - GetName( fodInfos->Shell.FOIShellFolder, pidl, SHGDN_INFOLDER, lpstrTemp ); + GetName( fodInfos->Shell.FOIShellFolder, pidl, SHGDN_INFOLDER|SHGDN_FORPARSING, lpstrTemp ); if ( ! IsPidlFolder(fodInfos->Shell.FOIShellFolder, pidl) ) /* Ignore folders */ { @@ -2403,7 +2403,7 @@ { /* get the file name */ lpstrTemp[0] = '\0'; - GetName( fodInfos->Shell.FOIShellFolder, pidl, SHGDN_INFOLDER, lpstrTemp ); + GetName( fodInfos->Shell.FOIShellFolder, pidl, SHGDN_INFOLDER|SHGDN_FORPARSING, lpstrTemp ); if (! IsPidlFolder(fodInfos->Shell.FOIShellFolder, pidl)) /* Ignore folders */ {

1 0

Patch for OLEClipbrd_IDataObject_GetData
by Sander van Leeuwen 26 Jan '02

26 Jan '02

Hi, Forte Agent was unable to copy text from the clipboard into the message body window because of a bug in this method. I'm not sure how Wine's clipboard implementation works, but handles returned by GetClipboardData are not supposed to be valid after the app calls CloseClipboard (see MS docs). The attached patch makes a copy of the clipboard handle and passes that to the application. Forte Agent frees this handle after it has extracted the clipboard data, so there's no memory leak. Sander

1 0

The cat is out of the bag (Lindows)
by Hetz Ben Hamo 26 Jan '02

26 Jan '02

Hi People, In case you didn't see - Lindows "preview" review is on www.newsforge.com... Hetz

1 1

cvs run
by lee johnson 26 Jan '02

26 Jan '02

just got wine cvs but it refuses to run even with copying missing shared file from $HOME to say /usr/lib here is error: --------------- [codewind(a)imyourhandiman codewind]$ wine wine: error while loading shared libraries: libwine.so: cannot open shared object file: No such file or directory [codewind(a)imyourhandiman codewind]$ thx lee -====

2 1

Does Windows have one of these?
by Bill Medland 25 Jan '02

25 Jan '02

As I look deeper into the DrawText boundary behaviour it becomes clear to me that the Microsoft version must actually keep the & symbols in the string until the very last moment. In particular it looks to me like they actually measure strings that contain them. I can't see how they can do that with GetTextExtent and its relatives; I can't see where to hide a flag as to whether to interpret the & or not. Does anyone know if there are Microsoft undocumented functions or undocumented ways to measure and output a text that includes & symbols with a way of specifying whether they count as prefix characters or not? Personally it seems silly to me and I don't intend doing so myself unless there is a good reason to duplicate all of Microsoft's weird bugs. Bill

1 0

RE: Excessive clipping of text in listview
by Medland, Bill 25 Jan '02

25 Jan '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi(a)cs.toronto.edu] > Sent: Friday, January 25, 2002 9:11 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: Excessive clipping of text in listview > > > On Fri, 25 Jan 2002, Bill Medland wrote: > > > Does anyone know how we (again) broke the text in the large > icon display of > > listview? It seems to come and go as we develop. > > <blush>I probably broke it</blush> I know the feeling. (not surprising given the size of the delta; you ought to see what my last big one would have screwed up). > > > The symptom. Our application has a ListView window. As of > yesterday's cvs > > most of the text only displays about 2 or 3 pixels wide, > while a few are > > readable. > > Are you using Unicode or ANSI? Can I get access to the code > to test with? ANSI Do you have access to the Microsoft "rowlist" sample? If so then use that but edit a couple of the labels to be longer than one line. It's the "being longer than one line" that messes it up. > > > I am just backtracking but I'm in a rush (I have to put together > > a demo machine by yesterday) and I'd like to know how far > back to go. > > Tell me, is 1.106 OK? Most likely the patch 1.106 -> 1.107 broke it. It did work on 1/jan so it was probably your delta. > > > -- > Dimi. > Thanks for the rapid response Bill p.s. what is going on in DrawLargeItem with the ellipsification; it looks like it ellipsifies it and then throws the result away. I am currently working on DrawText which should provide everything needed to draw the text properly. I am feeding it to Alexandre in small pieces so that we don't break anything. Microsoft, as far as I can see, don't actually use DrawText; they appear to reimplement all the ellipsification but I don't see why.

3 6

RE: Excessive clipping of text in listview
by Medland, Bill 25 Jan '02

25 Jan '02

Panic over; the 20020101 version will do for now. > -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi(a)cs.toronto.edu] > Sent: Friday, January 25, 2002 9:11 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: Excessive clipping of text in listview > > > On Fri, 25 Jan 2002, Bill Medland wrote: > > > Does anyone know how we (again) broke the text in the large > icon display of > > listview? It seems to come and go as we develop. > > <blush>I probably broke it</blush> > > > The symptom. Our application has a ListView window. As of > yesterday's cvs > > most of the text only displays about 2 or 3 pixels wide, > while a few are > > readable. > > Are you using Unicode or ANSI? Can I get access to the code > to test with? > > > I am just backtracking but I'm in a rush (I have to put together > > a demo machine by yesterday) and I'd like to know how far > back to go. > > Tell me, is 1.106 OK? Most likely the patch 1.106 -> 1.107 broke it. > > > -- > Dimi. >

1 0

Excessive clipping of text in listview
by Bill Medland 25 Jan '02

25 Jan '02

Does anyone know how we (again) broke the text in the large icon display of listview? It seems to come and go as we develop. The symptom. Our application has a ListView window. As of yesterday's cvs most of the text only displays about 2 or 3 pixels wide, while a few are readable. I am just backtracking but I'm in a rush (I have to put together a demo machine by yesterday) and I'd like to know how far back to go. Bill

2 1