April 2004 - Wine-devel - list.winehq.org

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 16 Apr '04

16 Apr '04

Could you take a look at this fix? I would think I have resolved the other issue with SetDefButton as well. Tests with msg ran fine. Regards Santosh Siddheshwar <<patch.diff>> > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry(a)baikal.ru] > Sent: Friday, April 16, 2004 1:35 PM > To: Santosh Siddheshwar; Alexandre Julliard > Cc: Robert Shearman; wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > This test fails with WINE even after I create the DIALOGINFO structure > the > > first time it enters DefDlgProc. Not sure why this test should work on > > Windows. > > Since I wrote it under Windows it apparently works there. > > > Basically at the stage where you are setting DM_SETDEFID there are > > no child windows on the dialog. > > Yes, I was also confused when I saw this for the first time. > > > Then what does DM_SETDEFID and DM_GETDEFID do when there are no child > > controls on the dialog? > > Looks like it should store id in the dialog structure, and only then try > to change the look of a control. > > > My guess is implementation of DEFDLG_SetDefButton > > may need to change. > > Yes, but that's another bug, not related to your patch. Although it would > be > great if you could fix that as well, don't bother if you have no time, > I'll > fix it later, this should be a very simple patch. > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

[Peter Riocreux] Re: dlls/kernel/console.c::SetConsoleCtrlHandler() cleanup/fixup
by Peter Riocreux 16 Apr '04

16 Apr '04

Sorry, mistyped the wine-patches address before ...

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 16 Apr '04

16 Apr '04

This test fails with WINE even after I create the DIALOGINFO structure the first time it enters DefDlgProc. Not sure why this test should work on Windows. Basically at the stage where you are setting DM_SETDEFID there are no child windows on the dialog. Then what does DM_SETDEFID and DM_GETDEFID do when there are no child controls on the dialog? My guess is implementation of DEFDLG_SetDefButton may need to change. Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry(a)baikal.ru] > Sent: Thursday, April 15, 2004 5:48 PM > To: Santosh Siddheshwar; Alexandre Julliard > Cc: Robert Shearman; wine-patches(a)winehq.com > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > OK.One place where this could be done is WM_NCCREATE which comes before > > WM_CREATE. Other place (possibly better) where it might be possible to > do > > this is in CBTProc hook procedure. Not sure about the second option > though. > > Any thoughts? > > Attached test case shows that dialog info is initialized on the very first > DefDlgProc invocation. > > So, DefDlgProc16/A/W as the very first thing should call DIALOG_get_info > and > if it returns NULL initialize dialog structures. > > Alexandre, please apply the test as soon as the dialog initialization is > fixed. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Add a message test for custom dialog initialization. > > -- > Dmitry. << File: msg.c.diff >> ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Re: [Darwine] compiling wine on Darwin/MacOS X 5/10
by Pierre d'Herbemont 16 Apr '04

16 Apr '04

Emmanuel, Index: libs/wine/loader.c =================================================================== RCS file: /home/wine/wine/libs/wine/loader.c,v retrieving revision 1.16 diff -u -r1.16 loader.c --- libs/wine/loader.c 2 Jan 2004 21:08:05 -0000 1.16 +++ libs/wine/loader.c 15 Apr 2004 18:17:07 -0000 @@ -182,6 +182,9 @@ +#ifdef __APPLE__ + if ((test_only == 0x2) && (ret = wine_dlopen(path, RTLD_NOW | RTLD_GLOBAL, error, errorsize ))) break; +#endif +#ifdef __APPLE__ + if (!(ntdll = dlopen_dll( "ntdll.dll", error, error_size, 0x2, &file_exists ))) return; +#else if (!(ntdll = dlopen_dll( "ntdll.dll", error, error_size, 0, &file_exists ))) return; +#endif These tests are no longer useful on Mac OS X. It was when ntdll was built as a dylib. However the check for environ is useful. Pierre On 15 avr. 04, at 23:36, emmanuel maillard wrote: > Hi, > here come some patches to build wine on Darwin/OS X > > Changelog > Build dylib on Darwin > > emmanuel > > <libs.diff>

