Re: gdi32: Use the LOGFONT charset field on OEM font creation
Hi, Is this patch incorrect or more tests are needed? Dmitry said that there are needed additional tests, but you wouldn't like to commit these. Please explain my mistakes. -- Best regards, Ilya Shpigor.
Re: gdi32: Use the LOGFONT charset field on OEM font creation
On Tuesday 05 January 2010 17:08:52 Dmitry Timoshkov wrote: Ilya Shpigor shpi...@etersoft.ru wrote: Some explanation for this patch: The fsCsb is bitfield that is used as boolean value. If this is false the DEFAULT_CHARSET is using and the real charset is choosen through the current ANSI codepage. But this is mistake in case of the OEM charset. A real fix would be to add Terminal font to Wine. If the Terminal font will be changed in test to Tahoma this still be failed. Are you sure what the current behavior of the WineEngCreateFontInstance is correct? When the user create logical font with OEM charset the GetTextCharset function will be always return ANSI independently of font name. This conversions occurs because of the current logic WineEngCreateFontInstance. Can there be a solution for the already existed fonts? -- Best regards, Ilya Shpigor.
Re: [TRY 2] extrac32: Create directory tree before extraction
Hi, Why this patch don't have been commited? There are mistakes? I really want to make extrac32 better, but I don't know what to do if nobody answer me. -- Best regards, Ilya Shpigor.
Re: comctl32: Implementation the WM_GETTEXT processing of datetime control
Hi, Thanks for reply. I don't think it's a right way. You probably should use window text instead updating it on every change, see how GetWindowText is implemented. GetWindowText work with the server side text buffer. Are you offer to use it? I don't sure that control text and this kind of window text are same things. Datetime control have own interpretation of data in the self text buffers. Using window text will need some synchronization when this data change. Can I do it? -- Best regards, Ilya Shpigor.
Re: comctl32: Implementation the WM_GETTEXT processing of datetime control
Or course you can, format a string every time contents change and store it with SetWindowText(). WM_GETTEXT will work through default procedure (I've done it that way for IPAddress control). This is good idea, but SetWindowText just send the WM_SETTEXT message. Your patch comctl32/datetime: Block WM_SETTEXT message don't allow to do it. Anyway GetWindowText should work, and Wine's implementation uses WM_GETTEXT only for same process windows, so you shouldn't override default handling for this message. This possible to test: is the datetime window procedure process WM_GETTEXT? This message must be send to control directly and be processed through CallWindowProc with DefWindowProc parameter. Is this test give right results? P.S. Also don't forget comments regarding tests part. The second try of test have been send. -- Best regards, Ilya Shpigor.
Re: user32/tests: Test edit control to WM_GETTEXT processing after WM_DESTROY
Please don't commit this test. Instead use or comment next try: user32: Destroy EDITSTATE structure in the WM_NCDESTROY message processing -- Best regards, Ilya Shpigor.
Re: [1/2] extrac32: Add command-line parsing
Hi, What about this group of two patches? Is this correct or there are mistakes? -- Best regards, Ilya Shpigor.
Re: [TRY 2] [1/3] programs: initial add extrac32 utility
You need to include patched configure.ac as well with new WINE_CONFIG_MAKEFILE entry. Are there other troubles in these patches? -- Best regards, Ilya Shpigor.
Re: [TRY 2] [1/3] programs: initial add extrac32 utility
Hi, Nikolay You need to include patched configure.ac as well with new WINE_CONFIG_MAKEFILE entry. Are you shure what the changes in configure.ac needed? Andrey Turkin wrote in list below: No you don't need to (most patches do add some subset of autogenerated files for some reason but it is not necessary). -- Best regards, Ilya Shpigor.
Re: [TRY 4] user32/tests: Add tests for STM_SETIMAGE and STM_SETICONmessage processing
On Tuesday 29 September 2009 10:57:45 you wrote: You should use SendMessageA instead of SendMessageW to make the test run under Win9x as well. Testing the return value of SendMessage would be also helpful. Hi, The TRY 5 of tests had beent sent. Is it correct or my test so bad that nobody doesn't like to answer? :) -- Best regards, Ilya Shpigor.
Re: comctl32: Send the parent notification after the Wine has set the tooltip position (bug #14336)
On Monday 28 September 2009 19:36:05 you wrote: Could you please add a test for that? Test for this patch has been sent: comctl32/tests: Add test for setting the tooltips position by parent -- Best regards, Ilya Shpigor.
Re: user32: Add check for the need to redraw static control after STM_SETIMAGE and STM_SETICON
On Saturday 26 September 2009 12:09:30 Nikolay Sivov wrote: --- + if ((style SS_TYPEMASK) != SS_ICON) return (HICON)-1; ... + if ((style SS_TYPEMASK) != SS_BITMAP) return (HBITMAP)-1; ... + if ((style SS_TYPEMASK) != SS_ENHMETAFILE) return (HENHMETAFILE)-1; --- Add tests for that please (MSDN tells about 0 return value on error). Yes, MSDN tells about 0. The -1 value is used for detecting the errors inside Wine and blocking the static controls redrawing. Then the 0 value is returned to application: - STATIC_TryPaintFcn( hwnd, full_style ); + if (lResult != -1) + STATIC_TryPaintFcn( hwnd, full_style ); + else + lResult = 0; Tests for checking STM_SETIMAGE and STM_SETICON messages processing had been sent above: [TRY 3] user32/tests: Add tests for STM_SETIMAGE and STM_SETICON message processing Is there a better way to block this redrawing? -- Best regards, Ilya Shpigor.
Re: user32: Add check for the need to redraw static control afterSTM_SETIMAGE and STM_SETICON
First thing to do (as usual) is to add the test to show the drawing behaviour. Ok. I will make TRY 4 of tests. -- Best regards, Ilya Shpigor.
