Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How do i add browse button? 4

Status
Not open for further replies.

Mandy_crw

Programmer
Jul 23, 2020
578
PH
Hi everyone.. I have a page in my application that edits a record... I want to put a browse button and look for the picture of the owner of the record and rename that picture which should be desame with its idnumber.... Would you please help me how to start or give sample code that i can adapt? Thanks and God bless....
 
Hi Mike,

Well, FILE() may be “reliable” in your sense, but I remember having some serious issues (with hindsight probably with false positives). Changing the code to ADIR() according to help from Tek-Tips or Foxite solved all these issues.

I don’t see any reason whatsoever to NOT use ADIR() instead of FILE(), as I never need to search in more directories. And of course ADIR() has many more things to offer when working with files.

Regards, Gerrit
 
Thanks for that, Gerrit. I wasn't disagreeing with you; I was just curious about the word "unreliable". I must say I am still not convinced, but by all means use ADIR() if you think it better.

Actually, I don't often use FILE() myself. I just did a search on one my largest projects. It has 120,000 lines of code, but it only uses FILE() five times: four of them to check for the presence of a company logo to include in reports; and once to check for the presence of an FRX which the user selects for printing - and in that case, it correctly returns .T. if the FRX is embedded in the EXE. Of course, all applications are different, and this one might well not be typical.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
May I revisit the use of FILE() for testing the result from GETPICT() or GETFILE() as suggested by Chris near the start of this thread?

The point was that using FILE() in that way has two purposes: (i) To see if the user cancelled the dialogue; and (ii) to check that the file they specified in the dialogue actually exists. My reply was that those were two quite different cases that needed different actions.

If the user cancels the dialogue, they are indicating that they want to cancel the entire process - whatever process the dialogue was part of. For example, if the purpose of the dialogue is to specify a text file to import into a memo field, cancelling the dialogue is the same as cancelling the import. So the correct action for the program would be to do nothing: just exit from the function or method or wherever else the action is specified.

In the second case, the user can specify a file that doesn't exist by typing the file name manually rather than picking from the dialogue. That would be a user error. (Conceivably, it could also happen if the file happened to get deleted between the user opening the dialogue and selecting the file, but that would be rare.)

How you deal with this case would depend on the severity of the error. Trying to read a non-existent file into a memo field would result in a VFP runtime error, so you definitely want to test for that. I maintain that FILE() would be perfectly OK for that, as you would always pass a fully-qualified file name (as returned from the dialogue), so you won't have to worry about the search path or files embedded in the EXE.

Another example would be if the user specified a non-existent image file for use with an image control. In that case, VFP would not raise an error. The result would be that the image would remain blank. So I would be inclined to ignore that, on the basis that it would be obvious to the user.

Of course, even if the image file exists, there's no guarantee that it is a valid image. There's nothing stopping the user selecting a text file or any other file type, even from GETPICT(). As far as I know, there is no way of checking that a given file is a valid image file. But even in that case, VFP won't raise an error. The file name will be correctly stored in the Picture property, but no image will show up in the control.

So to summarise, this is my conclusion from this thread:

- Whenever you use GETFILE(), GETPICT() or any other "dialogue" function, always check to see if the returned value is empty; if it is, do not proceed with whatever action the dialogue was being used for.

- If the consequence of selecting a non-existent file would cause a runtime error, use FILE() to check that the file exists. (By all means, use ADIR() if you prefer, but FILE() is more concise and works just as well [in this case]).

- If the consequence of selecting a non-existent file does not cause an error and is obvious to the user (as in my example of an invalid image file, above), then do nothing.

I'm not being dogmatic about any of this, nor am I trying to persuade anyone to change their ways. I'm just saying that this is the way I have always done it, and it has worked well for me.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
There also is a very pragmatic solution not checking, just trying...

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()
Try
   Copy File (lcUserPicture) To "c:\Graphics 2021\Pictures\" + this.Parent.text1.value + ".jpg"
   MESSAGEBOX("Picture marked and copied to Pictures folder!",0+64,"Information")
Catch
   MESSAGEBOX("Something went wrong, please retry.",48,"Attention")   
Endtry

Chriss
 
Thanks so much Mike and Chriss as I read all you explanations and given examples it gives me so much learnings… thanks… but i’ve also seen “array” although i have read and research it already, i dont know how and where to use it… please give me examples on how and when to use array Chriss… thanks…
 
Thanks for this very good article, Tamar.
It was written in 2001 but still very useful.

At that time, VFP9 was not yet available.

Mandy should watch, that e.g. in VFP 9 now more than 65,000 elements of an array in VFP 9 are possible.

See VFP9 help:
[i]You can now specify arrays containing more than 65,000 elements, for example, when using the DIMENSION command. Normal arrays and member arrays have a new limit of 2GB. Arrays containing member objects retain a limit of 65,000 elements.[/i]

Peace worldwide - it starts here...
 
Thanks Tamar and German12.... I'll try to read and study it... God bless
 
Mandy,

the only reason I used Local Array laDir[1] in one line is, that I used ADIR in the next line, and ADIR is one of many VFP functions that create an array - or - as I prefer it - extend an existing array. In this case, the array isn't even used, I just use the return value of ADIR, which states how many array rows are created so If Adir(laDir,lcUserPicture)=1 means that ADIR finds the lcUserPicture file on the hard drive (instead of a file named the same within the EXE), it could also be 0, if this file is not on the hard drive, but might still be in the EXE. It could never be 2 or higher, as lcUserPicture is a specific file with the full path to it, that's what GETPICT() returns, it never returns a file name with a relative path or without a path at all. By the way the declaration of the array is optional, ADIR also reates an array, if it doesn't exist. But its scope then is PRIVATE, not LOCAL. Remember scope, it's a very important topic to not step on our own foot in many cases. Scopes should always be as small as needed, and that's LOCAL in this case.

The array aspect of this is otherwise unnecessary, I don't even use the array at all, I just ensure it's only scoped and visible to the method itself. I see it triggers your interest and that's fine, of course. If you ask me, arrays mostly play a role in one case: When functions create them, like ADIR(), ALINES(), AUSED() and many more. Most of the time I prefer the cursor as similar data structure, as cursor fields have names, not just a numeric address, as array elements. Cursors can be results of queries and can then be part of further queries. Arrays can also be created as a result of a query, but you can't use them as a table of the FROM clause, so regarding SQL arrays are dead ends, cursors are playing in the major league of VFPs workareas.

Chriss
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top