Easy use of GetOpenFilename in Quickwin

[dboggs]

I recently stumbled upon a real gem in Quickwin: if you use compiler switch /fpscomp:filesfromcmd, then the statement OPEN (unit, FILE=' ') will bring up the windows file select dialog box for the user to search for and enter a file. This is far easier than using the API GetOpenFilename as described in one of the samples programs. I spen hours getting that to work--and here it is available with one line of code!

The documentation is almost nonexistent, nearly impossible to find, but it is mentioned under "fpscomp" (in the proverbial fine print).

I have two questions/requests about this feature:

1. Why does one need the switch fpscomp to obtain this behavior? Why couldn't it be standard in a Quickwin program?

2. The dialog that pops up has the default file mask of *.txt. Is there any way to control this? I had high hopes that FILE='*.DOC' (for example) might carry through to the dialog--but alas. Seems there should be some other way that is still easier than the API GetOpenFilename call.

Quickwin developers at Intel, take note!

[jimdempseyatthecove]

Nice catch, good to know. I guess FILE=' ' indicates use pop-up file selector (with default pattern of *.txt). Perhapse there is (or should be) an additional keyword PATTERN='*.dat', or MATCH=, etc... Maybe there is, I haven't looked (also I do not have the newest release of IVF). Jim Dempsey

[Steven_L_Intel1]

This feature was in Microsoft Fortran PowerStation. We enabled it as an option. There is no user control of the dialog - if you want that, you can call GetOpenFilename yourself - we provide a worked example.

[Paul_Curtis]

IMHO depending on the implicit behavior of an obscure compiler flag to implement a needed and complex UI feature strikes me as really poor programming practice (but then, I also think using abstraction layers such as Quickwin is a poor idea too). I would suggest as a general principle that the more explicit and fundamental low-level code your application contains to accomplish its goals, the better, since this approach retains control as much as possible with the code itself, invaluable for debugging and extending. What will you do when Windows 8 or 9 comes out and that compiler flag suddenly no longer works? GetOpenFileName is already deprecated, here is what MSDN has to say: "Starting with Windows Vista, the Open and Save As common dialog boxes have been superseded by the Common Item Dialog. We recommended that you use the Common Item Dialog API instead of these dialog boxes from the Common Dialog Box Library."

[Steven_L_Intel1]

It may be deprecated but it will still work. We found that a lot of people were surprised by the behavior and I would not call it "needed". Nevertheless, that decision was made 15 years ago so it's a bit late to change it now.

[Paul_Curtis]

Steve, I'm not suggesting that the flag doesn't work or needs changing, only that programs which rely on that behavior (and make no effort at mastering the Windows API beyond invoking a compiler flag) may find themselves at risk.

[Steven_L_Intel1]

I don';t see a risk. If we find out that the functionality stops working in some future Windows version. we'll just switch to the newer interface.

[dboggs]

This automatic use of GetOpenFilename is an extremely valuable feature. Why can't it be standardized for IVF? When FILE='fname' in an OPEN statement does not exist, I believe that the Fortran standard states that the resulting action is implementation-dependent. Bringing up an OS feature to allow the user to specify an alternate fname is a very logical action. And with Windows, bringing up GetOpenFilename would also be very logical. So, why limit this action to Quickwin projects, let alone those specifying an obscure compiler switch for compatibility with a package 30 years old? It would be great if this worked for ALL project types, without any special switches. And it would just be icing on the cake if, when the specified FNAME does not exist, that name would be passed to GetOpenFilename as a search mask. (Or more specifically, perhaps, if fname contained any '*' or '?'). How about it?

[IanH]

If my console program (or GUI, for that matter) suddenly started popping up a GUI instead of returning an iostat error code or halting execution when it couldn't find a file, then I think I'd be moving the intel folk quite a few spots further down my xmas card list. It's easy enough for the Fortran programmer to write some code to respond in an appropriate program specific manner to the ifort iostat error code that indicates "file not found". (GetOpenFilename ain't going nowhere... the number of applications that would break would be horrendous. Have any published API's ever been deleted from Win32? There are still 16 bit API's in there that have been No-Op's for almost two decades now!)

[mecej4]

DBoggs wrote

When FILE='fname' in an OPEN statement does not exist, I believe that the Fortran standard states that the resulting action is implementation-dependent.

Where did you find text to support that belief? The book Fortran 2003 Handbook says.

9.5.1 Connecting a File to a Unit In what is probably the most common situation, the OPEN statement connects an external file to a unit. If the file does not exist, it is created.

That action is quite different from the FPS one, and users may be unpleasantly surprised if non-compliant behavior were to be the default. (Things may be less of a problem if the OPEN statement has a STATUS clause.)

[IanH]

I don't think that sentence from the F2003 handbook considers the possibility of a STATUS specifier with a value of 'OLD' (perhaps because that's not the "most common situation"?).

[Paul_Curtis]

"...(GetOpenFilename ain't going nowhere... the number of applications that would break would be horrendous. Have any published API's ever been deleted from Win32? There are still 16 bit API's in there that have been No-Op's for almost two decades now!)" I hate to be the one to break this to you, but MS simply does not care whether your old programs continue to work, they have indeed junked many APIs and will do whatever they want, including forcing existing code into obsolescence, without regard for your investment; after all they always have something better to sell you. This is not a new subject: http://www.joelonsoftware.com/articles/APIWar.html

