forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

FILE_OPENR in debug compile

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
Clay



Joined: 20 Mar 2014
Posts: 12

PostPosted: Wed May 11, 2016 8:27 pm    Post subject: FILE_OPENR in debug compile Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5040
Location: Salford, UK

PostPosted: Wed May 11, 2016 8:57 pm    Post subject: Reply with quote

Can you post a small working program that demonstrates the problem.
Also state which operating system you are using.
Back to top
View user's profile Send private message
Clay



Joined: 20 Mar 2014
Posts: 12

PostPosted: Wed May 11, 2016 9:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5040
Location: Salford, UK

PostPosted: Thu May 12, 2016 8:10 am    Post subject: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 468
Location: Sunderland

PostPosted: Fri May 13, 2016 12:28 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
wahorger



Joined: 13 Oct 2014
Posts: 393
Location: Morrison, CO

PostPosted: Fri May 13, 2016 4:19 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 1833
Location: Sydney

PostPosted: Sat May 14, 2016 9:15 am    Post subject: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 468
Location: Sunderland

PostPosted: Wed Jun 15, 2016 12:33 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5040
Location: Salford, UK

PostPosted: Wed Jun 15, 2016 10:05 pm    Post subject: Reply with quote

Ian

Can you post a short sample and I will check it out.
Back to top
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 468
Location: Sunderland

PostPosted: Thu Jun 16, 2016 12:28 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5040
Location: Salford, UK

PostPosted: Thu Jun 16, 2016 2:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group