Alternatives for get_filtered_file@()

I have been using this function for many years, but now have run across a potential snag as it interfaces to my SW.

Specifically, I have a 'Save' function that allows the user to save settings into a file. The user may have loaded a file of settings previously. If I provide this file name to the function, but the user clicks the 'Cancel' button (or close the dialog using the 'X'), there is no method by which to detect if the user has cancelled. If the user has specified the same file, then I ask if the user wishes to 'Overwrite', but since they clicked 'Cancel' this is confusing. It was to me the first time I experienced it! Also, if the user had inadvertently typed a new file name, but decided to 'Cancel', it would then be used as a valid file and 'Saved'. No way to detect what the user has done.

Perhaps a CLEARWIN_INFO@() parameter that would let you know if the user cancelled the file operation? Or, a LOGICAL FUNCTION version of this; FALSE=user cancelled or other file naming problem (there are a lot of possibilities).

Bill

Bill,

You are probably right to ask for that check. You can, of course, examine the date and time stamps to see if the file was actually saved, but of course, only after you have checked that it actually exists. (A Cancel may prevent writing the file in the first place, or in overwriting an existing file).

I find the greying out process in the items in a File menu pretty taxing, for example, disabling Save after a save, until something has been done to the dataset. Similarly, once there is something in play, I have to disable Open as I don't have an MDI philosophy because it is too hard (Instead, I reckon to be able to launch multiple instances of my applications).

There is a matching set of problems associated with saving on exit, and if the user has actually saved their work, including when exitting Windows.

Eddie

Bill

Here is a sample program. Please let me know if it leaves any outstanding questions.

     WINAPP
     PROGRAM sample
     INTEGER iw
     INTEGER,EXTERNAL::open_func
     iw = winio@('%ca[Sample]&')
     iw = winio@('%mn[&File[&Open,E&xit]]',open_func,'EXIT')
     END
!------------------------------------------------------------
     INTEGER FUNCTION open_func()
     USE mswin
     CHARACTER file*256,path*256,title*20
     INTEGER,PARAMETER::NFILTERS=2 
     CHARACTER*20 filtname(NFILTERS),filtspec(NFILTERS)
     title = 'Open Fortran File'
     file  = ' ' !Or the path of a file.
     path  = 'C:\techsupport'
     filtname(1) = 'Fortran files'
     filtspec(1) = '*.f90'
     filtname(2) = 'All files'
     filtspec(2) = '*.*'
     CALL get_filtered_file@(title,file,path,filtname,filtspec,NFILTERS,1)
     IF(len_trim(file) == 0) file = 'Open dialog cancelled by user.'
     iw = MessageBox(0,file,'Sample',0)
     open_func = 2
     END

Paul, if the file name is set, I cannot cancel without manually clearing the field in the Open dialog.

What you have here is exactly what I normally do when I am asking the user to specifically, unequivocally, asked to provide a new filename. I set it to blank so if the user presses 'Cancel', it remains blank.

I give the user an option to 'back out' of taking an action, usually by cancelling (via a button). This open file dialog doesn't allow me to have an option for the user to think 'OOPS, wrong path!' and cancel out without clearing the filename first.

If there is a better alternative to accomplish this, I'm in!

Bill

I am still not clear about what is lacking.

When calling get_filtered_file@, you can input a file name. Also the user can select a file when the dialog is open. In either case you get a blank-filled file name on return when the user clicks Cancel.

Once the dialog is open, ClearWin+ does not provide any control over how it is used. The corresponding Windows API function provides for a programmer's callback function but I doubt that it would help you.

Maybe a video would help me understand what you are aiming for. I find that Zoom is quite easy to use.

Eddie, the get_filtered_file@() function doesn't save the data; my function does, but it checks first to see if the user wishes to overwrite since the file does exist (yes, I do that check already, which is part of the source of confusion for users).

Paul, I can understand the confusion. Let me try this as a text example. This assumes you are using the API GetSaveFileNameA(). If that is not the case, please let me know what API function is being called.

1. You open a document in your application.
2. You work on the contents of that file.
3. You click 'Save'. The API dialog now presents options that allow you to choose another file and Save, or you can Cancel.
4. You realize that you've missed an edit and don't want to save it, yet. You click 'Cancel'.
5. Your application (because you've set it up this way) asks you if it is OK to overwrite an existing file.

The issue is that while GetSaveFileNameA() can detect that the user clicks 'Cancel', this normal behavior is not available to the invoking application.

Yes, I could provide a 'Save As...' AND a 'Save' option. 'Save As' would certainly capable of setting the file name to blank and detecting it. But what if the user, while clicking through folders, inadvertently clicks on a filename? No way to cancel that either. 'Cancel' is not recognizable by the calling application.

Bill

I am still not getting it.

Normally....

1. The Open file dialog is used to open a file.
2. The user works on it.
3. There is then the option to directly save (i.e. using the known file name, no dialog) or 'Save As' by firing up the 'Save As' dialog. The result of 'Save As' can be Cancel and the meaning is clear.

In either case (Save or Save As without Cancel) you could prompt with an 'Are you sure you want to' message box but that would not be normal.

Paul, you are right.

I also found, buried deep in a section of code, a coding error that convinced me this was not working correctly any more. So, my mistake! And my sincere apologies for the 'rabbit hole' of my own making I went down.

Mea maxima culpa, Bill