Glenn,

Thank you for your response, which confirms that the call to 
GetSaveFileName has repercussions (which, in my opinion, are undesirable).

I did try to get a directory listing after the call to 
GetSaveFileName (using perl and using backticks) and it seems to 
indicate that the current directory has not changed.  Still, the 
backtick commands do not see the files in that directory unless I 
specify their full path.

One thing I should try is to use ./filename instead of the full file 
path and see if that works.  If so, that would be a decent workaround.

Thanks again,

Gabriel


At 09:28 AM 4/8/2008 -0700, Glenn Linderman wrote:
>On approximately 4/7/2008 7:04 PM, came the following characters 
>from the keyboard of Gabriel R. Toro:
>>Hi,
>>
>>This question may be too simple for this group; if so, I apologize. 
>>I only use perl once in a while and this is my first experience 
>>with Win32::GUI.
>>
>>I wrote a simple perl script that calls GetSaveFileName to get the 
>>name of an output file and then calls the shell to execute some 
>>separate programs (I get the same problems using backtics or 
>>system). After the call to GetSaveFileName, the shell commands do 
>>not seem to find the necessary files (even though the files exist 
>>in the current directory), unless I specify the full path for those 
>>files. If I remove the call to GetSaveFileName and hard-wire a 
>>name, everything works.
>>
>>It is not a problem with the subroutine that calls GetSaveFileName; 
>>the subroutine returns the right name (including full path). It 
>>seems like Win32::GUI is having some undesirable side effect:
>>-does Win32::GUI change the current path? (my tests suggests it does not)
>>
>
>No.
>
>>-does Win32::GUI change the shell that executes the backtick or 
>>system commands or the settings of that shell?
>>
>
>No.
>
>>-anything else?
>>
>
>The GetSaveFileName dialog in Windows is known to change the current 
>directory, if you navigate away from the default location initially 
>displayed.  This can have repercussions, as you've experienced.
>
>There is a question of whether the Win32::GUI::GetSaveFileName 
>should pass through this behavior (as current) or should protect the 
>user from it (save & restore the CWD), or better document the 
>behavior of Windows itself.  I find that behavior of Windows rather 
>unfriendly, although I'm sure Bill can justify it as some sort of a 
>monopolistic practice.
>
>>I would appreciate any suggestions.
>>
>>Thanks,
>>
>>Gabriel
>>
>>
>>PS: Here is my GetSaveFileName (which, as I indicated, is working 
>>OK except for the "side effects").

....removed ...




>>-------------------------------------------------------------------------
>>This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>>Register now and save $200. Hurry, offer ends at 11:59 p.m., 
>>Monday, April 7! Use priority code J8TLD2. 
>>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>>_______________________________________________
>>Perl-Win32-GUI-Users mailing list
>>Perl-Win32-GUI-Users@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>>http://perl-win32-gui.sourceforge.net/
>>
>>
>
>--
>Glenn -- http://nevcal.com/
>===========================
>A protocol is complete when there is nothing left to remove.
>-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
>


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/

Reply via email to