Silverfrost Forums

Welcome to our forums

Windows 7 Problems with GET_FILTERED_FILE@

29 Jun 2010 6:51 #6585

Quoted from IanLambley 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

Good suggestion, but I have just tried that and it makes no difference.

I believe that our next step is to try and use a Windows API call from our own DLL written in Delphi or something similar.

We have in excess of 2,500 customers and a large percentage of them will be on Windows 7 in the next year or so. It's disappointing that we continue to experience fundamental problems such as this.

29 Jun 2010 7:36 #6586

Good luck on the DLL front. I tried the same thing using both MFC and direct win32 api from C++ - same problem in both, although my problem is not so much the dialog start up time (although sometimes it's quite slow) - it's more the fact that selecting any of the libraries or other shortcuts in the left-hand pane causes the whole thing to hang for a few minutes, and then often doesn't actually work. Also trying to navigate the folder in the right pan doesn't work when looking at libraries. It's fine if I select the c/d/e/network shares directly and then drill down the folder hierarchy, it's just the libraries and shortcuts.

The only solution I can come up with at the moment is to run a C++-based sub-process for the dialog - not great.

FWIW it looks like the issue is related to the size/complexity of the user's folders, and also what other DLLs/libraries you're using.

14 Jul 2010 12:47 #6627

Quoted from Robert This might be worth a look: http://social.answers.microsoft.com/Forums/en-US/w7performance/thread/d997d44f-ea9d-4efb-be7b-5c39fd18f6f6

Good try, but not applicable.

This is what is happening in our situation -

Hit browse button once, twice, three times. No delay. Hit it a fourth time and it can take 30 seconds to respond with an explorer dialogue, during which wait, if you click on the main application you get a 'Program not responding' message which, if you click on the program again will crash the application.

We have tried accessing through a Windows API and we don't get any delays in Win7.

14 Jul 2010 12:59 #6629

Do you mean you never get a delay if using the API? If so, can you post the fragment so I can compare it with the library code?

19 Jul 2010 1:25 #6642

Quoted from Robert Do you mean you never get a delay if using the API? If so, can you post the fragment so I can compare it with the library code?

We're still working on this one and are trying an alternative route using a different set of API calls.

20 Jul 2010 2:38 #6648

We are using your 'Filter.f95' program and get the same problem.

!**************************************************************************** !* * !* Salford ClearWin+ Example Code * !* * !* filter.f95 - version 1.0 29/6/99 * !* * !* Example of ClearWin+ get_filtered_file routine * !* * !* only compile using FTN95 version 1.6 or higher * !* * !**************************************************************************** !* * !* Illustrates the use of the function GET_FILTERED_FILE@ to obtain a * !* filename from the user. * !* * !****************************************************************************

winapp

program filter use mswin integer :: res, select_file external select_file res = winio@('%ca[Filtered File Example]&') res = winio@('%sy[thin_border]&') res = winio@('%bg[BTNFACE]&') res = winio@('%ob[raised]&') res = winio@('This program illustrates the use of%ff&') res = winio@('the function GET_FILTERED_FILE@.%ff&') res = winio@('Use the buttons to make your choice%ff%nl&') res = winio@('Note: that under WIN32 you will get the%ff&') res = winio@('enhanced dialog box.%cb%ff%nl&') res = winio@('%`^tt[&select file]%ff&', select_file) res = winio@('%tt[&Exit]') end program filter

!**************************************************************************** !* * !* Callback function that calls get_filtered_file@ to display the standard * !* 'open file' window * !* * !****************************************************************************

integer function select_file() use mswin integer :: res, number_of_filters logical :: must_exist
character(len=128),dimension (10) :: filter_names, filters character(len=128) :: file_name,path character (len=20) :: title common / pdata / title, file_name, path, filter_names, filters,& & number_of_filters, must_exist data ifirst / 1 / if (ifirst.eq.1) then ifirst = 0

  title = 'select_file File'
  path = 'c:\\surveys\\testdata\\example survey - finished'
  file_name = 'fred.txt'

  filter_names = ' '
  filter_names(1) = 'Text files'
  filter_names(2) = 'Batch files'
  filter_names(3) = 'All files'

  filters = ' '
  filters(1) = '*.txt'
  filters(2) = '*.bat'
  filters(3) = '*.*'

  number_of_filters = 3
  must_exist = .true.

endif

write(,) ' pre ' write(,) 'title = ', title(1:leng(title)) write(,) 'file_name = ', file_name(1:leng(file_name)) write(,) 'path = ',path(1:leng(path)) write(,) 'number_of_filters = ', number_of_filters do i = 1, number_of_filters [color=red:fb13fd2d74]contd...[/color:fb13fd2d74]

20 Jul 2010 2:42 #6649

write(,) 'filter_names = ', filter_names(i)(1:leng(filter_names(i))) write(,) 'filters = ', filters(i)(1:leng(filters(i))) enddo write(,) 'must_exist = ', must_exist

res = winio@('%ca[Result]&') res = winio@('%bg[BTNFACE]&') res = winio@('You selected file '%ws'%2nl&', file_name) res = winio@('%cn%bt[OK]') select_file = 1 end function select_file

What's happening is that I hit the select file button and choose a file. I do this 3 further times and all is okay. On the fifth time it hangs for about 20 seconds before the file selection window appears.

Then I can hit select file a further 5 times and it'll hang again.

Sometimes it returns no file at all. Sometimes it never even opens the Explorer Window, simply saying I have selected filename ''

21 Jul 2010 8:36 #6657

Further to the post above regarding using Delphi in a DLL to generate the open dialog, I have found the following :-

Calling the Win32 API 'GetOpenFileName' does not cause any problems but this function was deprecated as of Windows Vista. Since windows vista, file dialogs are handled by a COM object : IFileDialog. Using IFileDialog from my DLL, I get the same erratic behavior as GET_FILTERED_FILE@. GFF@ produces the same style dialog as IFileDialog so I assume that this is what is being used on systems running Vista or later.

A search of the web reveals many people having problems with Open / Save dialogs on Win 7 across many varied applications.

6 Jun 2011 3:54 #8355

Just a quick bump to say that I'm having a similar problem under W7 32 and 64 bit OS. Symptoms as noted above with one or two more to add into the pot...

1 Stopping and starting the app sometimes fixes it. 2 It's not limited to the 'documents' library - it happens with 'ordinary' folders as well, especially when trying to 'save' a file. 3 Sometimes, repeated pressing of the 'save' button eventually works.

Anyone found a solution yet?

K

13 Jun 2011 1:31 #8405

May have a solution.

Step 1: Control Panel → Administrative Tools → Services Set WEB CLIENT to start automatically

Step 2: Start Menu: Search for 'indexing options', double click it, click 'modify' and then uncheck 'offline files'.

Reboot and try the file operation again.

Works, so far, for me.

K

27 Jun 2011 6:16 #8466

Nope, the problem has recurred...

😢

Anyone got any ideas on a fix?

K

27 Jun 2011 4:26 #8467

Some more info...

Deleting my network shared drive mount points fixes the problem (for now!).

I had two drives (L: and S:) connected to a couple of other machines on the network, so out of desperation, I deleted them and rebooted... Walah!

K

8 Nov 2011 11:18 #9194

All - have any of you folks who have been having problems with this found a definitive solution yet?

I've tried dismounting mapped shares with no success plus various other things. It works okay if I manually enter a path or go via the Computer->Drive Letter entry but anything using Libraries or Favourites hangs and eventually shows an empty folder.

Thanks, Alan

9 Nov 2011 7:36 #9197

GET_FILTERED_FILE@ is a wrapper for the API functions GetSaveFileName and GetOpenFileName. These generate the older style of dialog box (not the new Vista and Windows 7 style).

If you can use this style of dialog box successfully in some application (for example Notepad or Microsoft Word) in the contexts that are causing problems, then there must be something wrong with the way in which GET_FILTERED_FILE@ is processing the results from GetSaveFileName or GetOpenFileName.

This being the case, I would need precise details of the situations in which failure occurs.

9 Nov 2011 11:36 #9201

Paul,

I looked at MSDN for 'GetOpenFileName' and noted the following:

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

Would it be possible to provide a version of GET_FILTERED_FILE@ as a wrapper for the API functions from the recommended Common Dialog Box Library to see if this changes the performance.

As I have never been a C.. programmer (although twice trained), I'm not sure what this may involve. I have an interest in this as my move to Windows 7 is nigh.

John

10 Nov 2011 9:07 #9204

I see what I can do.

11 Nov 2011 10:24 #9210

Paul. Sorry I can't be more specific about what the causes are. I have created a very simple test app in the past which did seem more 'reliable' than my main app. The main app links to a number of additional DLLs (such as Gino Gfx) which may be having an effect. I did think it was down to the size of my documents library but that doesn't seem to be the case although a larger number of files/folders may be making matters worse.

I believe GetOpenFileName etc. do use the Vista dialogs internally if they can, and I have in the past used the common item dialog api within a C DLL and the problem still occurred - maybe have more joy.

15 Nov 2011 3:12 #9221

GET_FILTERED_FILE@ will need extending in order to provide access to the Common Item Dialog. You don't get this via GetOpenFileName and GetSaveFileName. I will add this to the wish list.

29 Nov 2011 1:42 #9314

Paul,

Since moving to Windows 7-64, this is now a real problem for me! I was working late last night and got to testing Get_Filtered_File@ and it hung. I called it quits for the night. The next morning (after rebooting) it all worked. I don't think anyone has identified the cause of this non-performance ?

We need a wrapper for the 'Common Item Dialog API' that can provide a pop-up to select a file. It doesn't have to be identical to Get_Filtered_File@, but needs to avoid the loc-up than only sometimes occurs.

Update: I have two graphics programs, both very similar. One does not exhibit the problem, the other when I select file open, hangs for a while in call Get_Filtered_File@ (varies from 10 seconds to now 10 minutes plus) then returns with a blank file_name. I can run both at the same time, indicating that what is causing the problem is more complex than I can understand. I am keeping the latest version of the one that works, in case my next edit tips it over the edge !!

John

Please login to reply.