Putfile() loses filename

[tkee]

This is my code:
m.path = FULLPATH('gctrl2.dbf')
m.path2 = LEFT(m.path,LEN(m.path)-10)
mfile = m.path2 + 'KnoxGS' + LEFT(DTOC(DATE()),2) + SUBSTR(DTOC(DATE()),4,2) + RIGHT(DTOC(DATE()),2)
mfile = gcpath + 'GSPAYMENT_DATE_' + STR(YEAR(DATE()),4,0) + LEFT(DTOC(DATE()),2) + SUBSTR(DTOC(DATE()),4,2)
mfilename = PUTFILE("Prepare Update File", mfile, "txt")

On some computers it works as I would expect and brings up the window in the correct directory with the correct file name. On others it acts as though mfile doesn't exist and has no file name and is in a different directory, even though in debugging mfile is the same on both the computers where it works and where it doesn't. What am I missing?

 

[Tore Bleken]

Could it be a virtualization problem? This article describes the problem:

http://doughennig.com/papers/Pub/Vista.pdf

 

[Mike Lewis]

So what is different between the two types of computers (the ones where it works and the ones where it doesn't work)? Different versions of Windows? Different date settings? Some other differences?

Also, are you seeing the problem after the user has actually interacted with the SaveFile dialogue? If so, are you sure you know what the user is doing (they might escaping out of the dialogue, for instance)?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If you cancel from GETFILE or PUTFILE dialog the return value is an empty string. You can't force the choice or input of a filename.

Try yourself, if you set m.lcFilename='test', then m.lcFilename=PUFILE() and click Cancel, afterwards inspect m.lcFilename, it'll be empty. And of course FILE('') is .F.
You can address this with cancelling the overall process for which you want a file name specified or you enforce the user to select or enter a target file name.

And I just tried another problematic case: The file name contains a non-ANSI character, like for example 'α', then PUTFILE() returns an 'a' instead of α and of course that file does not exist.
In general, PUTFILE is there to provide a new file name, not to pick an existing file, if you pick an existing file name, the PUTFILE dialog even spawns a warning message box, whether you want to overwrite the chosen file.

Bye, Olaf.

 

[tkee]

The file name is empty in the Save File dialog box only on some computers. The computers should be identical, all Windows 7. They were all upgraded at the same time, so probably bought and installed at the same time by the same person. I have tried it myself on different computers with the same result. I'm not trying to force the input of a file name, just have a default. That is what doesn't show up. I test for an empty string after they close the window. The problem is before or when it brings the window up, not after they click on Save or Cancel.

 

[Olaf Doschke]

Well, you specify a file name in the second parameter of the PUTFILE function. CD to the base directory beforehand.
You can also specify a full file name, but it won't create missing directories.

Bye, Olaf.

 

[Mike Lewis]

So what you are saying is that the parameter you are passing to PUTFILE() is blank? In other words, the fault is taking place before the call to PUTFILE()?

If that's so, we can rule out virtualisation as a cause, given that you are not actually creating or saving a fle at this point, so there would be no oppportunity for virtualisation to kick in.

However, I can confirm what Olaf said about non-ANSI characters. I've also just been doing some tests. If you pass a filename with, say, an accented letter or non-ASCII currency sign, the filename will appear blank in the dialogue. The same is true if the name contains a character that is illegal in filenames, such as ?.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

even though in debugging mfile is the same on both the computers where it works and where it doesn't

Lets begin with what you see when you do your Debugging....
If you put a Breakpoint or a SET STEP ON just before the code you show and then single step through the following code, do you see the EXACT SAME values for each of the variables that are being assigned?

If not, then you have found your problem.

Additionally in your Watch window you can look for FILE(mfile) and see if that is 'seen' by the application prior to the PUTFILE().

Give that a try and let us know what you find.

Good Luck,
JRB-Bldr

 

[tkee]

The values are not exactly the same. For the ones where it works as I want it to it has a drive letter Ex: s:\shareddrive.....
On the ones where it doesn't work properly it has the correct path, but no drive letter Ex: \\shareddrive...
I'm sure this is the problem, but don't know what to do about it. They all use the same batch file to map.
Thanks for all the help!

 

[Mike Lewis]

They all use the same batch file to map.

Well, it looks like the mapping isn't working on all the computers. Or, rather, isn't working in the way you think it is. So the next thing to do is to check that your batch file is doing what you expect.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

If you read the VFP Help on FULLPATH() you will see that you might get a value even if the file cannot be found.

If the file cannot be located in the MS-DOS path, FULLPATH( ) returns the path and the file name as if the file was located in the current default directory.

But if the actual file was Not in the current default directory, then you would be getting an non-valid value.
For Example - I just now went into my VFP Command window and typed: ?FULLPATH("Temp.XTX")

And, in spite of the fact that the file does not exist, I got back: C:\PROGRAM FILES\VFP9\TEMP.XTX​

I think that if I were doing this, I'd not use FULLPATH() where, according to the Help file, I could possibly get a wrong value.

Now, as to what you got in your Debug efforts.....

On the ones where it doesn't work properly it has the correct path, but no drive letter Ex: \\shareddrive...

NOTE - both UNC paths (ex: \\shareddrive\...) and finite drive mapping (ex: S should both work to define a path as long as the workstation itself can access both. But if it cannot access one or the other, then a problem will arise.

Perhaps try using the Windows Explorer and just paste the \\shareddrive.. path into its address window and see if the workstation can indeed access that UNC path at all.

If not, then maybe user permissions and/or other user-specific Windows drive/path SHARE rights need adjusting.

Good Luck,
JRB-Bldr

 

[tkee]

FOUND IT! Thanks for all your help. Somebody updated some of shortcuts to start the program differently. I don't understand exactly why it made a difference, but it did. They're all back working now.

 

[Olaf Doschke]

Changing the start/working directory in a shortcut changes the current directory of the application, so yes, this will affect how PUTFILE() works or not works. Anyway, I'd rather always CD to some dir and then call Putfile() with the filename only, so CD JUSTPATH(...) and PUTFILE('',JUSTFNAME(...)).

Also to work with YOUR intended working directory you can orientate an initial CD to SYS(16,0).

Bye, Olaf.

 

[Mike Lewis]

Good to hear that you have solved the problem. But it highlights a serious weakness in your application.

The fact that you are relying on the user starting the application in a particular directory means that you have no control over the directory that the application sees as its default. That it turn means that there is a risk of the application not finding its files, or not creating files where you expect them to be. In particular, it explains why your FILE() function returned an unexpected result.

It would be better always to set the default directory explicitly, using the SET DEFAULT command. If you want the default to be the same as the directory from which the application was launched, you should do something like this:
[tt]
SET DEFAULT TO JUSTPATH(SYS(16))[/tt]

Just put that at the start of your main program, and the situation you described should never arise again.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, JUSTPATH(SYS(16)) has a pro for simplicity, but if you sort your project files in subfolders \PRGS\,\LIBS\ etc., and main.prg is in \PRGS\, a subfolder in relation to your PJX file, then SYS(16) varies between starting within the IDE and in the compiled EXE, therefore I said orientate to SYS(16).

For my case I use lcHere = STRTRAN(JUSTPATH(SYS(16,0)),"\PRGS","") and then CD (lcHere), also I save that as goApp property.

A simple solution also is to put main.prg in the same folder as the PJX file, then JUSTPATH(SYS(16)) is the same path no matter whether you start main.prg or the EXE.

Bye, Olaf.

 

[Mike Lewis]

A simple solution also is to put main.prg in the same folder as the PJX file, then JUSTPATH(SYS(16)) is the same path no matter whether you start main.prg or the EXE.

Yes, that's exactly what I do.

Also, I have a standard set of sub-directories for my source files, below the "main" directory (the one containing the project, the main program, etc). Those sub-directories are for Forms, Reports, Code, Classes, etc. In my SET PATH, I specify the relative paths to those directories (relative to the default directory). This means that, when I start a new application, I can simply copy that standard directory structure to the new location, and can always keep the same SET DEFAULT and SET PATH commands.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

>Yes, that's exactly what I do.
Then your solution works, but this has to be told as a prerequisite, not everybody has their main.prg there.

In regard to DBFs the DBC is a great service of finding a certain table by its name only. And yes, I know relative paths are stored within the DBC for that to work, but that only breaks, if you move around DBF and DBC in a way their relative path changes.

So in the end, I actually also use relative paths, but only where I can be 100% sure this won't break. Things like third party code can do so, stored proc code, timer code....

VFP also takes the precaution to store absolute paths, for example when you SET DEFAULT to somewhere, and then SET PROCEDURE or SET CLASSLIB to a list of relative paths, then look into SET("PROCEDURE") and SET("CLASSLIB") and you see VFP internally has stored the absolute paths. That makes it independent on what you CD or SET DEFAULT to later and that's the stance I take, too. So in short, you can only rely on relative paths with such code, because VFP internally does not.

That's another reason I rather put together absolute paths with a base path determined from SYS(16) or any other relevant base path. I don't talk of hardcoded absolute paths, as that would need adaption to reuse code in another project or move a project. I'm totally on your side with that dynamic aspect, but I can determine base paths and then put together absolute paths from there and don't lose that flexibility.

Bye, Olaf.