Odd behavior

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.

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.

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.

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.

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.

Is it possible that you need more RAM?

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.

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.

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!

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.

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

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.

If you are able to send me your code then I am willing to take a look at it.

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

Bill

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

ParametersAndTypes_interfaces.ins

Apologies. I have updated the file.

These are the compile options for this routine (and 99.9% of everything in the /CHECKMATE compilation).

BINARY;CFPP;CHECKMATE;DUMP;ERROR_NUMBERS;FPP;HARDFAIL;IGNORE;
IMPLICIT_NONE;LIST;NO_COMMENT;PERSIST;SAVE;UNLIMITED_ERRORS;WIDE_SOURCE;XREF;
ZEROISE;

Here's the top part of the .MAP file after linking. Both /CHECKMATE and /RELEASE are identical as far as this is concerned..

Linker Map of f:\cmasterf95\CHECKMATE\WIN32\C-MASTER.exe Sun Aug 2 07:31:59 2020

Image base = 400000 Image align = 1000 File align = 200

Stack = 3200000 Heap = 100000

All my link steps use the default values (4 separate programs).

There seems to be a least one more file missing...

TYPE_DEPENDENT_INTERFACES.INS

I have not checked if there are others missing.

I had forgotten how deep the includes went.

I think I have them all now.

Thanks for hanging in for me!