Windows 7 Problems with GET_FILTERED_FILE@

Hi,

I'm having major problems with GET_FILTERED_FILE@ within Windows 7 related to the new Win7 file dialog and it's Libraries feature. The problem appears in programs compiled with any version of ftn95 including 5.40 but seems to be dependent upon the size of the Libraries (in this case my Documents library). I'm using Windows 7 x86 (but x64 is the same), Win32 compilation.

What I find is that when I launch a file open dialog initially everything seems okay, but as I navigate through my folders and libraries the right-hand pane of the file dialog starts to take a long time to refresh and eventually ends up showing no files, or hanging and not allowing folder to be selected, or incorrectly showing no entries in the library. This can happen after selecting only a couple of libraries in succession, or after a minute or two of jumping around my folders.

The demo below can be used to repeat the problem

winapp
  include <windows.ins>
  
  character(len=260):: title, file, path
  integer, parameter:: NFILTERS = 2
  character(len=32):: filternames(NFILTERS),filterspecs(NFILTERS)
  integer:: mustexist

  title = 'Open File Test'
  file = ''
  path = ''
  filternames(1) = 'Fortran Source Files'
  filterspecs(1) = '*.f90;*.f95'
  filternames(2) = 'All Files'
  filterspecs(2) = '*.*'
  mustexist = 1
  call GET_FILTERED_FILE@(title, file, path, filternames, filterspecs, NFILTERS, mustexist)
end program

When you run this it brings up a file open dialog. Clicking around fairly randomly in the left hand side between the various Libraries (Documents, Music, Pictures etc.) or Favourites locations, interspersed with double-clicking on folders and sub-folders on the right-hand side I eventually end up with the right hand side taking ages to generate, and eventually it either doesn't update when the left hand side is clicked, or clicking on a library will result in a 'the folder is empty' message. It may take 20-30 seconds of clicking around randomly, or may happen immediately.

If you drill down directly into the file system using the Computer section on the left, however, it's absolutely fine.

The problem also occurs if I call the standard file open dialog from within a VC++ DLL called from Fortran or even when using the newer IFileOpenDialog Shell interface directly. It does not happen, however, if I use the same code from within a VC++ program (ie. no ftn95 involved).

The problem is worst on my main machine with a 100gig Documents library however I've repeated it on two more machines, although it can take a bit more clicking around to make it go bad.

It's driving me nuts and I'd be really interested to know if anyone else can repeat this problem, and whether anyone can come up with a solution. I can always force the old XP-style dialog but that's not a great solution, and the code always worked in Vista which uses the same common dialog interface.

Thanks, Alan

I cannot give you a definitive answer to this problem, only an intuitive guess.

I suspect that the problem relates to the amount of memory required by the Open/Save File dialog. If this is the case then there is no easy solution.

To start off, I would see if the Task Manager gives any indication of the memory usage in this situation. If you have not used the Task Manager before then you may need to find out how to activate the relevant monitors.

Memory use is around 10MB for a debug build. It does seem to use quite a lot of handles (500 odd) and threads (30) but nothing extortionate in the grand scheme of things. Anyway, I get the same figures when running the VC++ version which doesn't exhibit the problems at all so it seems unlikely to be a memory usage issue (not a straightforward one anyway). I've also tried using the winapi GetOpenFileName directly from Fortran in case the use of a DLL has anything to do with it but the problem persists.

As I mentioned, this same issue occurs on all the three Win7 machines I've tested so it appears to be a major problem and, I'm afraid, appears to be an issue only with FTN95 (albeit probably of Microsoft's making not yours). It's also a show-stopper for anyone hoping to release their software for Win7 😦

If it helps, I've uploaded the Fortran demo source for VS 2008 to (there's also a binary in there): http://www.noisemap.ltd.uk/download/TestGetFilteredFile.zip

Also there's a rough and ready VC++ version (which works properly) at: http://www.noisemap.ltd.uk/download/TestOpenFile.zip

I'd be really interested to know if this occurs on other systems - it's so bad on my main machine that I just have to click on the Documents, then Music, then Pictures entries in the left-hand 'Libraries' section to make it all go haywire and I only have 45 top-level folders in my Documents library so I wouldn't say it's an unusual setup. It's sometimes a little better on first login but soon goes wrong.

Also, Win7 uses this new open dialog even if you use the WinAPI directly so there isn't any obvious way of reverting back to the old XP (or even NT) one. The only solution I can think of at the moment is to use a separate C++-based application to implement the file dialog and spawn this as a child process from the Fortran (yuk!!!).

Cheers, Alan

I still think it is probably a memory issue. Perhaps we need a different base address for salflibc.dll if it is clashing with one of the APIs. As you imply, it probably has nothing to do with the size or base address of the exe.

I you want me to try anything out I'm only too happy to oblige 😃

Hi, Has there been any movement on this issue ? As far as I can tell it's the only thing preventing my ClearWin applications from properly supporting Windows 7. Thanks, Alan

If you have C++ code that works OK then you can create a C++ function based on this code and compile it using the supplied C++ compiler SCC that comes with FTN95. This can be linked with your other Fortran files in order to access your function from Fortran. There are instructions in the help file on how to access C++ functions from FTN95.

