I tried what I find people say - that the FILE() function reports false positives. Let me check...
It's true that FILE() will report the existence of a file if that file is also part of the EXE. You can then specify a path at which the file does not exist and even specify a path that doesn't exist in itself. VFP will first only look for JUSTFNAME() within the EXE and return .T., if it finds the file within.
To cover that concern, ADIR() is a good function to ensure the file is only searched at the specified path. I don't expect user photos to exist within the EXE, but in some cases, they might be brought to Mandy and her coworker with generic names like "1.jpg", which could also likely be the name of a jpg included in the EXE as part of the UI design.
So, it's a valid concern, Gerrit, thanks for pointing it out. Still, the false positives are of low concern, COPY FILE will only copy from hard drive, so even if 1.jpg exists within the EXE but also exists and is picked from a folder on the hard drive, that is what will be copied, since COPY FILE doesn't first look for the file of that name within the EXE. Actually, to copy a file from within the EXE to somewhere else you need to use FILETOSTR(), which reads a file from within the EXE, not COPY FILE. That makes the concern less hard, but since I had a concern with tempering of the filename which already is not usually happening from the two users who want to use their application correctly and don't need to break it, as they own and maintain and program the source code.
Nevertheless, this is how it can be used overall:
Code:
Local lcUserPicture
IF EMPTY(this.Parent.text1.value)
MESSAGEBOX("Please choose a record for image edit!" + CHR(13) + "Click Ok to retry!",0+16,"Information")
RETURN
ENDIF
lcUserPicture = GetPict()
Local Array laDir[1]
If Adir(laDir,lcUserPicture)=1
Copy File (lcUserPicture) To "c:\Graphics 2021\Pictures\" + [highlight #FCE94F]this.Parent.text1.value[/highlight] + ".jpg"
MESSAGEBOX("Picture marked and copied to Pictures folder!",0+64,"Information")
ENDIF
I'd only consider not keeping this UI dependency, as the source of the file name should be the id field of the user table, not the textbox that displays it. Aside from the fact a user id should be just the key the database and code and programmer sees and knows, not a field displayed to the application users at all. It's not data you show or even enter or modify, it is a key created by the database and to identify a record for code, not for an application user.
If you get there and understand the importance of that, Mandy, you'll eliminate these fields from forms. And then your image browse button stops working as you don't remember it took the user id from this text box instead of taking it from its source, the table.field.
Face it, once you have a user id as autoinc, it's a readonly field. Cyopiying it to a textbox, the textbox.value is editable, you could use an edited value to name the user image and that will not be writable to the user id field in the DBF, so you have a mismatch there. Take the user id from the usertable field that stores it, from nowhere else. It could even be worse and you use a char field for the user id that actually is editable.
Chriss