Greetings

"The only difference seemed to be that -x caused the gui to appear during compilation."

-x actually runs the script to determine additional runtime dependancies. So if a GUI is in use then it'll be displayed.

"Is it possible you *thought* you've corrected the "tkkit.dll" typo, but still have it (maybe in your "build" script?)"

Possible, but it's hard to say given they copy and paste different things at different times and refuse to acknowledge the runtime warnings. You'll notice they provide different messed up pp calls at multiple times in the thread. Note that use of -gui isn't recomended if there are problems when running the executable created. It obscures the problem, as can be seen from several posts in this thread.

"But when I run it a few more times, it seems to start quicker after the initial run."

The first run will extract the whole zip file to a temporary area (for example C:\Documents and Settings\user\Local Settings\Temp\par-user), subsequent runs are quicker as they use this cache.

Note that ActiveState currently don't provide a 64bit package for MinGW, so you need to install it yourself.

Glad to hear it!

Marto is right about the -x switch; I hadn't yet read that far in the pp docs, but now I see why "pp" would want to run the program first, to further evaluate what other modules (eg. DLLs) are needed.

He's also correct about the cached files, it seems that using the -C (or --clean) switch to "pp" will:

Clean up temporary files extracted from the application at runtime. By
+ default, these files are cached in the temporary directory; this all
+ows the program to start up faster next time.
[download]

I'm excited that this new way (for me) of packaging Perl programs seems an elegant (and cheap) alternative to ASP's "perlapp". I tried using it with Tk and it worked very smoothly.

Here's my demo program; you can call it with --exe to build the executable:

##
#  PAR::Packer example using Tk
#
#  Notes:
#
#      1.  Run this script, and it creates a simple Tk App
#      2.  Install PAR::Packer in Windows using:
#
#           C:\>  ppm install MinGW
#           C:\>  cpanp i PAR::Packer
#
#          Don't worry if Win32::Exe tests fail:
#
#            dmake.exe:  Error code 129, while making 'test_dynamic'
#            dmake.exe:  Error code @55, while making 'sudirs-test'
#
#          Just select 'y' when prompted:  Proceed anyway? [y/N]: y
#
#      3.  To make the executable, type "<script> --exe"
#
#


###############
## Libraries ##
###############
use strict;
use warnings;
use File::Basename;
use Tk;


##################
## Main program ##
##################
my $src = basename $0;
(my $exe = $src) =~ s/[.]pl$/.exe/;

if (@ARGV > 0 and $ARGV[0] eq '--exe') {
    my $cmd = "pp --gui -o $exe $src";
    print "Command:  $cmd\n";
    system($cmd);
    exit;
}


# Tk Gui
my $mw  = new MainWindow(-title => 'PAR::Packer with Tk Example');
my $frm = $mw->Frame->pack(-expand => 1, -fill => 'both');
my $b1  = $frm->Button(-bg => '#ffefb3', -text => 'Hello World');
my $b2  = $frm->Button(-bg => '#ffefb3', -text => 'Quit (^Q)');
$b1->configure(-command => sub { print "Hello world!\n" });
$b2->configure(-command => sub { exit });
$b1->pack(-side => 'left');
$b2->pack(-side => 'right');
$mw->bind("<Control-q>" => sub { $b2->invoke });
$mw->MainLoop;
[download]

say  substr+lc crypt(qw $i3 SI$),4,5

You may also be interested in -T which allows you to specify a location for the cache. Out of interest have you tested using Strawberry Perl vs ActiveState?

Thanks again. Now I have to go and learn how to use Tk beyond a simple test case.
Do you have any suggestions on a good site.
I've googled but it's always nice to hear what people in the know think.

"I am going to check everything out."

I live in hope, but we've been round this loop several times before.

"I actually cut and pasted the exact command line I entered into my Console window (I'm not using a build script)."

It's inconsistent at various points throught your thread, either you didn't copy and paste it or you've made multiple mistakes when typing it several times. Consider testing paths actually exist, tab them out in the same way you do under linux/unix.

No inconsistencies whatsoever. golux asked if I was sure that the command I was posting was what was really being entered. His thinking was sound, I could have been running script b but pasting what was in script a. I correctly informed him that I was actually running the command in the console window and I was cutting and pasting the actual command I ran when I got the behavior I was seeing. Note: I never said I typed the command into the command prompt every time, you just inferred that to make your point. It's a long command so I typed it into my command prompt the first time and then cut and pasted that into notepad. I would then cut and paste the command from notepad into my console window. That is why I had the same typo several times. When the typo was pointed out I ran the fixed command in my console and then copied that command to notepad. It is also why I inadvertently called the command later with --gui after I had removed it once for testing. I copied and pasted the command in my console window and removed the --gui. I neglected to remove it from notepad.