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
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
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
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
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, ALT Linux Team
Russia, Saint-Petersburg, www.etersoft.ru
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,
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
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:
