On Mon, Dec 16, 2002 at 10:59:30AM -0500, Dan Espen wrote: > > This mail seems to have gone thru a time warp, you sent it Friday, > but I'm reading it on Monday. > > Dominik Vogt <fvwm-workers@fvwm.org> writes: > > On Fri, Dec 13, 2002 at 08:20:29AM -0500, Dan Espen wrote: > > > Dominik Vogt <fvwm-workers@fvwm.org> writes: > > > > On Thu, Dec 12, 2002 at 03:46:18PM -0500, Dan Espen wrote: > > > > > Dan Espen <[EMAIL PROTECTED]> writes: > > > OK, I think you are saying that there are other places a window > > > can get unmapped/destroyed/withdrawn by fvwm other than destroy_window. > > > I'll try to find all the other places and see if I can trace them. > > > > Perhaps you could just comment out all XUnampWindow() calls on the > > client window and all Reborder() calls for the moment. If this > > still happens we can safely assume that the application unmapped > > or destroyed the window itself. > > I think thats all resolved now,
Damn, I sent that mail on friday. > but I thought I'd mention, > I put a macro for XUnmapWindow in fvwm.h, remapped the function > call to print the __FILE__ and __LINE__ information, then > invoked MyXUnmapWindow where the real XUnmapWindow was called. > It seemed to work pretty well. > > > > > It may help to watch the events flying around prior to the window > > > > being unmapped. > > > > > > We don't seem to have any debug logic that produces a trace of events. > > > It seems like it would be pretty useful. > > > > I often put in a lot of debug statements, but in general I am only > > interested in a few events, but with very detailed output. One > > big debug switch wouldn't work too well - we'd need more control > > over the debug level and the verbosity of each event type. > > Well, I did it with one big switch statement. It worked pretty > well. I don't know if I should bother to commit it as ifdef'd debug > code or not, its not that hard to recreate. I agree, most often > its just one or 2 events that are of interest. I think I'll just > hold onto it. Bye Dominik ^_^ ^_^ -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
