Re: spy.c in debug output
Dimitrie O. Paun [EMAIL PROTECTED] 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.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: spy.c in debug output
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.
--
Dimi.
Re: spy.c in debug output
Dimitrie O. Paun [EMAIL PROTECTED] 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: spy.c in debug output
On Mon, Jan 03, 2005 at 07:19:49PM +0100, Alexandre Julliard wrote: Dimitrie O. Paun [EMAIL PROTECTED] 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. -- Dimi.
Re: spy.c in debug output
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+
Re: spy.c in debug output
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
Re: spy.c in debug output
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(). -- Dimi.
Re: spy.c in debug output
On Sun, Jan 02, 2005 at 04:47:41PM +, 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()
--
Dimi.
