Re: Howdy! Newbie with keyboard patches.
On Tue, Jan 23, 2007 at 08:58:24AM +0100, Tomas Carnecky wrote: I'm sure I could hack you a small app that takes input events from /dev/input/eventX and uses XTest to fake X key events. That way you could 'map' F13 to Control-F1. I've written a few 'drivers' for input devices (MS Strategic Commander etc) that way.. and it works great. this app allready exists: http://hansmi.ch/software/inputd -- cu pgpISBGQK94BC.pgp Description: PGP signature
Re: Howdy! Newbie with keyboard patches.
On Mon, Jan 22, 2007 at 02:07:34PM -0600, Peter Seebach wrote: I have implemented and tested a patch which is almost certainly unsuitable for production, but which is very convenient to me; it is this patch I enclose. This patch replaces F13-F24 with control-alt-F1 through control-alt-F12, and F25-F32 control-alt-shift-F1 through F8. CTRL+ALT+Fn is used to switch to the text-consoles and back to X11 (at least on linux and openbsd). hardwire this in wine might not be a good idea. -- cu pgpLXk7BKWoBY.pgp Description: PGP signature
Re: user32: WM_SETFONT on button shouldn't repaint directly
Clinton Stimpson [EMAIL PROTECTED] writes: Anything wrong with this patch? It hasn't been accepted. I suspect you need an UpdateWindow() too. To confirm this (or not) you should avoid the PeekMessage loop in your test. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Alexandre Julliard : oleaut32/tests: Add tmarshal test.
Alexandre Julliard [EMAIL PROTECTED] writes: Module: wine Branch: master Commit: aa9dcb42019e0ebc0913d1a56b150684212099ea URL: http://source.winehq.org/git/wine.git/?a=commit;h=aa9dcb42019e0ebc0913d1a56b150684212099ea Author: Alexandre Julliard [EMAIL PROTECTED] Date: Mon Jan 22 23:18:45 2007 +0100 oleaut32/tests: Add tmarshal test. Sorry, that one should of course have been credited to Rob Shearman, not sure why my name got in there instead... -- Alexandre Julliard [EMAIL PROTECTED]
Re: [try3]: user32/tests: add tests for WM_SETICON - what's wrong?
Anything wrong with them again? http://www.winehq.org/pipermail/wine-patches/2007-January/035044.html http://www.winehq.org/pipermail/wine-patches/2007-January/035043.html Thanks, Kirill
Directplay Sevice Provider
Hi everyone, i'm taking a look at wine's directplay implementation. From the the wiki i've seen that there are efforts to understand the directplay protocol. But it seems to be be quite a difficult task. Would not be a better idea to implement a wine directplay service provider with our own protocol, not compatible with microsoft tcp/ip service provider, but portable and usable on both windows and linux? Bye Pignotti Alessandro -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe
Re: Directplay Sevice Provider
On 1/23/07, Alessandro Pignotti [EMAIL PROTECTED] wrote: Hi everyone, i'm taking a look at wine's directplay implementation. From the the wiki i've seen that there are efforts to understand the directplay protocol. But it seems to be be quite a difficult task. Would not be a better idea to implement a wine directplay service provider with our own protocol, not compatible with microsoft tcp/ip service provider, but portable and usable on both windows and linux? But if we did that, we couldn't play between Windows and Linux machines. Bye Pignotti Alessandro -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Damjan
Re: Howdy! Newbie with keyboard patches.
In message [EMAIL PROTECTED], Christoph Frick writes: On Mon, Jan 22, 2007 at 02:07:34PM -0600, Peter Seebach wrote: I have implemented and tested a patch which is almost certainly unsuitable for production, but which is very convenient to me; it is this patch I enclose. This patch replaces F13-F24 with control-alt-F1 through control-alt-F12, and F25-F32 control-alt-shift-F1 through F8. CTRL+ALT+Fn is used to switch to the text-consoles and back to X11 (at least on linux and openbsd). hardwire this in wine might not be a good idea. That's the thing that's neat about having Wine translate keycodes X has but Windows doesn't into keycodes you can't send in X (because something else would grab them) that Windows can use. :) -s
Re: user32: WM_SETFONT on button shouldn't repaint directly
Clinton Stimpson [EMAIL PROTECTED] wrote: -if (lParam) paint_button( hWnd, btn_type, ODA_DRAWENTIRE ); +if (LOWORD(lParam)) InvalidateRect(hWnd, NULL, TRUE); Your test doesn't show that the usage of LOWORD(lParam) is justified. -- Dmitry.
Re: Directplay Sevice Provider
Am Dienstag 23 Januar 2007 14:08 schrieb Alessandro Pignotti: Hi everyone, i'm taking a look at wine's directplay implementation. From the the wiki i've seen that there are efforts to understand the directplay protocol. But it seems to be be quite a difficult task. Would not be a better idea to implement a wine directplay service provider with our own protocol, not compatible with microsoft tcp/ip service provider, but portable and usable on both windows and linux? I think you should get in Contact with Kai Blin too. He is the main worker on DirectPlay at the moment. I think he decided to reverse engineer the Microsoft Protocol for a few reasons. One of them is that we do not have to equip windows machines with our own service providers. Understanding the protocol gives some insight into the way dplay works, and I guess Kai has some fun reverse engineering the protocol :-) pgpj6bDMKUsG4.pgp Description: PGP signature
Questions about OleLoadPictureEx and SetDIBColorTable
Hi,
I'm still working on the freeware Navigation
(http://francois.fouchet.free.fr/) which will soon be added to AppDB.
I produced a working version of WidenPath (a priliminary patch will come
soon).
Another problem appeared in an other place (which was masked because of
WidenPath at the beginning).
Navigation triggers a problem in SetDIBColorTable. I investigate a
little, but I don't know enough to conclude. I need your help.
In SetDIBColorTable, this particular test failed :
/* Check if currently selected bitmap is a DIB */
if (bitmap-color_table)
Here is the source code (in vb) in Navigation :
Set hDessin = LoadGif(LocFile) '#* (uses LoadPicture in a StdPicture)
ShowErr SelectObject(Plans(plDessin).hdc, hDessin), SelectObject
Dessin:#Here#
ShowErr SetDIBColorTable2(Plans(plDessin).hdc, 0, 256,
PaletteAltitude(0)), SetDIBColorTable:#Here#
Just before the failure, Navigation uses OleLoadPictureEx, which is
partially implemented :
fixme:ole:OleLoadPictureEx
(0xee06ec,343250,1,{00020400---c000-0046},x=0,y=0,f=0,0x33dd48),
partially implemented.
I don't really know what happen, since I don't understand everything in
those differents functions. Can anyone please help me to investigate
more precisely to discover want happen, and try to correct something if
necessary ?
Thank you all,
Laurent
Re: gecko download busted?
On Thu, 2007-11-01 at 17:19 +0100, Wojciech Arabczyk wrote: Hello trace:wininet:HTTP_GetResponseHeaders raw headers: LHTTP/1.1 302 Found\r\nDate: Thu, 11 Jan 2007 15:47:17 GMT\r\nServer: Apache/2.0.54 (Debian GNU/Linux)\r\nLocation: http://optusnet.dl.sourceforge.net/sourceforge/wine/wine_gecko.cab\r\nConne ction: close\r\nContent-Type: text/html\r\n\r\n but no connection request to that new URL, and the cabextract failed. I guess I'll try with a newer wine once I get to the office... Sourceforge changed the mirror schema. The wine-gecko element is downloading correctly again since 0.9.29. unless you use a native urlmon.dll
Re: doc: Add info about where to get the Windows DDK
On Mi, 2007-01-24 at 13:31 +1100, Jeff Latimer wrote: Thanks for your update. Just a small typo (Device = Driver): DDK is the Windows Driver Development Kit -- By by ... Detlef
