Can anyone tell me why we can't use functions from windows/spy.c for debugging purposes (in TRACE output) in any dlls/ modules?
Vitaly Lipatov a écrit :
Can anyone tell me why we can't use functions from windows/spy.c for debugging purposes (in TRACE output) in any dlls/ modules?
because they are not exported as regular APIs from user32, and we must stick to what the Win32 API provides for inter DLL calls A+
On Sun, 02 Jan 2005 17:22:43 +0100, Eric Pouech wrote:
because they are not exported as regular APIs from user32, and we must stick to what the Win32 API provides for inter DLL calls
Perhaps we could provide a Wine specific API and then an inline function that does a GetProcAddress on it, and if it's missing just passes the number straight through.
That way there are no hard dependencies between the DLLs but when run using Wine user32 the traces are more helpful.
Thoughts?
thanks -mike
On Sun, Jan 02, 2005 at 04:47:41PM +0000, Mike Hearn wrote:
Perhaps we could provide a Wine specific API and then an inline function that does a GetProcAddress on it, and if it's missing just passes the number straight through.
Right. A default implementation could be just:
wine_dbg_sprintf("%x", msg);
Anyway, it would be way cool if we could use the nice dumping functions from spy.
We should be exporting a wine_dbg_msg_{enter,exit}() that we could use them nicely in our window procs.
In fact, I don't think it's feasible to return a string (the max buffer is probably not big enough), we should just dump the output automagically to the correct channel, so maybe a better name would be: wine_dbg_msg_{enter,exit}_dump()
Hmm, it needs a bit more thought, we also need a calling macro to hide the channel business: TRACE_MSG_ENTER()/TRACE_MSG_EXIT()
"Dimitrie O. Paun" dpaun@rogers.com writes:
Right. A default implementation could be just:
wine_dbg_sprintf("%x", msg);
Anyway, it would be way cool if we could use the nice dumping functions from spy.
We should be exporting a wine_dbg_msg_{enter,exit}() that we could use them nicely in our window procs.
You can also simply turn on the +message channel and you get nice traces for all the window procs. I don't think there's much point in duplicating that functionality inside the window procs themselves.
On Mon, Jan 03, 2005 at 03:19:50PM +0100, Alexandre Julliard wrote:
You can also simply turn on the +message channel and you get nice traces for all the window procs. I don't think there's much point in duplicating that functionality inside the window procs themselves.
Unfortunately, it's not that simple. If it were, there wouldn't be a point in having any tracing functions in our window procs. Thing is, then I'm debugging say listview, I don't want to turn +message on, it dumps way too much information. For this reason, I have trace inside the LISTVIEW_WindowProc() (and this is true for _all_ window procs, BTW). It would be a lot more useful if that trace would be printed in a decoded manner, as it will eliminate a lot of duplicated effort of decoding that info in the internal functions.
What I mean is that the typical pattern is:
XYZ_WindowProc(...) { TRACE("(%x, %ld, %ld\n", msg, wParam, lParam);
switch(msg): case MSG_ABC: return XYZ_ABC(msg, wParam, lParam); .... }
INT XYZ_ABC(msg, wParam, lParam) { TRACE("print decoded w/lParam, often incomplete 'casuse it's too hard\n", wParam, lParam); ... }
All this would be unnecessary, if the trace in the XYZ_WindowProc() did the right thing.
"Dimitrie O. Paun" dpaun@rogers.com writes:
Unfortunately, it's not that simple. If it were, there wouldn't be a point in having any tracing functions in our window procs. Thing is, then I'm debugging say listview, I don't want to turn +message on, it dumps way too much information.
You can of course configure the message filters to only dump listview messages in that case. Another possibility would be to make spy.c print only the listview messages if +listview is on but +message is off.
On Mon, Jan 03, 2005 at 07:19:49PM +0100, Alexandre Julliard wrote:
"Dimitrie O. Paun" dpaun@rogers.com writes: You can of course configure the message filters to only dump listview messages in that case. Another possibility would be to make spy.c print only the listview messages if +listview is on but +message is off.
Certainly, all that is possbile. On the other hand, experience shows that nobody does it if it's not immediately simple. And yes, people are lazy, and prefer to work with stuff they understand rather then hack on things they don't even know exist, as evidenced by all the trace statements present in the code.
To my mind, it's a bit academic that it's possbile, if it's not used my 99% of the people. It's too bad that we have such a woderful facility in spy that could be so much more useful, and we don't make use of it. Such a pitty.
On Sun, Jan 02, 2005 at 05:22:43PM +0100, Eric Pouech wrote:
because they are not exported as regular APIs from user32, and we must stick to what the Win32 API provides for inter DLL calls
True, but they are useful. Maybe we can move them to libwine, or do a trick of sorts with GetProcAddress().
-
Alexandre Julliard -
Dimitrie O. Paun -
Eric Pouech -
Mike Hearn -
Vitaly Lipatov