Selecting a file without opening it

[c.haslam]

FileSelectFolder() allows the user to select a folder; FileOpenDialog() allows a user to choose and open a file.

How does one code opening a dialog to select a file without opening it?

[TheXman]

FIleOpenDialog() does not "open" the selected file(s).  It just lets you use the file open dialog. 

The return value upon success is a string containing the path(s) of the selected file(s), not file handle(s).  If it actually opened files, you would expect it to return file handle(s), like FileOpen().

For the record, the same way FileOpenDialog() doesn't actually "open" any files, FileSelectFolder() doesn't change the working directory.  It just lets you use the folder selection dialog.

Edited March 8, 2021 by TheXman

[c.haslam]

Thanks. It would be nice if this info were in the Help.

[Melba23]

c.haslam,

Quote

It would be nice if this info were in the Help

Where in the Help file page for FileOpenDialog does it even mention opening files? It specifically says:

Quote

Return Value

Success:the full path of the file(s) chosen

which is all that it does (other than change @WorkingDir if successful and which is also quite clearly mentioned). Do you expect us to say what it does NOT do as well? I mean it does not delete the files, nor change their attributes, nor move them up one level in the directory tree, etc, etc. What it does do is tell you the file(s) selected - which is, as shown above, specifically mentioned.

M23

 

[c.haslam]

You are correct, however given its name it would be nice if the Help made clear, in this case, that it does not open files. Had it been called FileSelectFiles all would be clear.

[TheXman]

Using your logic, what would you call a function that represents a common dialog box (named OpenFileDialog) that allows a user to specify a filename for one or more files to open (making sure that it followed the established naming convention for AutoIt file-related functions)?  Keep in mind that you want people to understand that it is a common Microsoft dialog box, not a custom dialog box.  Maybe....FileOpenDialog() or FileOpenFileDialog() (which is a little redundant)? 

Just because you misunderstood the naming of the function and didn't understand the help file's description of what it actually does, doesn't mean that every else has that same misunderstanding.  That's a bit self-centered isn't it?  You make it sound like function names should be tailored to you and your understanding, as misguided as they may sometimes be.  😉

Edited March 8, 2021 by TheXman

[c.haslam]

Having been away from AutoIt for a year or so, I was confused. I would call it FileSelectFile. The first "File" identifies it (and sorts it in the Help) as a file-related function. It would then be a "mate" to FileSelectFolder.

This change would break many scripts: you asked, so I suggested. It won't happen.

I note that FileOpenDialog labels the button as Open. But in the script I am writing, a selected file is never opened, so having a parameter to choose the label as Open or Select would be an advantage.

Mea culpa!

[Melba23]

c.haslam,

Alas, "FileOpenDialog" is the Microsoft name for that dialog, so that is what the AutoIt function is called. I sympathise with your plea, but best take it up with Bill Gates, not us!

M23

[pixelsearch]

Usually I don't participate in this kind of thread to avoid a "too much" passionate debate, but today I'll do an exception.

@c.haslam : your thoughts are exactly the ones I had 3 years ago when I discovered AutoIt, asking myself how a function named "FileOpenDialog" didn't open anything, especially when there's an "Open" button in the Dialog ! Isn't it supposed to be a "FileOpen" function (which opens a file) added to a GUI dialog ?

It's true that the help file stipulates "Success: the full path of the file(s) chosen." and chosen is a key word in this sentence. If the function doesn't open anything but simply "chooses" or "selects", then why isn't it called "FileSelectFile", based on the "FileSelectFolder" function name ? Or even "FileChooseFile" ? Everything without the "Open" word in it would be fine !

And for users who still don't find an issue with the word "Open" in "FileOpenDialog", then don't you think the function could also have been badly named "FileDeleteDialog" or "FileMoveDialog" or ""FileRenameDialog" ? With a help file stipulating in all cases "Success: the full path of the file(s) chosen." ?

I'm sorry but this GUI dialog function badly named "FileOpenDialog" is only a file chooser function not related at all with "Open". You can do what you want with the returned "full path of the file(s) chosen", you can delete the files, move them, open them etc...

Anyway, Melba23 gave us the correct reason why the function is named like that and I'm glad he "sympathises with your plea". Because of his open mind, he's able to understand people's concerns and, as I already told him before, he's able to place himself in other people's shoes to understand them better.

So c.haslam you're not alone on that one, I remember having had the same thought about the badly named "FileSaveDialog" function (which saves nothing at all) but when this "misfortune" happens to you once, then it shouldn't happen anymore after that... in theory.

Edited March 9, 2021 by pixelsearch

[JockoDundee]

3 hours ago, pixelsearch said:

how a function named "FileOpenDialog" didn't open anything,

to be sure, it opens a dialog

[Musashi]

