forums.silverfrost.com

[wahorger]

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

[wahorger]

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

[JohnCampbell]

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

[PaulLaidler]

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.

[JohnCampbell]

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