1 0

Re: Wine fixes
by Dimitrie O. Paun 16 Apr '04

16 Apr '04

On April 16, 2004 12:16 am, Dimitrie O. Paun wrote: > IMO should just nuke some of these useless includes. > How can we test that they are really needed? Oops, sorry folks, this message was meant for the AbiWord guys! :) -- Dimi.

1 0

Re: abnt2 keyboard patch
by Rafael Ávila de Espíndola 16 Apr '04

16 Apr '04

> I still see problems with your patch. > > 1. You are using 'keysym == 0x2C' for comma, but what happens if NumLock > is on, and you press comma on the main keyboard, not on the keypad? > Shouldn't X11 send XK_KP_xxx event in that case (something like XK_KP_Decimal)? The file /usr/include/X11/keysymdef.h has the line #define XK_KP_Separator 0xFFAC /* separator, often comma */ This appears to be appropriate. But X11 is not sending it in debian (sid) or fedora. The output from xev when, with the numlock initially off, I press comma, kp_comma, numlock, comma and kp_comma is: KeyPress event, serial 22, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69979707, (124,72), root:(364,205), state 0x0, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69979799, (124,72), root:(364,205), state 0x0, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980420, (124,72), root:(364,205), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980521, (124,72), root:(364,205), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980955, (124,72), root:(364,205), state 0x0, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981057, (124,72), root:(364,205), state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981755, (124,72), root:(364,205), state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981850, (124,72), root:(364,205), state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69982436, (124,72), root:(364,205), state 0x10, keycode 91 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69982535, (124,72), root:(364,205), state 0x10, keycode 91 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," > 2. Please generate unified diffs, 'using diff -u' for patches. Sorry. I am really embarrassed. An unified diff is attached. > > -- > Dmitry. Rafael

2 1

Re: dlls/kernel/console.c::SetConsoleCtrlHandler() cleanup/fixup
by Dimitrie O. Paun 16 Apr '04

16 Apr '04

On April 15, 2004 11:18 am, Peter Riocreux wrote: > * This doesn't yet matter, since these handlers are not yet called...! > + * > + * Peter Riocreux (par(a)silistix.com) 2004-04-15 > + * Added error checking and now uses SetLastError() > */ One more thing: please don't add this sort of thing, it belongs in the CVS log, not in the source code. -- Dimi.

1 0

Re: [D3D8] Add support for vertex shader (using ARB_vertex_program extension)
by Christian Costa 15 Apr '04

15 Apr '04

Maxime Bellengé wrote: >Hi Christian > >Are you looking for someone to test the patch on an NVIDIA card ? >If you tell me how to test or the game to run, I can give you a >feedback. > >a+ > >Max > > > Hi Maxime, You can try the vertexblend, vertexshader & dolphinvs demos from the DX8 SDK. You can switch between HAL to REF devices to see the difference. Thanks for testing! :-) Bye, Christian

1 0

RE: More serial access issues
by Geoffrey Hausheer 15 Apr '04

15 Apr '04

