From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chris Faylor <cgf@cygnus.com>
To: insight@sourceware.cygnus.com
Subject: Preserving errors to the console in Windows versions of insight
Date: Sun, 18 Jun 2000 21:15:00 -0000
Message-id: <20000619001543.A13914@cygnus.com>
X-SW-Source: 2000-q2/msg00284.html

I've been playing around a little with the Windows version of insight,
attempting to have it preserve errors that occur during the insight
initialization process.

Currently, if something is not set up correctly during gdb startup, it
is possible for gdb to just silently die, leaving the user at a loss for
what happened.

The reason for this behavior is that insight "disconnects" itself from
the console early in gdb initialization.  This means that any errors are
that are supposed to be printed to the console window are essentially
sent to /dev/null.  So, a potential fix is to move the disconnection
later in the initialization.

I've done that, and it works, but it has a couple of drawbacks.  1) the
console window stays on the screen slightly longer when insight is
started via an icon, 2) errors are nicely displayed in the console
window but if you didn't start insight from a console window, the error
disappears when the console window goes away due to insight exiting.

I was thinking that one way to solve this problem would be to reassign
stderr to a pipe and fork another process which waits for input from the
pipe.  If the parent process disappears, then the child displays
anything it has received in a dialog box and exits when the user clicks
on OK.

I hate to start another process just to deal with this but Windows is
amazingly insistent about not allowing reconnection to a console or even
to write to a console in any way from an unrelated process.

I don't know if there is some other way to trap stderr in such a way
that tcl/tk could popup an error window.  If there is, that would
probably be preferable.

Does anyone have any thoughts about this?

cgf