I have a program that works fine in fast compile but won't work in debug compile. In fast, all menu items for my dialog box work fine. In debug, the exit function, etc work fine but the "File Open" option leads to a grayed out box and unresponsive program.

Having trouble getting a small program to exhibit the behavior. I have a large, involved numerical program that starts off with the user choosing a data file. This big program won't let me pick a data file when compiled with FULL_DEBUG and UNDEF compiler options.

However, I built a small simple program to simply let you pick a file and then tell you what file you picked. Of course my simple program works like a charm no matter how I compile it.

Maybe there is some subtle setting somewhere that I'm getting wrong? Any stray thoughts are appreciated at this point. I've spent several hours trying to get this fixed. Frustrating since I have a "real" problem I'm trying to understand in the big program!

This has been the subject of a number of posts on this forum and elsewhere.
My best guess is that there can be problems with the Microsoft Open/Save dialog (used here by ClearWin+) when memory is at a premium.

64 bit ClearWin+ uses a different approach (than that used by 32 bit ClearWin+) when launching this dialog box. I assume that you are using a 32 bit implementation. For 64 bits, ClearWin+ opens the dialog box in a separate application hence with minimal memory use and this seems to be working well.

Problems when using 32 bits are rare but frustrating.

If we continue to get good reports about this for 64 bit applications then the longer term solution could be for us to adopt the same approach for 32 bit ClearWin+.

While the root cause is unknown, perhaps one known bug could be a culprit? If the program uses a TRIM() function in an IO statement, and FULL_DEBUG is in effect, the stack pointer can become "corrupted". Luckily the corruption is "corrected" when the sub-program/function performs a RETURN. But, if something is stored on the stack that you would need access to while the function is running, the stack pointer reference use in the code will likely be incorrect.

I was lucky, and had used the /SAVE option to eliminate using the stack for temporary variables. That said, on several other threads here, using the stack for temporary variables is certainly spoken of, and using /SAVE should eliminate that behavior at the cost of re-entrancy and additional static memory usage.

But, if the behavior is corrected, this might be your fix (temporarily).

My impression of the open problem when using get_filtered_file@ was that there was a "stack" problem (more likely memory leakage). This was overcome with /win32 by reducing the amount of memory being used. With /64 the memory limits are gone, so it is difficult to identify any problem. Not sure if it is fixed or just no longer an issue. My clearwin+ program is running much better with /64, as I have removed a lot of array size limits by increased my program managed buffers. It is working very well.

Paul,
I'm sorry it would be difficult as the short examples even in "Debug" mode always work. As the program gets bigger, it fails to respond. In "Release" mode, it works.

I could package up all the code for a demo, just to see the effect of the two compilation modes. Perhaps I might try 64 bit first.

When I removed the debug mode, the release mode failed in the processing section of the file read due to the parameters of acos and atan2 being outside the valid range or both arguments zero. But why would the debug version work on the same data file as the release mode version failure.

This is almost certainly a recurrence of the problem mentioned earlier on this thread. Since the problem only arises for you in debug mode, your solution might be to put this part of the code into a subroutine with is compiled in release mode.

As I said above, longer term, 32 bit ClearWin+ could be changed at this point to use the 64 bit ClearWin+ approach which seems to work OK.