PerlApp can't find bound module

[petecm99]

UPDATE: Thanks for all your helpful suggestions! Specifically including the module it was looking for (DateTime::Locale::en_US) worked perfectly...

Benevolent monks,

I use Active State's PerlApp program to create Windows executable GUI programs, with excellent results. Until now, that is.

I just added DateTime::Format::Excel to my GUI in order to parse an Excel date-formatted field (since Excel has the annoying behavior of storing dates as decimal numbers).

When I "compiled" my program in PerlApp, it created an executable successfully, but when I run it, it can't find one of the modules required by DateTime::Format::Excel (Can't locate DateTime/Locale/en_US.pm in @INC).

I see DateTime::Format::Excel listed in the Files tab of the PerlApp project, so my Module Search paths appear correct. Also, I can easily find this module in my C:\Perl\site\lib\DateTime\Locale folder, so I even tried manually binding it, to no avail.

I seek enlightenment in one of the following solutions -
1. Has someone encountered a similar issue with PerlApp and can provide a method to force it to find the obscure module?
2. Is there another somewhat simplistic method to convert Excel datetime numbers into actual dates, other than using the DateTime::Format::Excel->parse_datetime method?

Piously yours,
Sexton Pete

[dasgar]

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.
I can't find the related information right now about the Excel formats, but if you search Excel's help, you should be able to find the information. If I find the information later, I'll post an update.

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.

[Marshall]

This is one of those things that can happen. PerlApp is much smarter than it used to be and it has some heuristics for dealing with major libraries like Tk, LWP, etc.

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;

[GrandFather]

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.

[Proclus]

I also use Marshall's suggestion when PerlApp does not find and bind the modules. That does the trick. Just put this at the beginning of your program:
use DateTime::Locale::en_US

[Marshall]

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.