_WinAPI_GetSaveFileName don't return file extension

[erix]

Hi Autoit Expert,

Since Autoit 3.3.14.4 _WinAPI_GetSaveFileName don't return file extension in the result.

Before, if i don't say something wrong, when i used a code like that :

#include <WinAPIDlg.au3>

$export = _WinAPI_GetSaveFileName("Select a file", "CSV (*.csv)|txt (*.txt)")

MsgBox(4096,"",$export[2])

The result for $export[2] was file.csv or file.txt

Now, i only have "file" without extension

Of course, it's if user give only name of file and doesn't write the extension.

So, now how can i know if user have selected CSV or TXT.

Thank you

Eric

[Melba23]

erix,

Works for me as expected using v3.3.14.5 - I get the extension appended to the filename.

M23

[kaz]

I ve just test, and if the user don't type extension, the result doesn't contain extension for me to.

[Melba23]

kaz,

You are right - thanks for testing.

M23

[Melba23]

erix,

More testing shows that if you  set the $sDefaultExt parameter to anything other than a blank string (the default setting) you get the selected extension returned even if it is not appended to the name in the dialog input:

#include <WinAPIDlg.au3>

$export = _WinAPI_GetSaveFileName("Select a file", "CSV (*.csv)|txt (*.txt)", Default, "", "*")

MsgBox(4096,"",$export[2])

I am now looking in the repository to see if I can find any changes made to that function that might have caused this change you detect.

M23

[erix]

Right Melba, it works. While waiting for a correction i will use this trick.

Thanks kaz for your confirmation.

[Melba23]

erix,

Are you sure that it used to return an extension before v3.3.14.3? I ask because we have not changed anything in the function and MSDN suggests that the behaviour you are seeing is what should be expected.

So we are not going to amend the function - it could break existing scripts - but we are going to add the following remark to both _WinAPI_GetSaveFileName and _WinAPI_GetOpenFileName:

Quote

###Remarks###
Note that if the $sDefaultExt parameter is left blank and the user does not append an extension in the dialog input then no file extension is appended to the returned filename, even if there are multiple options in the filter and a user selection has been made from the dialog combo. Setting this parameter to any value will force the function to append the selected extension to the returned filename - or the default value if no selection is made.

So you will need to continue adding a parameter as I suggested above - but at least you will now know why you need to do so!

M23

[erix]

Hi Melba.

I tried with Autoit 3.3.14.5 and 3.3.14.2

With 3.3.14.5, result are without extension

With 3.3.14.2, result are with extension

Just one difference in my test, the include is not the same.

Thanks

Eric

 

[Melba23]

erix,

Thanks for that. The WinAPI includes were all rearranged between v3.3.14.2 and v3.3.14.3 so that none were absolutely huge in size - I will take another look at the functions in the 2 versions over the next few days and see what I can find out what changed, as obviously something must have happened despite jpm's protestations to the contrary.

M23

[Melba23]

erix,

OK, we now have a clear idea of what is going on.

What happened: MSDN says that the result you get in 3.3.14.5 is what you should get. The function used in 3.3.14.2 and earlier used a "hack" to append an extension if nothing was chosen by the user - when the WinAPI includes were rewritten, the function was completely rewritten and that "hack" was not included. So the old function was actually "wrong" and the new one is "correct".

What will happen now: We are going to keep the new "correct" function as it is what MSDN tell us should happen and add something along the lines of what I posted above to the remarks in Help file page to explain the "new" behaviour. We will also add a "Script-breaking Change" to the change-log so that people are aware that they need to do something nowadays to get an extension returned.

Thanks a lot for telling us about the change in behaviour - none of us realised that the old function had this rather clever "hack" within it!

M23

[erix]

Ok, thanks Melba for your research and this explaination.

Eric