Re: [perl-win32-gui-hackers] Win32::GUI::Console

[Robert M. <rm...@po...>]

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.