Well, after tracing the events through wineserver, I see 'serial_queue_event' gets called, serial_get_poll_events returns 'POLLOUT', async_notify gets called (but async->thread->wait is 0, so it doesn't do anything besides setting the status to STATUS_ALERTED. The secod serial_get_poll_events returns 0 (due to the status no longer being STATUS_PENDING), but this doesn't really matter as the 'register_async' call doesn't create a reply. Back in my application, __register_async does not reset u.Status (since 'ret' is 0), which means that 'finish_async' never gets called, which appears to be the only way that FILE_AsyncWriteService can be called (which actually does the write) ,and no data is written to the serial port. It all seems to operate as the code dictates, so I'm not sure what the right fix is. It would seem to me that something is not working right in __register_async. Perhaps finish_async should not be gated by 'u.Status'? Or u.Status should unconditionally be set equal to 'ret'? The second seems more likely to me, as that is the only way the WriteFile could return TRUE (in fact I see no way that WriteFile could return true in today's code, regardless of what the server does (since u.Status can only be changed from STATUS_PENDING if ret != 0 (and STATUS_SUCCESS == 0), so u.Status can never equal STATUS_SUCCESS. I am having a lot of difficulty understanding exactly what the server call is doing (I think it is checking that it is clear to write to the Serial port, though it seems to be awfully complex if that is all). Also, I don't know what the conditions are under which finish_async should be called. I changed the code to unconditionally set u.Status = ret, and WriteFile is no longer returning an error, but this didn't help (I'm never seeing FILE_AsyncWriteService get called, because call completion is disabled). So it looks like there are several points that are preventing FILE_AsyncWriteService from being called, and maybe I'm barking up the wrong tree. I can see a few possibilities: (1) some other routine is supposed to do the write, and I'm missing it, or (2) the server is supposed to do the write (perhaps via asyncy_notify?), in which case I don't see any place where the write buffer is passed to the server, or (c) the server is supposed to tell the client to do the write (again by async_notify?), in which case, I'm not seeing how that works. This code seems to run around in circles to me. .Geoff -----Original Message----- From: Geoffrey Hausheer Sent: Wednesday, April 14, 2004 2:05 PM Subject: More serial access issues Well, I broke down and pulled out the oscope and rs232 breakout box to try to figure out why my app isn't able to communicate with the device. turns out that Rein's patch is correctly deasserting DSR, however, I am not getting any data over the Tx pin. And after I checked the output of WriteFile, it is failing. GetLastError doesn't return anything useful (a value of 997 which FormatMessage() can't do anything with). But some debugging led me to determine that NtWriteFile is returning 0x103 which is STATUS_PENDING. After that I'm somewhat lost as to what is going on. Obvioulsy, 'register_new_async' is returning this status, which apparently happens when wine_server_call returns 0 or STATUS_PENDING (not sure if the second is even possible). But about here I am getting completely confused as to what we are trying to accomplish. The file is opened via: CreateFile("COM1", 0, NULL, OPEN_EXISTING, 0, NULL) so we're not in overlapped mode. SetCommTimeout is called with the COMMTIMEOUTS structure containing all 0s. All flow control is disabled using SetCommState. Before a write, we always call 'PurgeComm' and ClearCommError. In Windows, this combination results in a write always occurring when WriteFile is called, regardless of whether there is anything connected to the serial port. Wine appears to be waiting for something, and I'm not sure what. If anyone has any ideas how I might proceed, i'd be glad to hear them. Thanks, .Geoff

1 0

Compiling MFC with latest CVS checkout.
by Manjunath Sripadarao 15 Apr '04

15 Apr '04

I am trying to compile MFC with latest CVS checout, I copied the source from the windows MFC dir and also the include dir (both for MFC and the VC98 include dir). I ran winemaker --interactive . and specified the -I paths. I got a couple of makefiles. Now if I do a make I get this error. [manju(a)manju MSVS]$ make make[1]: Entering directory `/home/manju/MSVS/mfc/src' wineg++ -mwindows -mno-cygwin -o mfcdb.so mfcdb.res mfcdb.dbg.o -lodbc32 -lole32 -loleaut32 -lwinspool -luuid mfcdb.exe-ueIUVp.spec.c:451: error: invalid conversion from `void (*)()' to ` void*' winegcc: gcc failed. make[1]: *** [mfcdb.so] Error 2 make[1]: Leaving directory `/home/manju/MSVS/mfc/src' make: *** [mfc/src] Error 2 Any ideas/tips. Am I even following the correct procedure ? There doesn't seem to be any document detailing this process. Any tips/instructions/suggestions would be greatly appreciated. I am doing this on a fedora core 1 (with prelink fixed and stuff, wine runs well), with a 2 Ghz P4 machine. If any other info is needed please feel free. Thanks in advance, Manju

3 3