View previous topic :: View next topic |
Author |
Message |
Clay
Joined: 20 Mar 2014 Posts: 23
|
Posted: Wed May 11, 2016 8:27 pm Post subject: 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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Wed May 11, 2016 8:57 pm Post subject: |
|
|
Can you post a small working program that demonstrates the problem.
Also state which operating system you are using. |
|
Back to top |
|
|
Clay
Joined: 20 Mar 2014 Posts: 23
|
Posted: Wed May 11, 2016 9:44 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Thu May 12, 2016 8:10 am Post subject: |
|
|
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+. |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Fri May 13, 2016 12:28 pm Post subject: |
|
|
A separate application! That is How I got it to work, using a separate application and communicating with the message function.
Ian |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri May 13, 2016 4:19 pm Post subject: |
|
|
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). |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Sat May 14, 2016 9:15 am Post subject: |
|
|
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. |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Wed Jun 15, 2016 12:33 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Wed Jun 15, 2016 10:05 pm Post subject: |
|
|
Ian
Can you post a short sample and I will check it out. |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Thu Jun 16, 2016 12:28 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Thu Jun 16, 2016 2:47 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Sat Aug 28, 2021 9:12 am Post subject: |
|
|
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. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Mon Aug 30, 2021 1:43 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Mon Aug 30, 2021 5:13 pm Post subject: |
|
|
Eddie
Is this a question for Ian?
As I recall, FILE_OPENR and GET_FILTERED_FILE@ use the same internal ClearWin+ function. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Mon Aug 30, 2021 7:06 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|