forums.silverfrost.com

[wahorger]

If I set the last argument (MUSTEXIST) to zero, I cannot type in a file name and have that reflected back to the calling routine. The dialog will not return unless the file already exists.

Using MUSTEXIST=1 works just fine, and as specified in the documentation.

I want the user to be able to either select an existing file, or type in a new name.

Bill

[Wilfried Linder]

Is it this you are looking fore? At my PC it works as you wants - either select an existing file or returning the name you keyed in. (This source in FOR style):

[wahorger]

Wilfried, I essentially have the same code as you, but there are a few subtle differences. But no change in the result.

Just to be clear: When the dialog appears, I type in the name of a file that does not exist in the directory and click on the "Save" button. Nothing happens; the dialog remains open, and the file does not appear in the files list in the folder.

So, I made these changes incrementally to my code:

1. You pad the path name with char(0). That's not in the doc example, and should not be necessary. It made no difference; still can't type in a file.
2. I had only one filter specified (*.*). I added *.txt to the list. No difference in result.
3. I added in the set_open_dialog_path@ call (although it shouldn't be necessary). No difference in result.
4. Shortened my file and path variables and the caption heading. No difference.

V7.10.0 of the compiler and the as-delivered libraries.

[Wilfried Linder]

Funny...

[Wilfried Linder]

To prevent confusion: I use Windows 7 / 64bits. I have stripped my code a bit, see below. If you like, copy some fortran files into c:\temp and try to run my example.

[wahorger]

Wilfried, thanks for the quick reply. And thanks for the FTN95 lesson on array initialization. This is helpful.

Turns out, there is a bug when this function is used in the CHECKMATE version. If I compile in RELEASE, it works just as you described and works fine.

Now, why that would be an issue, I have no idea. But there is a bug.

Just for completeness in case Paul were to need to know, my compile options are:
CHECKMATE Version: /Checkmate /DEFINT_KIND 2 /silent /SAVE /ZEROISE /FPP /CFPP /WINDOWS

RELEASE Version: /DEFINT_KIND 2 /silent /SAVE /ZEROISE /FPP /CFPP /WINDOWS

[wahorger]

Another piece of information that might be helpful with this bug.

I wrote an interface routine, basically copying the same interface structure, but compiling the interface routine the same way I compile all my RELEASE code (that worked).

And, it didn't work.

[PaulLaidler]

I will log this for investigation.

In the mean time, since you are using /DEFINT_KIND 2, you especially need IMPLICIT NONE. It is generally better to let the compiler set the default INTEGER kind which is 3 (32 bit integers).

Also, as a general rule the options /SAVE, /ZEROISE and /SILENT should be avoided.

However, you may have good reasons for using these options in your program.

[PaulLaidler]

Your code worked fine for me without modification and with /checkmate.

Here is what it looked like in the end but the changes are just cosmetic.

[wahorger]

Paul, thanks for doing this. I am at a loss for the reason(s) why. Even my little Plato test program doesn't work. None of the options in Plato are checked, so standard integers, etc. all around.

However, your code works perfectly (in Plato) on my machine, both in Checkmate and Release. I'll poke around some more.

The reasons for most of the options are buried in the antiquity of the code. When it was first written (1982), I*2 and R*4 was the default, so the data files are built (generally) around that. So, the defaults are set accordingly. And that may not be helpful.

Your comments are most certainly valid.

And, thanks for the help!

[wahorger]

I have run the same code on a Windows 2000 machine, and it works perfectly in CHECKMATE, but will not run appropriately in Win7.

Obviously, it is something on my system that is preventing this, but I have no clue where to look, or what to change.

If anyone has an insight into this, please let me know. If I find out anything, I'll post it here.

As always, I feel well supported here!

[DanRRight]

To give you more clues post your entire code somewhere, we will compile and run it on Windows 7 and Windows 8. Or PM me

[wahorger]

Dan, the entire project is well over 25K LOC with 150+ routines, including a few "C" modules as well. Not really practical.

That being said, I appreciate the offer of your time. It is a generous offer, indeed!

I found something that might work, and am trying it now.

The fact that the identical, compiled code runs under Win2K, my wife's Win7 (Home), but not on my Win7 (Pro) says it is something on my end on one machine. I have had a couple of other "strange" things happen, such as very odd IOSTAT return codes, etc. that may all be related.

Again, thanks for the offer, and we'l keep in touch!
Bill

[wahorger]

This problem on my machine has been fixed.

I had to perform an "Update in place" on Windows 7. Took about 2 hours. The instructions (link below) were not quite exact, but they served to get me back and the CHECKMATE version, Save Dialog, is now working. No idea precisely what was wrong.

There are two sections to this "Update in place". The first did not do anything (that I could detect). The full "Update in place", scary though that was, did the trick.

http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/win-7-64-bit-3rd-party-apps-wont-open-windows/5dc0192c-ea7b-452a-a5ef-db82aa24fa5e

[wahorger]

... and now, the same problem is back. Will not work properly in CheckMate, works fine in Release.

Apparently, the 180+ updates that occurred as a result of "rolling back" the OS have now put whatever problem there was back in place.

Sigh.