Re: [PATCH] deferred trace

[Alexandre Julliard]

gerard patel  writes:
> - I don't see how I will get the window list I generate with
>
> WIN_WalkWindows if there is no change at all in Wine - I should
> have said that to cut in the trace size in not a goal per se, but a
> mean to make debugging easier. 
> If I have to make a first run with full trace that I have to browse to see
> what is the meaning of the window handles appearing in the trace, I lose 
> a lot of time. Having immediately a view of all existing windows is *very*
> handy.

I don't doubt it's very useful for the specific problem you are
tracking; but it's hardly generic enough to be included in the main
tree.

[PATCH] deferred trace

[Gavriel State]

Alexandre Julliard wrote:
> gerard patel  writes:
> > - I don't see how I will get the window list I generate with
> >
> > WIN_WalkWindows if there is no change at all in Wine - I should
> > have said that to cut in the trace size in not a goal per se, but a
> > mean to make debugging easier.
> > If I have to make a first run with full trace that I have to browse to see
> > what is the meaning of the window handles appearing in the trace, I lose
> > a lot of time. Having immediately a view of all existing windows is *very*
> > handy.
>
> I don't doubt it's very useful for the specific problem you are
> tracking; but it's hardly generic enough to be included in the main
> tree.

I disagree - many of the bugs I encounter can happen well into the run
of a program.  For example, debugging a dialog box in an app that comes
up only after a specific set of occurances.  Having the ability to turn
on -debugmsg +all at will would make this kind of debugging much easier.
Trying to do this with an external program controlling the debug trace
is an excersize in futility due to the speed hit you get from -debugmsg 
+all.

I remember wishing fondly for something like this when we were working 
on WordPerfect, but never having the time to do it myself.

-Gav