August 2005 - Wine-Devel - list.winehq.org

Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken

by Hiji

Looks like someone else is having this problem. I've tried looking at listview.c and the treeview equivalent as well, but I can't made heads or tails of it. I have no experience with C. Anybody on this list make any changes to listview or treeview in the last few months? Hiji > ------- Additional Comments From > qingdao33122(a)yahoo.com 2005-04-08 23:58 ------- > About the same problem with AceFTP > > Free download for trial > http://software.visicommedia.com/en/products/aceftpfreeware/ > > wine-20050524-1fc1winehq > > Problem starts before I do the FTP thing. > When I drag a file within the local pane(a > listview), > a copy of that file is immediately created. But > things > don't stop there. The moment I move the mouse a bit, > AceFTP asks me with a popup menu if want to: > Move to current location > Copy to current location or > Create a short > If I choose to copy, ANOTHER copy of the file is > created. > After that, every time I move the mouse, > AceFTP asks me again, thus an infinite loop > and infinite number of copies of the same file. > > BTW. I have to use native shell related dlls for > AceFTP to > display the local pane. So I suspect the problem is > with > the interaction between native and builtin code. > > I hope my English is good enough for me to make some > sense... > > -- > Configure bugmail: > http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Aug. 5, 2005

Re: Automatic ANSI<>Unicode message translation

by Troy Rollo

On Fri, 5 Aug 2005 13:22, Dmitry Timoshkov wrote: > I very carefully have read your mail, the code, and the results you have > got. Did you try to remove SetCPGlobal calls and see whether it actually > changes anything? Obviously you didn't, because if you did you'd realise that each program performs 3 series of tests - one before *any* calls to SetCPGlobal, then a series after each value of SetCPGlobal. You would also have realised that one of the tests was performed on a system whose native code page is 950, particularly since I (1) said as much and (2) show the default code page as the first line of output in each test file (which you would have noticed either by reading the source file or by looking at the test output). You haven't mentioned any tests you have done that show some other behaviour. If you have, supply them and show your results. By the way: >> WM_CHAR messages are delivered "immediately" whether sent by SendMessage or >> PostMessage. > >Actually not immediately, just fast enough, so that GetMessage/DispatchMessage >delivers a message while the thread does Sleep. Why do you think I put the word in quotes?

Aug. 5, 2005

Re: Automatic ANSI<>Unicode message translation

by Dmitry Timoshkov

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > > I skipped everything else since the tests apparently do not run on a proper > > (or rather expected) locale, and the results basically show what you would > > get on an english locale without SetCPGlobal hacks. > > You clearly neither read my message very carefully nor really looked at what > the code was doing. Try again after you have. I very carefully have read your mail, the code, and the results you have got. Did you try to remove SetCPGlobal calls and see whether it actually changes anything? -- Dmitry.

Aug. 5, 2005

Re: Automatic ANSI<>Unicode message translation

by Troy Rollo

On Fri, 5 Aug 2005 12:59, Dmitry Timoshkov wrote: > I skipped everything else since the tests apparently do not run on a proper > (or rather expected) locale, and the results basically show what you would > get on an english locale without SetCPGlobal hacks. You clearly neither read my message very carefully nor really looked at what the code was doing. Try again after you have.

Aug. 5, 2005

Re: Automatic ANSI<>Unicode message translation

by Dmitry Timoshkov

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > I have just finished running a series of tests using the attached programs - > msgchar, msgchar2 and msgchar3. > > * The short version: > > WM_CHAR messages are delivered "immediately" whether sent by SendMessage or > PostMessage. Actually not immediately, just fast enough, so that GetMessage/DispatchMessage delivers a message while the thread does Sleep. [skipped] > When using SendMessageA to send WM_CHAR to a window registered with > RegisterClassA, no conversion is performed even if the threads have different > values for CP_THREAD_ACP. > > In other words, where a conversion is performed it is always based on the > modified CP1252, which has the effect that no visible conversion is ever > performed for A->A messages. That just means that your way of changing system locale using SetCPGlobal doesn't work (not mentioning that it's quite strange to call an API in a DLL after FreeLibrary, that works because kernel32 is already loaded before LoadLibrary). I skipped everything else since the tests apparently do not run on a proper (or rather expected) locale, and the results basically show what you would get on an english locale without SetCPGlobal hacks. -- Dmitry.

Aug. 5, 2005

Re: Automatic ANSI<>Unicode message translation

by Troy Rollo

On Wed, 27 Jul 2005 20:34, Alexandre Julliard wrote: > Since there is no way of knowing if the target window uses the same > code page, or even if its code page won't change between the time the > message is stored in the queue and when it is retrieved, the only sane > approach is to store messages in the queue in Unicode. Only > SendMessage calls that bypass the queue avoid the translation. I'm > pretty sure that this is what Windows does too, if you have a test > demonstrating the opposite I'd be very interested to see it. I have just finished running a series of tests using the attached programs - msgchar, msgchar2 and msgchar3. * The short version: WM_CHAR messages are delivered "immediately" whether sent by SendMessage or PostMessage. Where there is a conversion from A->W or W->A, the conversion is performed using a modified CP1252 table regardless of the values of CP_THREAD_ACP and CP_ACP. Effectively, when sending a message to a window that was created by a thread in a different code page, if SendMessageA is used, no translation is performed. This was tested on a Win2k system with a default of CP1252 (Western Europe) and a WinXP system with a default ACP of CP950 (Chinese Traditional). The table used for the conversion differs from the real CP1252 table in that characters 81, 8D, 8F, 90 and 9D, which are unassigned in CP1252, are converted to and from the Unicode characters with the same value (+). This results in a round-trippable conversion via Unicode, so that for WM_CHAR PostMessageA to an ANSI window will always work provided the data is in the code page expected by the recipient, but SendMessageA and PostMessageA to a Unicode window and SendMessageW and PostMessageW to an ANSI window are only guaranteed to get the correct result if CP1252 is used or the messages are limited to characters in the range 0x00->0x7f (assuming nothing exotic has been done like setting the ACP to an EBCDIC code page). (+) - The CP1252 table in libs/unicode/c_1252.c does the same thing, but is seems Microsoft's CP1252 table also does this despite the fact that every published document on the code page says those characters are undefined. * The long version The first two programs create windows after setting the thread locale to be Chinese Traditional, which results in a CP_THREAD_ACP of 950. They then create additional threads with a locale of Japanese, which gets a CP_THREAD_ACP of 932. They create windows using both the W and A versions of the RegisterClass and CreateWindow API calls, and then tests sending messages using SendMessageA and SendMessageW for Unicode character 0x6893 (CP932 0x88 0xB2 and CP950 0xB1 0xEA). The difference between msgchar and msgchar2 is that the first uses GetMessageA/DispatchMessageA and the second uses GetMessageW/DispatchMessageW. The third program tests more characters and the 950->932 direction and 950->950 transmissions, and was used to verify that a modified CP1252 is what is being used. Note that 0x88, which is a lead byte in CP892, is one of the characters that maps outside the Latin1 page in Unicode (CP1252 0x88 is Unicode 0x02C6), which makes double-byte characters beginning with that code ideal for these tests. The results were surprising. No matter what I did, when SendMessageW was used to send WM_CHAR to a window registered with RegisterClassA, the conversion was performed using a modified CP1252 - even if the system code page and thread code page for the receiving thread was CP950. When sending WM_CHAR using SendMessageA to a window registered with RegisterClassW, the conversion was also performed using CP1252 - even if the code page and thread code page for the receiving thread was CP950 (and for the sending thread was CP932). When using SendMessageA to send WM_CHAR to a window registered with RegisterClassA, no conversion is performed even if the threads have different values for CP_THREAD_ACP. In other words, where a conversion is performed it is always based on the modified CP1252, which has the effect that no visible conversion is ever performed for A->A messages. In the first 3 sets of results (the ones listed as "results.*"), W->W PostMessages lose information because GetMessageA and DispatchMessageA are used. The next 2 sets of results (listed as "results2.*") do not show this loss, suggesting that messages are stored in the queue in "Unicode" based on the modified CP1252 conversion. A 5 second delay was used between all calls to SendMessage and PostMessage, and lead bytes were never being held back to wait for the trail bytes. Obviously Windows is fundamentally broken in the way it handles this. The general rule for applications has to be that if IsWindowUnicode is true, use SendMessageW with the Unicode character, and if false, use SendMessageA with the ANSI character, preferably knowing the code page expected by the recipient. Applications should avoid GetMessageA, TranslateMessageA and DispatchMessageA and use the W ones exclusively (since they might be processing a message for a Unicode window - perhaps the rich edit control?) I also ran the program under Wine to test its behaviour, which does not match the behaviour of Windows at all. The source to the test programs is attached, together with the output of the tests.

Aug. 5, 2005

Re: ntdll: Fix raw CD-ROM access on Linux

by Jesse Allen

On 8/3/05, Tobias Gruetzmacher <tobias(a)portfolio16.de> wrote: > Hi, > > after submitting my bugreport > http://bugs.winehq.com/show_bug.cgi?id=3175 I curefully checked the > transfer directions in dlls/ntdll/cdrom.c. I think, they are reversed at > two places. > > The attached patch fixes my reported bug. This may also fix bug 3143. > It does fix the bug. Actually, both games use SIntfNT.dll, so we got a duplicate bug report. Thanks for tracking down the issue. Jesse

Aug. 4, 2005

Re: [DSHOW] Beginning of winestrmbase lib (resend)

by Christian Costa

Dimi Paun wrote: >From: "Christian Costa" <titan.costa(a)wanadoo.fr> > > >>Add winestrmbase library and make quartz use it. >> >> > >If this is wine specific, and it's supposed to be >streambase library, I think winestreambase is maybe >a clearer name, winestrmbase makes it sound like >a string processing lib. :) > > > Well, I chose this name because the Direct Show SDK provides the strmbase.lib library. The purpose is quite the same so I kept the same name and prefixed it since it's wine specific. But hey, I don't mind changing in to winestreambase it it makes less confusion. :-)

Aug. 4, 2005

Re: [DSHOW] Beginning of winestrmbase lib (resend)

by Dimi Paun

From: "Christian Costa" <titan.costa(a)wanadoo.fr> > Well, I chose this name because the Direct Show SDK provides the > strmbase.lib library. > The purpose is quite the same so I kept the same name and prefixed it > since it's wine specific. But if that's the case, shouldn't we just name it strmbase and make it compatible? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Aug. 4, 2005

Re: compile error in current cvs

by Stefan Leichter

Am Donnerstag, 4. August 2005 21:02 schrieb Jacek Caban: > Michael Jung wrote: > >On Thursday 04 August 2005 18:35, Stefan Leichter wrote: > >>current cvs does not compile for me. Im on SuSE 9.0 > > > >This seems to be a missing configure check for the libxml2 development > >headers. For a quick fix on Debian sarge you can install the libxml2-dev > >package. > > > >Bye, > > In Gentoo you need to create link: > /usr/include/libxml -> /usr/include/libxml2/libxml > but it seams to be Gentoo specific thing and I'm > not sure how to support it property in Wine. > > Jacek Good shot, this fixes my problem too. Thanks Stefan

Aug. 4, 2005