Hi Maek,
Sorry for the longish post ...
>Therefore I added
>#ifdef _MSC_VER
> cerr << "Hit a key to continue..." << endl;
> cin.get();
>#endif
>to function
>void fgExitCleanup()
Thank you for bringing this up! ... it has been a problem
for a long, LONG TIME ... IIRC there was a time, in the
far distant past, when re-direction did function ... but
no more ... some change, maybe in PLIB, SG or FG stopped
it completely ...
I really WISH there was a way to re-direct this output
to a disk FILE, so the whole output could be reviewed,
but I have tried, and tried, with simgear logging, but
have never quite succeeded ... I know, it should be
'simple' ;=))
IFF the log output could be directed to a FILE, then
the need for a 'wait key' action at the end would not
really be necessary ... perhaps it could be another
command line action, like --log-to=filename.txt ...
I can see your idea to 'know' whether it is an 'error'
or 'normal' exit, but if it was always written to a FILE,
that file restarted when you next run FG, then you could
check that file in ANY/ALL CASES ... there are ALWAYS
some interesting entries, that SHOULD be explored ...
It is difficult, read IMPOSSIBLE, to enlarge the
windows console buffer big enough so you can 'see' ALL
output ... especially since each iteration outputs a
whole bunch of diagnostic stuff ... many times a
second ... so, even with a 'wait-for-key-exit' you
only 'see' the end ... so this is not really a
complete 'solution' anyway ...
Does anyone have a coded way to 'alter' simgear logging,
such that a FILE could be used in place of cerr ... and
cout for that matter ... IN WINDOWS ... maybe if someone
could code it in *nix, then that code could be 'modified'
for WINDOWS ...
I further 'understand' this re-direction is perhaps
NOT a problem in *nix systems, thus it gets no real
attention ... maybe it is also ok in a cygwin
build and run - have never tried ... thus can NOT
really expect any *nix solution ...
Fred, even when, as you suggest, fgrun is used
as the launcher - since it really aids in setting the
many command line items of FlightGear - a SEPARATE
console window is opened, and closed when FG exits ...
Thus it is NOT output to the fgrun 'console' window,
whether fgrun was started from a console, or as a
shortcut, which create a new console window ... this
is, of course, using a MSVC built fgrun, running in
'pure' windows ...
Are you pointing out that run_win32.cxx has been
'recently' altered to do this? It is certainly
a few weeks or so since I last built fgrun (07SEP06) ...
maybe I just need to do another build ...
But a compare of the run_win32.cxx I used, shows it is the
SAME as the current - perhaps yesterday - svn update
of the fgrun source ... what can you be doing different
to me? My fltk-1.1 was svn updated the same day ... and
PLIB, pthreads, etc, all of that date or more recent ...
And as Reagan points out, although it IS possible to
write a launcher that does re-direction before running
an application, as the MS sample suggests, using threads
and pipes, again this is NOT the NEW console window that FG
NOW creates, but only the console window of the launcher ...
Again, this did work in the now distant past, and I have
such a 'launcher', from approximately the same MS sample
code, which I still sometimes use for other apps, which
I called 'exec32.exe', but it also FAILS with FG ;=(( like
Maik suggested - a broken pipe, or something !!!
Yes, there are some neat functions in FG main(...) like
those used for the macintosh (only) code -
freopen ("stdout.txt", "w", stdout );
freopen ("stderr.txt", "w", stderr );
Maybe if this is also done in windows, BUT it will have
to be AFTER -
// set default log levels
sglog().setLogLevels( SG_ALL, SG_ALERT );
since I am very sure sglog() also does something
like this in logstream.hxx ...
inline logbuf::int_type
logbuf::overflow( int c )
{
#ifdef _MSC_VER
static bool has_console = false;
if ( logging_enabled ) {
if ( !has_console ) {
AllocConsole();
freopen("conin$", "r", stdin);
freopen("conout$", "w", stdout);
freopen("conout$", "w", stderr);
has_console = true;
}
return sbuf->sputc(c);
}
else
return EOF == 0 ? 1: 0;
#else
return logging_enabled ? sbuf->sputc(c) : (EOF == 0 ? 1: 0);
#endif
}
In fact I am pretty sure the 'AllocConsole()' call is the
'newish' things that 'breaks' the old re-direction, but have
not had the time to try different things ... or research
back into history ...
As the MSDN help states -
Console applications are initialized with a console, unless
they are created as detached processes (by calling the
CreateProcess function with the DETACHED_PROCESS flag).
It is noted fgrun does NOT add DETACHED_PROCESS ;=() nor
does it add CREATE_NEW_CONSOLE ... it uses 0 for the
'creation flag' ...
So, since a CONSOLE application is started with a
console, initialised by the EXE loader, which may have
already had the redirection set from the command line,
there really seems no NEED for this call at all ...
And 'forcing' the 'inherited' standard handles back to
"conout$" is also maybe the thing that 'breaks'
re-direction ...
Maybe has_console could be made a PUBLIC member of
logbuf, so it could be set to TRUE, when SG is
used from a CONSOLE application ... maybe this code IS
needed when SG is used within a GUI application ???
Perhaps the author of this code could give us some
of the reasoning of why this was added, under a
_MSC_VER flag ...
Maybe there is a way to 'explore' this in cvs,
but I will need some help with the cvs commands to get
at this 'historic' information ... like when was it added,
by whom, and WHY ...
This 'problem' needs a pure windows solution ;=)) Where
are the MSVC WIN32 developers when you really need them?
Regards,
Geoff.
EOF - fgd-004.doc
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