[IanH]

There's a distinction between "encouraging you to use their latest and greatest stuff/API/subsystem or whatever" (which in part can be done by ceasing/slowing development in other areas) and actually deleting API's (such that source code can't be compiled/programs refuse to run on newer operating systems). There's plenty of evidence of the former ( e.g. Gdiplus :( ), but I'm not so sure there's much of the latter. What's more likely is that new capability present in later operating systems cannot be accessed using the older API's and ultimately the irritation associated with that forces a source change (given what's been happening with.net/WPF/Metro etal the entire Win32 API is in the firing line for that!). But deleting an API that was almost ubiquitously used in applications prior to Windows Vista is likely to result in business user mutiny.

[Anthony_Richards]

Has anyone here ever tried to use IFileOpenDialog, IFileSaveDialog etc.? They are Object-oriented methods and require knowledge and ability to handle new structures such as IShellItemArray. It's diabolical! I think you might have to learn how to use COM/AUTO programming using the Fortran Module wizard to really get into them - or for Intel to write some nice wrappers for them (hint?).

[dboggs]

Well I may have been a little inaccurate (i.e. told a white lie) when I said the response to an OPEN file=fname was implementation-dependent when fname does not exist. What I meant to say is that the response is implementation-dependent when fname cannot be opened. For example, if fname is not a valid filename, then obviously the file cannot be created, so what does the Fortran system do? In this case it would be perfectly logical to pop up GetOpenFilename. I don't think this would break existing codes. The most obvious uses for this would be to specify fname = ' ' (blank or null), or any string involving a question mark or asterisk. The blank or null case works now, but only in Quickwin (why?) and only with the archaic compiler switch (why?). And when it does work, why couldn't something like fname = '*.inp' be interpreted as a mask so that GetOpenFilename shows only *.inp files by default?

[mecej4]

In this case it would be perfectly logical to pop up GetOpenFilename.

Please keep in mind that there are other OSes than Windows, and that your programs would become non-portable if they relied upon on OS-specific routines such as GetOpenFilename. Secondly, as others have pointed out, the use of a GUI routine to cover deficiencies in a program raises new problems. How would your program with the call to GetOpenFilename run in batch mode? What if your program was part of a large task on a multi-CPU cluster that runs, say, every night? Which machine operator would get to choose a data file out of a list, and what if the file that should be read is located on a remote machine? You can, of course, build your own small file-processing package. In your Fortran code, check if the filename is blank at the OPEN statement and, if so, call the file-processing package to fetch you a non-blank filename by using a menu, a random-number generator, a list of preferred file-names, etc.

[onkelhotte]

Anthony Richards wrote:

Has anyone here ever tried to use IFileOpenDialog, IFileSaveDialog etc.? They are Object-oriented methods and require knowledge and ability to handle new structures such as IShellItemArray. It's diabolical! I think you might have to learn how to use COM/AUTO programming using the Fortran Module wizard to really get into them - or for Intel to write some nice wrappers for them (hint?).

I´m waiting for that too! I tried but failed... Markus

[dboggs]

To address mecej4 comments: 1. If the requested fname is not a valid filename, and if iostat does not exist, than a run time error will occur (file not found or file specification error). This would probably be the case on any OS. Is it better to get a RTE consistently, or to get some real help in specifying a valid filename (the old MS DOS Fortran would give a RTE error like "File name missing or blank - Unit x?" and expect me to type in a valid filename. All I'm asking for is a similar response but in a modern context. 2. If I were writing a program to run in batch mode, or on a cluster that runs every night, etc., well I simply would not use this feature. I would use an IOSTAT to trap the "error" and take appropriate action. This would be no different than it is now. Using IOSTAT to launch the GetOpenFilename routine, or even launching it with a direct call, is simply not very easty (It contains nearly 100 lines total, ~30 lines of code. The fact that a Sample Program was necessary to illustrate it's use is evidence of that. It shouldn't have to be that way. Any one who uses Matlab, for example, can see how easy it can be when the developers have done a good job implementing it in their package. But if Intel could get it to pop up simply by using the standard OPEN command, that would trump even Matlab's implementation.

[dboggs]

To address mecej4 comments: 1. If the requested fname is not a valid filename, and if iostat does not exist, than a run time error will occur (file not found or file specification error). This would probably be the case on any OS. Is it better to get a RTE consistently, or to get some real help in specifying a valid filename (the old MS DOS Fortran would give a RTE error like "File name missing or blank - Unit x?" and expect me to type in a valid filename. All I'm asking for is a similar response but in a modern context. 2. If I were writing a program to run in batch mode, or on a cluster that runs every night, etc., well I simply would not use this feature. I would use an IOSTAT to trap the "error" and take appropriate action. This would be no different than it is now. Using IOSTAT to launch the GetOpenFilename routine, or even launching it with a direct call, is simply not very easty (It contains nearly 100 lines total, ~30 lines of code. The fact that a Sample Program was necessary to illustrate it's use is evidence of that. It shouldn't have to be that way. Any one who uses Matlab, for example, can see how easy it can be when the developers have done a good job implementing it in their package. But if Intel could get it to pop up simply by using the standard OPEN command, that would trump even Matlab's implementation.