Creating a new folder

I may have a reason for this crash in one user account/machine and not another.

The FTN95 function browse_for_folder1@ uses the shell function SHBrowseForFolder as its base. The MSDN documentation says that from Vista on, it is best to use IFileDialog.

From Stack Overflow, the reason is the complexity of the folder dialog (many items) can cause the control to crash or yield 'odd results'. Indeed, the dialog visually appears to act a bit differently when invoked from different user/machine accounts.

http://stackoverflow.com/questions/15293557/selectdirectory-shbrowseforfolder-issue-when-having-a-lot-of-shell-items/15293771#15293771

Working on a temporary (?) solution....

I have decided to revert all my code from using browse_for_folder1@ to use browse_for_folder@, removing the ability to create a new folder by the user.

While taking away a 'standard' benefit from the code is lamentable, causing a crash is not a choice I can leave to the user.

I have experimented with IFileDialog, the suggested better way, but have not been able to successfully integrate this function with FTN95. I will continue, but I give this little hope of success at present.

Since this IFileDialog function is only available in Windows Vista and later, perhaps it is not the best choice for FTN95 at the present time. I also have users who are still using Windows XP on some field data input devices, so (for me) the die is cast.

If you know which OS creates the fault then you could test for the OS and make a choice in your code. See GET_OS_VER@.

It should also be noted than using a regular file open dialog (using GET_FILTERED_FILE@) then attempting to create a folder also causes a crash.

Now that I have transitioned to /DEFINT_KIND 3, the crash previously caused by creating a New Folder no longer occurs.

I don't know exactly why this should make a difference but if (say) you use /DEFINT_KIND 2 instead of /DEFINT_KIND 3 (which is the default) then literal constant integer arguments like the value 42 will be passed as the address of a 16 bit value. That is, it will be passed as 42_2 and not 42_3. This may make a difference and the effect could be different for 32 bit executables against 64 bit executables.

Putting this another way, /DEFINT_KIND changes the KIND value of literal constant integers that are not given a specific KIND value.

I did avoid literals in the calls to this function unless they were declared with an 'L', or declared specifically as INTEGER*4 and a parameter.

I cannot explain the difference in operations. Just an observation.