Re: question about multiwindow mode and application icons

["Earle F. Philhower III" <earle at ziplabel dot com>]

Howdy Harold...


> In winmultiwindowwindow.c - WM_COMMAND, WM_SYSCOMMAND, and WM_INITMENU 
> -  These were all ending with a break.  I changed them to end with a 
> return 0, except when WM_SYSCOMMAND doesn't actually process anything. I 
> also changed WM_COMMAND to WM_INIT_SYS_MENU and I changed the menu 
> identifier to ID_APP_ALWAYS_ON_TOP, which is stored in resource.h.  It 
> was, in my opinion, a misuse of WM_COMMAND and WM_USER the way that it was 
> initializing.  Now it should be clear what is happening.

Good point, I don't know what I was thinking about WM_USER, you're 100% correct
that it shouldn't be done in a WM_COMMAND, it's a valid message on its 
own.  I've
been programming Windoze since Win 3.1, I should've known better!

At 02:57 AM 5/17/2003 -0400, you wrote:
> Actually, I found a problem with the interaction between MultiWindow mode 
> and Clipboard (-clipboard) that seems to have something to do with this patch.
> I have been doing the following:
> 1) Launch XWin.exe -multiwindow -clipboard
> 2) Launch a local copy of xfig.  Observe that the title bar is being changed.
> 3) Close local xfig.
> 4) ssh to remote Debian Linux host.
> 5) Open xfig and/or mozilla on Linux host.
> 6) Observe that setting the title bar sometimes works, sometimes it doesn't.
> 7) When setting the title bar does not work, it is basically because the 
> MultiWindow Window Manager thread has exited.
> Checking /tmp/XWin.log indicates that winClipboardErrorHandler got called 
> twice, which shouldn't happen because all paths through 
> winClipboardErrorHandler lead to pthread_exit (NULL).  Thus, either 
> pthread_exit (NULL) is not killing the calling thread (not your fault) as 
> per the specification of what it is supposed to do, or somehow the 
> MultiWindow window manager is calling winClipboardErrorHandler.  In any 
> case, the window manager is being killed.

That's quite odd!  The XMsg thread explicitly sets the error handler to the
WM error handler, and there's no legal way for it to get into that function
since it's not referenced anywhere in the code.  I can't reproduce what you're
seeing, at least not on a single machine.  If its repeatable on your end, can
you try commenting out the pthread_create for the XMsg proc and seeing if it
occurs again?  Running xfig locally eats up 100% CPU when doing anything for
me, maybe there's a race condition somewhere that only shows up when the
scheduler is overtaxed?  FWIW I had seen the clipboard thread die under
the version of the server the cygwin setup installs, after running some EDA
tools but it's not something I took note of or kept logs.  And that rev is
so far behind the one you're at that it probably doesn't mean anything.

Looking over the XMsg function code the only thing I can think of is that
it needs to wait on the pProcArg->ppmServerStarted mutex, which it's not doing
presently since the comments make me think that only thread needs to do this
to kickstart the main server, and it's already being done in the clipboard
and the WM thread.  Also, since the thread opens the server before it
sets the error handlers I imagine the server process is up and running
when the error handlers are installed.

I modded my local copy to have separate XErrorHandler()/IOErrorHandler()
functions for the XMsg thread, and in the log when I run xfig V3.2.4
locally I can see that the main WM thread is getting some
"ERROR: BadWindow (invalid Window parameter)" lines every time a menu is
popped up, but except for that nothing untoward happens, and I'm not
getting any errors from the XMsg thread.

I'll look at this some more next week and yell if I can find anything...


-Earle F. Philhower, III
 earle@ziplabel.com
 cdrlabel - ZipLabel - FlpLabel
 http://www.cdrlabel.com