Although you say that the module is listed in the Files tab on PerlApp, I'd recommend trying to manually add it to the "Added modules section" along with any modules that it uses. I've had to do this a few times when PerlApp didn't included required modules. If you're still having problems, you might also check out their user forums.

As for alternate methods for getting date/time data out of Excel, there's a few other methods.

• If you're accessing Excel via Win32::OLE, try retrieving 'Value2' instead of 'Value', which will return the formatted data.
• Also, you can convert manually the date/time from the numerical value stored. The whole number portion is something like the number of calendar days since a specific date and the decimal portion is the time of day.

UPDATE:

I found the information that I was looking for. The link is below. The first few paragraphs explains the whole number for dates and decimals for time thing. Further on down, they have examples about doing some date/time math in Excel, but that will give you an idea of what you can do with your Perl code to do your own conversion.

http://support.microsoft.com/kb/214094

One last note about the link above. Toward the end, it describes the difference in how Excel handles dates on Windows vs. on Macs. If you decide to write your own code for the date/time conversion and plan to make it cross-platform compatible, you might want to keep that in mind.

I suspect that what is going on is that the run time environment is able to resolve a method call but that the .exe isn't able to do because the code is simply not available.

My advice is to not "force" modules into the .exe by "unnatural acts of nature". Give PerlApp a clue by putting a "use X;" statement in the source code. PerlApp will stuff everything that is "used" into the .exe.

The first time I built an .exe with Tk, it was a nightmare! I just had "use Tk;" and that worked when all the libraries were available (Perl is very smart). But I would run some say Balloon method in the code and ooops...darn, the Balloon stuff wasn't there in the .exe! Then crash, die, burn...

PerlApp is smarter now, but it is not perfect. My advice is to put a "use" statement in the source code rather than using options to force inclusion of a module into the .exe.

So do it like this... not necessary for Tk now, but I hope you get the idea... Add "use" statements in the source code and that will trigger the dependency checker to include that module in the .exe.

use Tk;
use Tk::Balloon;
[download]

I've not used PerlApp, but I'd expect it to have a way of forcing the inclusion of a module as the other packing tools I have used do.

There are many ways that run time dependencies can't be detected by a static analysis of the code. For example the module you are having trouble with may be loaded using a require once the users locale has been determined.

ProclusYes! Your simple one line of code is what I was trying to get at for "Can't locate DateTime/Locale/en_US.pm", "use" it, "use DateTime::Locale::en_US;"

As the Op gains more experience in writing Perl code destined for PerlApp compilation, the simplicity and efficiency of adding "use" statements to the source code rather than PerlApp option statements at the compilation phase to force inclusion of a module that the dependency checker doesn't think should be there will become apparent.

I strongly recommend writing source code that is easy for the dependency checker to deal with. When there are 2 sets of double colons, this almost a sure bet that a "use" statement will be needed and I just add that into the source code as I write it. Also, there are other ways of making a .exe file from Perl code rather than PerlApp, and those "other ways" will understand what to do when they see a "use" statement. My goal is that the source code "speaks for itself" and that is possible with Perl.