FILE_OPENR in debug compile

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.

How can I get this to work in debug?

Line of syntax is: I = winio@ ('%mn[&File[&Open]]&', 'file_openr', File_Name, Disp_Name)

Thanks, Clay

Clarification of my jargon: Fast Compile == FTN95/WINDOWS/BINARY Debug Compile == FTN95/windows/FULL_DEBUG/UNDEF/BINARY

Can you post a small working program that demonstrates the problem. Also state which operating system you are using.

OS: Windows 10 Pro

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!

Thanks again, Clay

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

A separate application! That is How I got it to work, using a separate application and communicating with the message function. Ian

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 having problems with the file_openr standard callback in 32 bit mode. It displays the dialogue the first time but not subsequently. Using Windows 7 and win32 debug. Ian

Ian

Can you post a short sample and I will check it out.

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.

I'm hoping you have a simple reason for that. Regards Ian

Ian

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.

Paul, This problem is resolved for me by shortening the filename character size from *256 to *200. Still in debug mode. A value of *220 and above did not work; I didn't try other values between *200 & *220.

Just out of interest, does the problem occur for you if you use the GET_FILTERED_FILE@ route?

I never know which is best.

Eddie

Eddie

Is this a question for Ian?

As I recall, FILE_OPENR and GET_FILTERED_FILE@ use the same internal ClearWin+ function.

Paul,

Both of you really. If the Get_Filtered_File route didn't exhibit the same problem, that would pin things down, wouldn't it? Even if in the end they do use the same function, surely there must be some wrapper code.

Your mention that they use the same function suggests that neither is the preferred route, which leaves me pondering about feline taxidermy!

Eddie