get_filtered_file@ - MUSTEXIST =0 does not work

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

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):

      winapp
      program test 
      implicit none
      include <windows.ins> 

      integer*4      nfltrs
      character*20   fnames(2)
      character*5    fspecs(2)
      character*120  xfile,pfad

      pfad   = 'c:\\temp\'//char(0)
      xfile  = ' '
      fnames = 'Fortran files       '
      fspecs(1) = '*.for'
      fspecs(2) = '*.f95'
      nfltrs = 2

      call set_open_dialog_path@(pfad)
      call get_filtered_file@('Select file',xfile,pfad,fnames,fspecs,
     *  nfltrs,0L)

      print*,'Your selection: ',xfile
      end

Wilfried

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.

	CHARACTER*129 IMPORTABLE_TEXT_FILENAME,importable_path
	integer*4 nfilters
	parameter (nfilters = 2)
	character*20 filtername(nfilters),filterspec(nfilters)
	data filtername/'Text files','All Files'/
	data filterspec/'*.txt','*.*'/

	importable_path = 'z:\\cmatest\\catsearch\\'//char(0)

	call set_open_dialog_path@(importable_path)
	  call GET_FILTERED_FILE@(
     $	    'Catalog Search',
     $	    importable_text_filename,
     $	    importable_path,
     $	    filtername,filterspec,nfilters,0L)	  

There is one error in your code; fnames has a dimension of two; your code reads:

      fnames = 'Fortran files       ' 

and shouldn't compile.

Funny...

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.

At my PC, after clicking on the Save button, the dialog closes and returns the just typed file name as it should be.

I use the actual compiler version (7.10) plus the actual DLL (beta version).

BTW: Fnames = '...' is NOT an error - both fnames(1) and fnames(2) are filled with the same string. It is the same like initialising vectors or fields with one command, for instance:

integer*4  vector(100)

vector = 0

Wilfried

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.

      winapp
      program test 
      implicit none
      include <windows.ins> 

      integer*4      nfltrs
      character*20   fnames(2)
      character*5    fspecs(2)
      character*120  xfile,pfad

      pfad   = 'c:\\temp\'
      xfile  = ' '
      fnames = 'Fortran files       '
      fspecs(1) = '*.for'
      fspecs(2) = '*.f95'
      nfltrs = 2

      call get_filtered_file@('Select file',xfile,pfad,fnames,fspecs,
     *  nfltrs,0L)

      print*,'Your selection: ',xfile
      end

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

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.

	winapp
	subroutine GET_FILTERED_FILE_CHK(title,file,path,filternames,
     $	filterspecs,nfilters,mustexist)
	include 'windows.ins'
	character*(*) title,file,path,filternames(*),filterspecs(*)
	integer*4 nfilters,mustexist
	call GET_FILTERED_FILE@(title,file,path,filternames,
     $	filterspecs,nfilters,mustexist)
	return
	end

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.

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.

   character(260) importable_text_filename,importable_path 
   include <windows.ins>
   integer,parameter::nfilters=2
   character(20) filtername(nfilters),filterspec(nfilters) 
   data filtername /'text files','all files'/ 
   data filterspec /'*.txt','*.*'/ 
   importable_path = 'c:\\techsupport\\'
   importable_text_filename = ' '
   call set_open_dialog_path@(importable_path) 
   call get_filtered_file@('Catalog Search',importable_text_filename,importable_path,filtername,filterspec,nfilters,0)
   print*, trim(importable_text_filename)
   end

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), I2 and R4 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!

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!

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

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

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

... 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.

I may be closer to the true reason. I increased the HEAP and STACK (dramatically) from the default values, and now, everything is working, both in CheckMate and Release.

Number of files in the folder?, Probably.....

John, thanks for the reply.

I have to admit that rolling back Win7 was a 'Hail Mary' kind of thing to do. I did not do it lightly, since I know the ramifications if the process failed. I did make sure I had a good backup before I started!! Nevertheless, with no changes to the code, it ran as CheckMate, and it didn't before. So, I thought, the problem is something that an update could fix.

OK, that was not correct; so, what else do we try?

Another post on this Forum suggested that, if the directory were quite full, it was possible that a dialog could not be opened at all if there were insufficient dynamic space into which the contents could be placed. This was more likely, since my test folder contains 677 files and 12 additional folders. Not really all that many, but, maybe, ....

So, without recompiling anything, I changed the stack and heap settings for the CheckMate version to be smaller than the default. Re-linked, and it worked! Reset to default, doesn't work. Made it 3x larger, it worked. Reset to default, didn't work.

So, I am at somewhat of a loss to figure out just what is going on. Had I tried this before the Update in Place, I could have saved myself some time (and a few headaches).

This is not the only odd occurrence I have had with CheckMate. Just a couple of days ago, a section of code (user error trap) got invoked, and the code crashed without any traceback to my code. By adding tracing code, I deduced that it was my error message dialog display. This has been working for 3 months with no changes. Yet, now, problems. By removing the call to SOUND@, the problem went away. I replaced it with a call to BEEP@. I lose my cool alert sound, but it doesn't crash.

I must point out that the RELEASE version of this code never had these problems. Both had, at that time, the default heap and stack sizes. That is why I went searching for heap/stack references in the Forum. I have yet to return to linking the old SOUND@ code with my current heap/stack changes in place, but I will, at some point.

One doesn't wish to have code being tested by an independent, non-technical user and not have a good traceback to find the weaknesses/faults!!

I have been having problems with get_filtered_file@ since I moved to Windows 7 in 2011. My impression is this is a Microsoft Windows problem, where the routine that get_filtered_file@ calls, is causing the memory 'leakage/grabing' problem. At present, the only way I can overcome it is to either:

• reduce the amount of memory my graphics program uses, or
• don't use get_filtered_file@, but give the file name on the command line.

Perhaps 64-bit will overcome this, but at present, there must be a fundamental problem with get_filtered_file@. The better solution would be for get_filtered_file@ to use a different (newer) windows file opening routine. My reading about this indicates that there is a newer routine available, but probably only for Win 7 and later O/S.

Has anyone found a solution to this ?

John

ClearWin+ already uses latest Open/Save standard dialog. Not because the ClearWin+ code has changed but because the related API call defaults to the newer version.

Paul,

That is disappointing news. I was holding out hope that this problem would be fixed with that approach, but you say it has already happened. I still found this problem with code I compiled last week, when I forgot to make the arrays smaller for the version that uses get_filtered_file@.

I will again review the array sizes and see what the limit is. It is an annoying bug as the program just hangs when I try to open a file. I'm never sure what is causing the problem on the computer I am testing and how portable the solution is, given other computers will have different libraries and network drives, assuming these are the cause of the problem.

My array size approach had meant sacrificing 100's of megabytes, which is a big chunk of memory for the file opening function.

I just hoped that after one of the many Microsoft updates, the problem would go away.

John