GET_FILTERED_FILE@

This function presents the usual 4 icons alongside the 'find file in' field ; namely, Go To Last, Up One Level, Create New Folder and View Menu.

When the View Menu is invoked to change the types of detail this request is forgotten the next time the function is called.

Is it the responsibility of the application to have knowledge of the users change ?

Steve,

I've been using this without giving it a second thought, and making the main user (me!) go through the directory tree every time. You can take the returned file, and take out the path for input next time as the start location, in which case, it IS the responsibility of the app to keep track of what was selected, and it isn't all that difficult.

But, you can't pick up the path if not file was selected, e.g. the user cancelled.

Your post made me think about the function - and the fact that I'm not finding it very inconvenient. Why? It all boils down to how the program leads the user through file selection.

Have you thought of using BROWSE_FOR_FOLDER@ to define the folder where a user's files are, and keeping track of that? Then he is less likely to wander off track when finding his file (presumably as input), and hence it matters less if you don't keep a track of the path eventually chosen with GET_FILTERED_FILE@, because it isn't far away from the initial directory, and therefore not all that inconvenient to go there. It's what I do.

I see that I save the file path choices in an old-fashioned INI file, and thus they aren't even volatile between runs of the program.

If I was only using GET_FILTERED_FILE@, then I would have found it frustrating to keep retracing the same directory changes each time, which is presumably why you asked.

Apologies, this is a bit convoluted.

Paul, as usual, may have a more elegant answer ...

Eddie

Litus,

Maybe I did not express myself sufficiently well !

The change that a user makes to the View Menu option after the GET_FILTERED_FILE@ is invoked is what I am referring to. Why cannot Silverfrost / Windows remember the change from say 'List' to 'Thumbnails' or say 'List' to 'Details' ? Or have I to code the @ function call to permit the application to remember the user setting of View Menu ?

It is understood that the application must control the path selection - there is no issue here.

Steve,

Now its my turn to confess - I never used that setting. It simply isn't one of the Clearwin options, is it? Perhaps one of the constants in the '.ins' file(s) controls it

Eddie

GET_FILTERED_FILE@ makes a call to the Windows API function GetOpenFileName or GetSaveFileName. GET_FILTERED_FILE@ tries to use and set the 'current working directory' and I suspect that the API functions may also use this independently.

Anyway you could try using ATTACH@ to set the current working directory before the call to GET_FILTERED_FILE@. After the call you could check to see if CURDIR@ gives the desired directory.

Paul,

Are you suggesting that the Windows API, when invoked by Get_Filtered_File@, is not remembering the users choice within the View Menu option ?

Others software - likely not to use Clearwin+ - when ultimately the Windows API call is made do indeed remember the users View Menu selection

My comment related to something else (the folder that you see when you open a standard dialog).

GET_FILTERED_FILE@ does not remember the View Menu option used on the previous call. In theory it could but the underlying GetOpenFileName (or GetSaveFileName) does not set or return a flag for this. These functions use a default value (List). GetOpenFileName does allow you to provide a callback function and, with clever programming, you can arrange for the callback function to change the default setting after the dialog has be opened. You may also be able to get the user's setting when the dialog is about to close.

In short, GET_FILTERED_FILE@ does not remember this setting and Microsoft does not provide a direct way to set and get it even when you call GetOpenFileName directly.

Paul, many thanks for finding this out for me.