forums.silverfrost.com

[KennyT]

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

[KennyT]

Nope, the problem has recurred...



Anyone got any ideas on a fix?

K

[KennyT]

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

[acw]

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

[PaulLaidler]

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.

[JohnCampbell]

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

[PaulLaidler]

I see what I can do.

[acw]

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.

[PaulLaidler]

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.

[JohnCampbell]

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

[IanLambley]

John,
Just a thought - When you try to identify the problem with a cut down program - does it work? If so, try using the cut-down program as a stand alone spawned from the main program and communicate via files or messages. Use an always_on_top to hide the fact.
Ian
PS, I'm probably talking rubbish - again.

[Wilfried Linder]

This is really astonishing. I use get_filtered_file@ since many years in many programmes, now under Win 7 with 32 or 64 bits, and all times without any problem. I have no idea whether we can find a solution by comparing the relevant parts of our codes? I always use set_open_dialog_path@ just before calling get_filtered_file@ - could it be that this avoid problems? No idea...

Regards - Wilfried

[JohnCampbell]

I have compared the 2 programs I noted previously and now managed to get the one that was not working to work by reducing the memory footprint.
I have a large array to store information (pre ALLOCATE days). This was set to :
integer*4, parameter :: million = 1000*1000
INTEGER*4, PARAMETER :: MXSTOR = 260*million
INTEGER*4 IIBASE(MXSTOR)

The program works for 200m and 260m but fails for 300m and 360m. The memory usage (from the .map file) for 260 gives the hex address :
4cb7f000 end Linker defined

260m > 1,228 mb works on windows 7
300m > 1,381 mb fails on windows 7
360m > 1,609 mb fails on windows 7 works on XP

As I am using Windows 7_64, the next test could be to try ALLOCATE to move the large array above address 2gb and see if it still works.

I have shown that by changing the memory layout (below 2gb) that the program operation changes. Based on this I would estimate that the routines that get_filtered_file@ calls is overflowing the memory requirement and clashing with other memory usage.

( To explain my interpretation; changing the size of common changes the size of section .bss in the link map. This shifts around in memory (0-2gb) a number of system allocations that are not listed in the .map. Changeing from 1.2gb .bss to 1.6gb .bss squashes up these system allocations and probably results in the memory corruption. Not sure when these system allocations are made. Could be at link time or at run time. While modifying the size of the stack or heap might change the performance, I have never been successful using this approach. )

This is possibly why some programs work and others do not in Windows 7.

A patch may be to reduce the size of .bss. If using Win7_64 you have access to 4gb of memory. This might be achieved by using ALLOCATE and shifting large arrays into the 2gb-4gb memory area. You can test this by using l = loc (array) and declare l as integer*8 to report memory addresses above 2gb.

The best solution is to update the API calls and remove this problem.

John

ps: my memory management equivalences real*4, integer*4 and logical*4 arrays for sharing the memory. If anyone knows how to reproduce this using ALLOCATE and modules, I'd like to know.

[JohnCampbell]

Has anyone tried reducing memory to solve this problem ?
Having a memory usage report from the load map somewhere between 1,228mb and 1,381mb load map appears to solve the problem and is consistently working for me. It would be good to know if it works in other cases also.

John

[simon]

On my second call to get_filtered_file@ the routine returns immediately with a blank filename - it will not even open the dialog box.