[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Odd StandardFile behavior



>>The following snippet works great- except when you select a drive as your
>>root directory. The leading : returned by the GetFolder call seems to mess
>>up the -e test. Is this a -e problem or a StandardFile problem? (I'm using
>>the 510b1r2 version).
>>
>>Also, would anyone like to help rewrite StandardFile.pl so it runs cleanly
>>under -w?
>
>I had a problem with the attached script when I wrote it sometime ago, in
>that it worked fine for folders on the HD but not for external drive
>directories.The program misbehaved if a floppy disc icon was dropped onto
>the script droplet. It is all to do with colons in the chdir() I recollect.
>In the form attached here it works properly I think.
>
>I guess you are getting "use of uninitialised variable" complaints from
>Perl with the -w switch on? In this script, which is recursive Perl keeps
>finding "$dir" uninitialised at each new level of recursion. The fllowing
>line:
>
>            $dir = "" unless $dir;
>
>seems to be the only way of dealing with that problem. You will find the
>script runs perfectly well without the line, but if the -w switch is on,
>Perl will complain about line 24. (In fact Perl even complains about its
>own @ARGV without the line <$ARGV[0] = "" unless $ARGV[0]>.)
>
>This isn't, I'm afraid, a proper answer to your question, but I hope it
>might be of some help nevertheless. I am not familiar with StandardFile.pl.
>
>Regards,
>
>
>Alan Fry
>

Actually, the StandardFile.pl problem I was talking about is like this-
----------------------------------------------------
#!/usr/bin/perl -w

require "StandardFile.pl";

$file = &StandardFile::GetFile ("Pick a file:", "TEXT");
print "You asked for $file.\n";
----------------------------------------------------
Runs fine, but under -w generates errors. As I use these routines to
provide a gui(and since they're part of the standard mac distribution).

After much experimenting, it seems that the problem is the failure to pass
a "default" value to the script- without one, it generates the error.

This code doesn't produce the error:
require "StandardFile.pl";
$file = &StandardFile::GetFile ("Pick a file:", "TEXT", "Null String");
print "You asked for $file.\n";
__END__

This is odd, because the routine doesn't need the null string to work- in
the subroutine description, it's listed as an optional parameter. I don't
think that the default setting has much relevance in this case, anyway- I
don't think the standard file dialog box can handle going to a specific
file in this context.

The following rewrite to the StandardFile::GetFile chunk seems to work-
-------------------------------------
# Name
#   GetFile
# Syntax
#   $filename = &GetFile([$prompt, ] @types);
# Description
#   Query a existing file name to user by Standard File Dialog Box.
#   $prompt is a user prompt, which is ignored under 4.1.1, but will
#   probably be shown in a future version. $prompt should never be a
#   string of length 4.
#   @types is a list of the file type which is used for
#   filtering the file list in the dialog box.
#
sub GetFile {
    local($prompt,@types) = @_;
         local($default) = pop(@types);

         if (length($prompt) == 4) {
                  unshift(@types, $prompt);
        $prompt = "";
    }


    &MacPerl::Choose(
       &GUSI::AF_FILE,           # domain
        0,                                      # type
        $prompt,                # prompt
        &GUSI::pack_sa_constr_file(@types),
                                          # constraint

        "0",                            # flag

       ""               # default filename, null in this context.
        );
}

-------------------------------------




Any comments?

Tim Howland




----------------=============================----------------
Tim Howland                               VSI
New Media Director           44 N Main, Norwalk, CT 06854
(203) 852-1010, ex. 248             F:(203) 831-5116
thowland@vsicom.com               http://www.vsicom.com