At the moment I am still assuming that the built-in base address of salflibc.dll needs changing for a later release but for the moment we need to wait for any other problems with Windows 7 and salflibc.dll to be reported.

I have tried using a VC++ DLL to launch the dialog using win32 API but it's the same problem. Also tried using win api directly from ftn and it too misbehaved. The only way I can think of getting it to work is launching the dialog from another c++ based process and doing some IPC between the two !!

Out of interest have you been able to reproduce the problem? I know at least one other person has. Any idea when you'll be able to have a look at it - are we talking days, weeks?

Thanks for your help, Alan

I have had a try with your example and cannot get it to fail. It seems to navigate around quite happily. Do you know anything in particular that seems to make it happen?

It's only a problem when using the 'Libraries' section on the left hand side to select, say, your docs but you need to click around it for a bit. On my system here I click just have to click squentially through the Documents, Music, Pictures and Videos library icons, then back again and by the time I get back to Documents the right hand pane is saying 'This folder is empty' when previously it showed all my documents. On other computers it varies. If you keep clicking constantly around the different libraries and within them for a minute of two without having problems I'd say you're not seeing it. I can repeat the problem on a number of machines, including a completely fresh x64 install, and when compiled on different machines as well. Alan

I suppose I must have clicked 30 or 40 different directories in the library and favourite sections. I wonder if a funny exception happens, running under sdbg I did see it unloading and loading different DLLs as I navigated. Some DLLs seem to get closed mare than they are opened (which must be a bug)

Maybe it's related - I guess if there are lots of DLLs going in and out there may be resource issues coming into play, or worse if they're being unloaded more than once !

The problem does seem to get worse as time goes on, so if I start up the computer it takes a few more goes to get it going wrong, then after that whenever I bring up a new dialog it happens more quickly. Since I tend to stay logged in and put my machine to sleep each day it may be more noticeable, but it does still happen. Also tried admin, and plain old user accounts with the same problem.

An update - I've managed to find a machine that doesn't seem to have the problem when running the test program: it's a completely fresh install with only a few files/folders in my document library. However when I run any of my proper apps it comes back with avengance. It seems to take a little longer to go wrong with smaller exes but it's still the same basic problem. It also seems to be a little sensitive to the speed of clicking between library entries - if I go too fast it hangs for a bit before showing nothing on the right hand side.

Robert,

I've now tried it again on a new PC with a fresh install of Win 7 x64. I can't seem to repeat the problem with the small test program, but again running any of my more complex ftn apps causes a hang (including those compiled with much older ftn95s years ago that have been running on customer sites for years). Interestingly, if I leave the hung window for a minute or two it will then work for one or two folder clicks before hanging again. It does seem to be linked to the size/complexity of both the executable and the documents folder.

I'd really like to know if there is any progress on this, or the strange DLL issues you noticed. I'm coming under a certain amount of pressure to produce a release and need to decide whether to go for plan B ! I'm still looking to see if I can generate a more complex test that causes the problem all the time.

I am not really sure what to suggest as it does not happen for me. I have just had another go and cannot get it to misbehave. I browsed a couple of big source trees and there was no issues. Out of interest, do you have the 'preview' pane turned on? It has caused a few issues for me in other applications (the previewers seem to crash).

No previewers on, just plain old Win 7. I have another slightly larger app that's part of our commercial release. I can get it to reliably cause problems on several PCs, although it does seem to be related to a combination of library size and exe size/DLL complexity.

I tried to PM you a link (rather not put it up here as it includes a third part commercial lib license) but for some reason I can't send you any messages (I get an error from phpBB: 'Ran into problems sending Mail. Response: 503 Bad sequence of commands. DEBUG MODE. Line : 185 File : smtp.php')- any suggestions ?

BTW. Did anything come of Paul's suggestion on DLL base address, or you're comment on DLLs not unloading properly ?

Cheers, Alan

You can always email ftn95@silverfrost.com.

I assume this all runs happily under sdbg? sdbg is stricter about system exceptions (that are sometimes ignored).

Sorry about the delay on this - it's quite difficult to get any consistency with this problem. It hasn't gone away though, but as I mentioned before seems to be linked to the size/complexity of the Documents library plus the executable.

I have run the earlier test program in sdbg and under my profile it crashes having created the file open dialog window, but not populated it (you see the outline of the window, sometimes with the root nodes of the left hand tree present). This occurs on three different Win7 computers (x64 & x86) - it's an exception within ntdll.dll (Exception 0x000006BA... most of the time !). However, if I log on with another account it generally works okay. Doing exactly the same thing in XP works absolutely fine.

I'm not sure where to go from here if you can't repeat the problem at all - hope something similar crops up elsewhere I suppose.

Robert,

We too are finding that using Get_filtered_file@ on W7 the PC occasionally waits before presenting the windows file dialog. Once control is back with the application the next gff call may be fine, then the next gff will require a wait again.

The W7 PC can be 32 bit or 64 bit.

This is unacceptable for our users who are not sure whether the application has hung.

Are you still none the wiser what is happening ?

Have you tried running the executable in XP compatibility mode?

Right click on the executable or its shortcut and select the compatibility tab and check the appropriate box and mode. Ian