Glenn Linderman wrote:
On approximately 5/30/2006 12:10 PM, came the following characters from
the keyboard of Robert May:
Jeremy White wrote:
Something like this:
- ability to close Console if there is one present and its not needed
- automatically re-create a console window if any reads/writes are
done on stdin/out/err
- ability to set the Console window title, Icon etc.
Eventually remove GetPerlWindow() from GUI.xs??
I suspect I'm missing the point:) But why do any of this? During
development most people would run with the console window showing -
makes debugging a GUI app so much simpler. Then when the script needs
to be deployed (either by wperl, or one of the exe creators) - the
console is automatically not created?
Yes, that can/has been done.
My personal twist on this is that I hide the console window, but have a
button to show it again, if the user wants to see the debugging message,
or if I am working with the user, and want them to read them to me.
That's nice. I'd like to hide the console, and have it automatically
re-appear when something bad happens (e.g. a warn/carp/croak ... in fact
probably when anything is written to STDERR). I've got a prototype
running using tie()d file handles; I also want to investigate using a
perlIO layer for this, as it feels that would be cleaner, but that can
only be used on perl 5.7 and above.
For my applications (packaged with PAR), it isn't likely that the user
will start them from a console window (CMD), but I do it, and get plenty
annoyed when the app crashes and my CMD goes away.
I think an option to add an END block that prints a message and waits
for a keystroke would be useful here - it won't keep the console around
if perl really crashes, but it should keep it around to allow reading of
most script-level warnings/errors.
I have no idea how to detect if the console for the APP is the same as
the one used to launch the APP, or even if it is possible to determine
that, but if it is possible to determine that, I'd like the option
(which I would use in several APPs) of then detaching from the original
console and creating a new one for the APP. Preferably, the new one
could be initially hidden.
I think it should be possible to tell which case we're in: if perl.exe
is run from an existing command window, then the perl.exe process is a
'child' of its command window process; if perl.exe is launched by
double-clicking the .pl file, then the command window process is a
'child' of perl.exe. It's just that there doesn't seem to be a simple,
cross-platform way of determining child-parent process relationships in
windows. With some XS code I think I can determine this relationship on
all the platforms that we need to support other than NT. (so it'll be OK
on W95/98/ME/2K/XP.
If you don't mind it looking a bit clunky, then you can already achieve
a process always having it's own console:
use Win32::GUI();
use Win32::Console();
# Detach from any existing console, fails silently
# if there is no existing console
Win32::Console::Free();
# Create and then hide a new console
Win32::Console::Alloc();
my $chwnd = Win32::GetPerlWindow();
Win32::GUI::Hide($chwnd);
You get a flash of console once when launching from the command line
(the Free() does nothing, the Alloc() creates a new visible console
which then gets hidden almost immediately.)
You get 2 console flashes for an app that is double-clicked to start
(the app creates it's own visible console, which then disappears when
Free() is called, the Alloc() creates a new, visible console that then
gets hidden.)
If only there was a way to ask AllocWindow() to create a hidden console,
but I read that it's impossible. (I do want to explore the possibility
of using a global hook to see if I can catch one of the messages that
happens early during window creation, and fiddle the WS_VISIBLE style,
but I'm not hopeful!)
Rob.
