forums.silverfrost.com

[KennyT]

So far, I think there is only one sure way to overcome the problem, as far as I can tell, and that is to overwrite an existing file. So, copy a file with the correct extension into the destination folder and rename it to the target name and select it from the dialogue, then when you click "Save", the "do you want to overwrite" prompt appears and the dialogue completes successfully.

K

[JohnCampbell]

Paul,

To improve the performance of GET_FILTERED_FILE@ in Windows 7, would it be possible to provide an alternative version (say GET_WIN7_FILTERED_FILE@) as a wrapper for the API functions from the recommended Common Dialog Box Library to see if this changes the performance.
I am not sure of the functionality difference, but my understanding is we need a pop-up dialogue to select and open a file.
My present understanding of the problem is that it can eat a lot of the stack. My coding response is to limit my graphics program to about 1.3 gb when I use /DEBUG.

John

[PaulLaidler]

GET_FILTERED_FILE@ and GET_MULTIPLE_FILENAMES@ should default to the new Vista-style Open file dialog under Windows Vista and Windows 7.

This is because the internal ClearWin+ call to GetOpenFileName does not use the hook and template members of the associated OPENFILENAME structure.

This should mean that an adaptation of these routines for Window 7 should make no difference. In other words, we will need to add a dummy hook or template to the internal code in order to opt for the old style dialogs when running under Vista or Windows 7.

Please let me know if this is not the case.

[JohnCampbell]

Paul,

I'm confused again. My earlier impression of reading the MSDN documentation was we have to change to the Common Item Dialog API.
I assumed that all the problems with get_filtered_file@ locking up on Windows 7 was as this is not happening.
In past testing, if I increased the amount of memory my program uses to above 1.3gb, then it starts locking when trying to select a file.
When the new version of the compiler arrives and I can use ALLOCATE for above 2gb with /debug, then I'll try and see if this changes the problem.
I note no one has commented on this for a while, so perhaps they have found a solution?

John

[KennyT]

Hi John/Paul

The problem I was having seems to have been "reduced" (without me changing anything!). I've had some Windows Updates since my last test so perhaps MS have fixed it?

If it comes back, I'll let you know!

K

edit. This was updated a couple of months ago - might this have fixed it?

http://support.microsoft.com/kb/2640148

K

[KennyT]

It's back! In a nastier form...

If I call get_filtered_file@ to retrieve a file name, an ALLOCATE call much much later on fails. If I just hard code the filename instead of using get_filtered_file@, then the ALLOCATE doesn't fail and the program runs to completion.

So, something must be screwing something somewhere, but what and where, I have no idea. It's unlikely to be reproducible in a Noddy, as the ALLOCATE that fails has been called multiple times before it fails...

Where do I start looking?

First up, I'll try under XP32 and W7-32 and report back...

K

edit: works under XP32, not under w7-32...

K

[JohnCampbell]

Kenny,

What is the memory usage size for this program ?
I found the error was sensitive to this. I was wondering if this was the case generally ?

John

[KennyT]

Hi John,

Total memory usage for the app peaks at about 980Mb when it runs successfully, but when it fails, it's at about 750Mb. I can "stress" the otherwise successful method by adding extra "malloc" calls. If I do, it fails at about 1Gb - is this a physical limit for PCs anyway?

Some more information may put the focus back on it being a MS problem...

I have 3 ways of accessing the file browser dialogue: FTN95, Qt and C++ DLLs and they all exhibit the same problem. The C++DLL calls the "XP-style" version and the QtDLL calls the "Vista-style" so, I think the problem is that calling that dialogue at all puts a "ceiling" on the amount af memory that ALLOCATE can get at?

K

[JohnCampbell]

Kenny,

My app fails at above 1,300mb but works ok below that.
From your size estimate of 980mb, it would appear that memory size is not a reliable indicator.
I have written a subroutine to find the 16 biggest vacant memory locations. I can run it at different times, releasing all (most) the memory at each call. It could be used to map available memory around the get_filtered_files call. I'll try it around my get_filtered_file call and see if I can identify lost memory.
This problem looks like a bug in windows interface to libraries. Not sure if it's the new version or the old interface.

One day a fix will come.

John

[KennyT]

Hi John,

I'm using the "peak private bytes" stat from Process Explorer, is that what you used?

K

[KennyT]

Here's a "noddy" that illustrates the problem:

[JohnCampbell]

Paul,

There is definately a problem with get_filtered_file@, as it's use limits the amount of memory available.
My impression is that the API routine being used has the problem as it has a problem with memory leakage.

The MSDN documentation for "GetOpenFileName" indicates that:

[PaulLaidler]

John

Please see my last comment in this thread.

The Common Item Dialog approach is the default for the appropriate operating systems. This is what you get with get_filtered_file@ for the reasons stated.

Kenny

When I get back to my office I will see if I can put together an independent C program that illustrates what happens in the library.

[KennyT]

Hi John,

I think that get_filtered_file@ IS now calling the new dialogue (at least, it looks like the new one, with my "favourites" and "libraries" in the LH panel) - so I think the issue is with MS, but we need to have a C/C++ version of the "memtest" program above to prove it.

K

edit: see Paul's reply at the same time!!!!

[JohnCampbell]

If we are now using the new file open dialogue and getting the memory leakage, is it possible to revert back to the old file open dialogue and see if the problem goes away ? It would probably loose access to the new library addressing features of Windows 7, but I'm yet to take advantage of this.

I havn't tested Kenny's example above, but it may be a useful vehicle to test an old and new file open dialogue box approach.

Now that /debug works with /3gb, the memory limit might be overcome, providing an effective solution to the limited memory.

John