the_slycer has asked for the wisdom of the Perl Monks concerning the following question:

Hi all, I've written a program in Tk that is in use by my place of work. It works great, was everything we needed. However, the one minor point that people complain about is that the DOS (terminal) window must be up while the prog runs.

I'd like to clear this up if I could. Playing with win32::gui I noticed it is possible to do this using a command like the following: 
my ($DOS) = Win32::GUI::GetPerlWindow();
Win32::GUI::Hide($DOS);

[download]
The problem here is that win32::gui is not cross-platform whereas Tk is, is there such a method with Tk? Or do you know of other methods. I tried using this utility, but can't seem to make it work in Win 2k. I also don't feel like forking out the $$$ for perl2exe pro which apparently can do this.

Replies are listed 'Best First'.
(Guildenstern) Re: Hiding the DOS window on Win32
by Guildenstern (Deacon) on Nov 17, 2000 at 02:59 UTC
    This one's also listed in the Perl Cookbook in section 15.17. Basically, you write a standard Perl script that uses Win32::Process to start your Perl.Tk program in a separate process. The original script then exits, and you're left with just your Perl/Tk app and no annoying DOS window.

    Update: After posing the fair use question, and poking around on the Web, I've decided to go ahead and post the code for this. You can download it from O'Reilly, so in my mind that makes it fair game. Here it is: 
    #!/usr/bin/perl -w
# loader - starts Perl scripts without the annoying DOS window
use strict;
use Win32;
use Win32::Process;

# Create the process object.

Win32::Process::Create($Win32::Process::Create::ProcessObj,
    'C:/perl5/bin/perl.exe',            # Whereabouts of Perl
    'perl realprogram',                 #
    0,                                  # Don't inherit.
    DETACHED_PROCESS,                   #
    ".") or                             # current dir.
die print_error();

sub print_error() {
    return Win32::FormatMessage( Win32::GetLastError() );
}

    [download]

    Once again, this is from section 15.17 of the Perl Cookbook.

    Guildenstern
    Negaterd character class uber alles!
[reply]
[d/l]
Re: Hiding the DOS window on Win32
by Adam (Vicar) on Nov 17, 2000 at 05:44 UTC
    Here is a thought: If the problem is only on MSWin32 machines, then wrap that bit of Win32 specific code into a block that only gets run on Win32: 
    if( 'MSWin32' eq $^O )
{
    require Win32::GUI;
    # Win32::GUI->import(); # Pretend to be 'use' ???
    my ($DOS) = Win32::GUI::GetPerlWindow();
    Win32::GUI::Hide($DOS);
}

    [download]
    Or something like that.
[reply]
[d/l]
Re: Hiding the DOS window on Win32
by gharris (Beadle) on Nov 17, 2000 at 02:52 UTC
    I seem to recall this being in the Perk/Tk FAQ, and they have a snippet of code you can place at the top of your script to fix the problem.
    But another option, and the one I prefer, is to make use of the wPerl executable provided by ActivePerl, which will not show a command prompt.
    Then I just make all my GUI perl scripts end in 'gpl', and associated 'gpl' with wperl.
    Now your scripts will work the same everywhere, and you can still run them with perl to see any console output (which will be discarded when you use wperl).

    Hope that helps!

    --Glenn
[reply]
Re: Hiding the DOS window on Win32
by Dr. Mu (Hermit) on Nov 17, 2000 at 03:51 UTC
    The easiest and slickest way to do this is to use perl2exe with the -gui option. To get this feature you have to pay for the Pro Edition, but it's not expensive. Plus you get the additional benefit of cramming your whole app into one exe that can run on another computer with no external dlls, no libraries -- no nuthin' else. It's all embedded in the exe. And that means no install program. Just unzip and go. (A fairly large app, when zipped, will fit on a 1.44MB floppy.)

    Sorry if this sounds like an ad, but I use the program and like it a lot.
[reply]
      I have used this (only the text version registered), but the problem is the size. Consider, an app written with perl/tk, using the tk::text extension, 1.8 meg. That's a big binary to be running! (at least IMHO) And again the cross platform stuff comes up, I'd rather just pop the script out and let it be, it looks like the way I'm going to go is run the code to hide the window if the OS is windows. Why it took someone else to point that out I'll never know :-) (BTW - thanks Adam)
[reply]
        I take your point. But perl2exe does offer a -tiny option in the pro edition that allows you to strip out some of the dlls and distribute them separately, which is an advantage if there is more than a single program involved. The questions one needs to ask when considering perl2exe are:

        1. Will the program be run on just the development machine or be distributed to other machines as well? If the latter, how much trouble is it going to be to do a full Perl install on the other machines?

        2. How "upgrade resistant" is the program? This is to say, if you upgrade your Perl installation, will the program have to be tweaked to accomodate it? (This may be a big issue when Perl 6 comes along, and is always a concern when you are using third-party modules.) If so, perl2exe allows you to freeze a working version, giving you time to do the tweaking (or not) as you see fit.

        Well, I guess my comments have taken us a bit afield of the original question! And once again, I probably sound like a shill for perl2exe. I'm not, but it does solve some problems for me that I don't mind sharing. :-)
[reply]

Back to Seekers of Perl Wisdom