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 

Odd behavior
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Thu Jul 30, 2020 5:14 am    Post subject: Odd behavior Reply with quote

This is the strangest thing I've seen in a while. I have not been able to duplicate it in a simple example, but am still trying. I tried posting this in ClearWin+ but it kept erroring out on me.

My application has two specific kinds of function calls to use Windows dialogs, specifically, the browse_for_folder1@ and get_filtered_file@.

When the app is started, normally the user would select a folder using a callback function that asks for a folder to be selected. Then, a file would be selected. When the file is selected, the code immediately returns (no dialog displayed) and indicates the user had cancelled the file selection. Again, no dialog is displayed, so this is some kind of default behavior.

If, however, I wait to about a count of 20-30 seconds, then select the file button, the dialog appears, and selections can proceed. I can perform as many file selections as I like.

If I then select the folder selection button again, I will have to wait another 20-30 seconds to be able to select the file.

This occurs on two different machines, and two different versions of Windows 10 (Home and Pro).

In a different application, selecting a folder never happens. No matter how long I wait, the button that invokes the browse_for_folder1@() function always returns as if the cancel button on the dialog was selected. I will save this one for later.

I have a couple of questions:
(1) Has anyone seen this behavior, and if so,
(2) How did you mitigate its effects?
(3) Is there another way to use iFileDialog that might alleviate these kinds of problems? According to the MSDN website, this is the preferred way to do these kind of operations. Whether that is actually true under Windows 10 or not, I cannot say.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Thu Jul 30, 2020 8:07 am    Post subject: Reply with quote

Is this Win32 or x64 and which version of the Silverfrost release are you using?

Someone recently had a problem with browse_for_folder and Win32 and I made a change that could fix this.

There is an alternative save/open mechanism that is provided via,

call clearwin_option@("alt_open_save")

You could try this.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Thu Jul 30, 2020 2:15 pm    Post subject: Reply with quote

Paul,
32-bit only.
Compiler V8.62.1
Libraries/DLL's dated: 4/22/2020

I'll give the alt_open_save option a go.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Thu Jul 30, 2020 2:58 pm    Post subject: Reply with quote

Paul,

I compile the code both as /CHECKMATE and /RELEASE. Only the /CHECKMATE exhibits the "delay" behavior. But there is more.

Without alt_open_save, the /CHECKMATE compilation takes about a minute for the file dialog to appear. Attempting to use the file dialog function again, and the delay occurs, about a minute long. The /RELEASE compilation experiences no delays.

With alt_open_save, the /CHECKMATE compilation takes around 30 seconds for the file dialog to appear. Attempting the file function again, it immediately appears. If I select the folder dialog, then the file dialog (a full second round), the delay for the file dialog to appear takes closer to a minute. The /RELEASE compilation experiences no delays.

As another piece of information (both compilations, alt_open_save enabled), when the dialog for the file selection comes up, the CPU utilization goes to 15%, or one full CPU's worth. The CPU utilization when the folder dialog comes up is about 0.2%, and continuously at that level.

N.B.: Upon the /CHECKMATE second round, in the Task Manager, the executable "goes away" from the display of running tasks. The total CPU utilization increases as seen previously, but the task itself is only shown in the "Users" tab.

In the tiny test code (which does not duplicate the problem), the CPU utilization for both dialogs is 0.2% (as expected).

For me, this says that if I am debugging especially file/folder interactions, I can expect the /CHECKMATE compilation to exhibit the delay, but it will do what i need it to do, eventually.

The CPU utilization is concerning, especially for the /RELEASE compilation.

And, I can't help but think that this is tied, somehow, to my inability to use the HELP facility properly.
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Thu Jul 30, 2020 3:25 pm    Post subject: Reply with quote

I saw the "Latest Versions" message, downloaded the compiler and libraries, and rebuilt everything.

There is no change in the performance of either /CHECKMATE or /RELEASE compilations.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Thu Jul 30, 2020 6:24 pm    Post subject: Reply with quote

Is it possible that you need more RAM?
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Thu Jul 30, 2020 7:32 pm    Post subject: Reply with quote

I have 32 gb of ram. I typically run at 35% usage (browser and other applications open.

The application takes about 430 mb (according to the Task Manager). Mostly, this is data.

My simple (non-failing) test program was modified to accommodate the common blocks. It consumes 331 mb, but has no issues running /CHECKMATE.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Thu Jul 30, 2020 8:23 pm    Post subject: Reply with quote

Win32 CHECKMATE uses its own memory management and this has limitations.

The basic premise is that users will use small models to run tests for undefined variables (i.e. use CHECKMATE) and then switch off CHECKMATE for large scale models.

64 bit FTN95 does not have this limitation.

For 32 bits, there may be a way to avoid the memory limitations whilst still keeping most of CHECKMATE but I would have to look into this.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Thu Jul 30, 2020 9:31 pm    Post subject: Reply with quote

Paul, thanks for looking in to this. I have a few questions, perhaps there is some relationship.

I have both FORTRAN and "C" routines. The "C" routines (compiled by SCC) are used to generate PDF's (which, for my problem, have not been started; they are dormant), and coordinate transformations (also compiled by SCC) but not linked or loaded fot this problem.

That said, is there anything "odd" that would need to be taken care of when using mixed-language programming? Is there any SCC option that should (or should not) be included?

Similarly, are there FTN95 options that should (or should not) be included because of mixed language programming?

I use a LOT of block common and initialization in BLOCK DATA subprograms. Large arrays (65000+ elements is a common size of an array).

If there is anything I should stay away from, let me know!
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Fri Jul 31, 2020 6:47 am    Post subject: Reply with quote

I don't think that these factors will be relevant to your problem.

At the moment I am assuming that the problem relates to the limited amount of memory that is available when using CHECKMATE with a Win32 application that has large arrays.

This is likely to be the case if the problem goes away when you either a) use a smaller model or b) stop using CHECKMATE.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Fri Jul 31, 2020 1:34 pm    Post subject: Reply with quote

Paul, thanks for the tip.

By changing a few PARAMETERs, I can reduce the array sizes easily. I'll try that first, later today.

Bill
Back to top
View user's profile Send private message Visit poster's website
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Fri Jul 31, 2020 4:43 pm    Post subject: Reply with quote

I changed a number of the parameters controlling the array sizes. Now, the executables (/CHECKMATE) are under 40 MB is size (down from 400+MB). But the problem still remains, and just as described in this thread.
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Fri Jul 31, 2020 6:26 pm    Post subject: Reply with quote

If you are able to send me your code then I am willing to take a look at it.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1217
Location: Morrison, CO, USA

PostPosted: Fri Jul 31, 2020 11:13 pm    Post subject: Reply with quote

Paul, while I have no problem sending you the code, there is a LOT of it, and the build I use is "hand carved". Meaning it would be time-consuming for you to re-create.

However, by commenting out huge sections of code, then enabling small blocks, I was able to trace the "offending" code to one routine. There are a few INS files along with it. The link to the package of this one routine is below. Perhaps you can perform a compile to see what gets "messed up".

It does allocate a block of memory.

If I comment out that allocate statement, there is no problem in /CHECKMATE.

If you require more code, we'll have to talk!

Bill

https://www.dropbox.com/s/r1o6z1rh0lbca86/HorgerProblem.zip?dl=0
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Sat Aug 01, 2020 7:09 am    Post subject: Reply with quote

Bill

There seems to be at least one missing file...

ParametersAndTypes_interfaces.ins
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
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