On Mo, 2006-11-20 at 16:48 +0100, Pierre d'Herbemont wrote:
+/* ---------------------------------------------------------------------
send_mouse_input
- */
+static void send_mouse_input( HWND hwnd, DWORD flags, DWORD x, DWORD y,
DWORD data, DWORD time, DWORD extra_info, UINT injected_flags )
+{
- POINT pt;
- pt.x = x;
- pt.y = y;
Hi. Some more questions.
POINT pt is never used for more than accessing pt.x and pt.y in this function, which is really useless, as both values are fn-parameters.
Is there code waiting, that use pt? A comment would be nice for this case.
Did you already try to replace "DWORD x, DWORD y" with "POINT pt" for the driver-internal Functions?
+BOOL QDRV_CreateWindow( HWND hwnd, CREATESTRUCTA *cs, BOOL unicode )
- if (cs->cx > 65535)
- {
ERR( "invalid window width %d\n", cs->cx );
cs->cx = 50;
- }
Setting the minimal or maximal size to 50 looks strange for me. Is this an leftover from debugging?
\ No newline at end of file
This is easy to fix.
On 20 nov. 06, at 20:34, Detlef Riekenberg wrote:
On Mo, 2006-11-20 at 16:48 +0100, Pierre d'Herbemont wrote:
+/*
send_mouse_input
- */
+static void send_mouse_input( HWND hwnd, DWORD flags, DWORD x, DWORD y,
DWORD data, DWORD time, DWORD
extra_info, UINT injected_flags ) +{
- POINT pt;
- pt.x = x;
- pt.y = y;
POINT pt is never used for more than accessing pt.x and pt.y in this function, which is really useless, as both values are fn-parameters.
Is there code waiting, that use pt?
You're right, I shouldn't use it. There are the remaining of the x11 driver rip off.
+BOOL QDRV_CreateWindow( HWND hwnd, CREATESTRUCTA *cs, BOOL unicode )
- if (cs->cx > 65535)
- {
ERR( "invalid window width %d\n", cs->cx );
cs->cx = 50;
- }
Setting the minimal or maximal size to 50 looks strange for me. Is this an leftover from debugging?
Indeed it is for debugging, because the metrics goes wrong as they are unimplemented, so to see the window it's better.
\ No newline at end of file
This is easy to fix.
Why should a new line be at the end of the file? Is that a coding style issue?
Thanks,
Pierre.
On 11/20/06, Pierre d'Herbemont pdherbemont@free.fr wrote:
Why should a new line be at the end of the file? Is that a coding style issue?
Some versions of gcc warn in this case. No clue as to why but I expect if git is doing it, then perhaps its due to some sort of issue with the diff and patch programs.
On 11/20/06, Steven Edwards winehacker@gmail.com wrote:
On 11/20/06, Pierre d'Herbemont pdherbemont@free.fr wrote:
Why should a new line be at the end of the file? Is that a coding style issue?
Some versions of gcc warn in this case. No clue as to why but I expect if git is doing it, then perhaps its due to some sort of issue with the diff and patch programs.
it seems to be "official" :-) This is in section 2.1.1.2 of the ANSI C 1989 standard. Section 5.1.1.2 of the ISO C 1999 standard (and probably also the ISO C 1990 standard).
On 11/20/06, Jaap Stolk jwstolk@gmail.com wrote:
it seems to be "official" :-) This is in section 2.1.1.2 of the ANSI C 1989 standard. Section 5.1.1.2 of the ISO C 1999 standard (and probably also the ISO C 1990 standard).
Thanks I found it.
Each instance of a backslash character () immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice. A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character before any such splicing takes place.
I've heard two good reasons why end of file new-line characters are a good idea. First, if you were to concatenate two files together (such as how i think the prepreocessor handles a #include), without that newline the last line of the first file and the first line of the second file would be appended together as one long line, instead of being one after another. Secondly, the lack of a newline could indicate a corrupt file / broken pipe.
On 11/21/06, Steven Edwards winehacker@gmail.com wrote:
On 11/20/06, Jaap Stolk jwstolk@gmail.com wrote:
it seems to be "official" :-) This is in section 2.1.1.2 of the ANSI C 1989 standard. Section 5.1.1.2 of the ISO C 1999 standard (and probably also the ISO C 1990 standard).
Thanks I found it.
Each instance of a backslash character () immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice. A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character before any such splicing takes place.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
"Detlef Riekenberg" wine.dev@web.de wrote:
+BOOL QDRV_CreateWindow( HWND hwnd, CREATESTRUCTA *cs, BOOL unicode )
- if (cs->cx > 65535)
- {
ERR( "invalid window width %d\n", cs->cx );
cs->cx = 50;
- }
Setting the minimal or maximal size to 50 looks strange for me. Is this an leftover from debugging?
Actually after you have raised that I think that this check should be either removed altogether (including winex11.drv), or modified to do what SetWindowPos already does - truncate window coordinates/sizes to short int. Probably this check/fix should be moved into user32 instead of populating it among the drivers.