I fully agree with @pixelsearch , that FileOpenDialog is a misleading function name (for at least 95% of the users).

However, @Melba23 's objection, that the naming was derived from Microsoft's specification, is comprehensible. Of course, it would go beyond the scope of any help to list everything that a function does not do. In "severe cases", a more exposed hint might be helpful, though.

4 hours ago, pixelsearch said:

So c.haslam you're not alone on that one

@c.haslam : You are definitely not alone with that one .

42 minutes ago, JockoDundee said:

to be sure, it opens a dialog

While I assume you meant it as a pun , from a purely linguistic point of view you're not wrong. FileOpenDialog could be interpreted both as a File->OpenDialog and as a FileOpen->Dialog.

[FrancescoDiMuro]

1 hour ago, Musashi said:

FileOpenDialog could be interpreted both as a File->OpenDialog and as a FileOpen->Dialog.

In this case, what the OP needs (and everyone who is interpreting in that way) is an English grammar course, and obviously, trying what the function does: it opens a FileOpen Dialog

Edited March 9, 2021 by FrancescoDiMuro

[pixelsearch]

Hellooo Musashi & FrancescoDiMuro
What about applying this "grammar split" to... FileSaveDialog

[Musashi]

19 minutes ago, pixelsearch said:

What about applying this "grammar split" to... FileSaveDialog

There are undoubtedly some function names, whose intuitive comprehensibility suffers from the adoption of Microsoft's naming conventions.

The question is : "What can be changed in this regard ?"

Altering the way these functions work to reflect what their names suggest, would result in script-breaking changes. Modifying the function names would lead to the same outcome. Apart from creating an UDF, an explanation of what the functions do not do in the help would probably be the best of the remaining options .

[TheXman]

6 hours ago, Musashi said:

There are undoubtedly some function names, whose intuitive comprehensibility suffers from the adoption of Microsoft's naming conventions.

The question is : "What can be changed in this regard ?"

I've got an idea!  What if there was an AutoIt reference file or document that painstakingly listed and described the AutoIt language, its use, what each and every function does and its parameters, and what the expected function's result should be upon success and failure?  What would be even better is if maybe they could throw in an example or two for most of the functions, because sometimes a good example can be worth a thousand words.  Maybe it could have a relatively easy to read, standardized, format so if it was used often enough, one could quickly find the answers to these types of questions about AutoIt.  Having such a document would surely clear up 95% or more of the ambiguities of naming conventions because it would clearly define its own language (AutoIt).  One would merely need to read this document to find and understand exactly what any given AutoIt language element does and how it could be implemented.  A document like that, if read and studied, might even make discussions like this one completely unnecessary.  I know, it's a pipe dream.  There's no way such a powerful document could or would ever be created and maintained.  🙁

Nevertheless, I really wished such a document existed.....oh wait.....it does!  It's called the Help File.  

Sorry, I couldn't resist. 

Edited March 9, 2021 by TheXman

[Melba23]

Musashi,

Quote

an explanation of what the functions do not do in the help would probably be the best of the remaining options

Dream on!

M23

[Musashi]

1 hour ago, Melba23 said:

Dream on!

Please don't take my dreams away .

9 hours ago, Musashi said:

 @Melba23 's objection, that the naming was derived from Microsoft's specification, is comprehensible. Of course, it would go beyond the scope of any help to list everything that a function does not do. In "severe cases", a more exposed hint might be helpful, though.

Finally, however, you , @FrancescoDiMuro , @TheXman [et al.] are of course right. If someone is interested to delve deeper into AutoIt, then she/he should also have the willingness and ability to deal with such inaccuracies in the addressed function names . Therefore, this aspect of the discussion can probably be declared as finished.

[c.haslam]

At the significant risk of offending MS experts and Bill Gates, how about changing the first line of the Help from "Initiates a Open file dialog" to "Selects a file or files for opening"?

 

Has anyone written a UDF that looks and behaves like FileOpenDialog but has "Select" rather than "Open" on the button?

[TheXman]

23 minutes ago, c.haslam said:

Has anyone written a UDF that looks and behaves like FileOpenDialog but has "Select" rather than "Open" on the button?

If you are purely interested in the functionality and not the look & feel, then maybe

 

Edited March 10, 2021 by TheXman
Corrected typo and grammatical error.

[Melba23]

c.haslam,

You are the first person to have mentioned this matter to my knowledge - given that Jon has mentioned that there are roughly 2500 downloads of AutoIt per day (yes, really) I would suggest that you are in a significant minority in this matter. The command opens an MS OpenFile dialog - so that is what the Help file tells you and the vast majority of users seem to understand what this provides.

And in answer to your second, my ChooseFileFolder UDF (the link is in my sig) does indeed use a "Select" button to return the files selected.

M23

Edit: I see TheXman beat me to it!

Edited March 10, 2021 by Melba23