forums.silverfrost.com

[DietmarSiepmann]

We try to save a file from within a GUI application built with Ftn95/Winio making use of the File Dialog.

In most cases this works, however, sometimes the dialog stays open and does not save the file as expected. This happens if we try to enter a file name of a non existing file to the File Dialog. The file name is not accepted when we click the button 'Speichern' in the picture mentioned below (which should make the file be saved).

We use FTN95 version 7.10 and Windows 7, 64 Bit.

A screenshot of the File Dialog is contained in the picture

http://www11.pic-upload.de/01.07.15/zflqgs4jqqh.jpg

If we perform the same action on an existing file, everything works fine.

We would apreciate any help and advice.

Regards,
Dietmar

[Wilfried Linder]

I think that you use something like

[LitusSaxonicum]

I live and learn. I never use %eb boxes, so I hadn't come across the EDIT_FILE ... callbacks, just the FILE_OPENR and FILE_OPENW ones.

At first, I found it confusing that the callbacks simply interrogated the user for the file name, and the rest of the work is done with OPEN and READ or WRITE statements.

It would be interesting to see what Dietmar uses with a few line of source code.

Eddie

[dgurok]

We use the subroutine "GET_FILTERED_FILE@" for our save file dialog with parameter MUSTEXIST=0 . As already mentioned in most cases the save dialog works fine but in some cases not. When the error occurs we can only close the dialog if we select an existing file or the abort button.

[LitusSaxonicum]

I find these sort of intermittent errors the most difficult to fix.

Is there a chance that MUSTEXIST can get changed somehow in your program?

I sometimes find that things are improved by the use of SAVE. Most of the advice on the web is not to use SAVE, because you should not rely on local variables keeping their values between invocations of a subroutine - which has always been the case in the 46 years I have programmed Fortran, but (and this is a guess really) sometimes when a subprogram closes the route to the return code from a WINIO@ call seems to get lost too. I found awful unpredictability in an application where I had divided the WINIO@ calls across a few subroutines until I used SAVE.

Anyway, it may be worth a try, and I'd be interested to see if it was helpful.

Eddie

[dgurok]

We have built our application with option undef and it seems that our application works fine. When we execute the call �GET_FILTERED_FILE@� we have no influence what happens then.

We may suspect a memory problem. It could be based on our application (how it is built, e.g. using large arrays on common blocks) or the computer environment but the strange think is that the behavior occurs on computers
with different sizes of ram (2, 4, 8, 16) using Windows 7 32/64 Bit. Win8 not testet.

We have the idea to change our large arrays from common blocks into allocable arrays. Maybe it helps.

[wahorger]

I also have had this same problem with GET_FILTERED_FILE@. In my case, it would work SOMETIMES in /CHECKMATE, and always in /RELEASE.

There was some tie in with other ClearWin+ components I was using (specifically, a window that exclusively used Text Array). When I reworked the code to not create/destroy the window every time the user input information, this SAVE problem went away, as well as occasional crashes at random times, all associated with the TextArray. Since I made the change, there have been no crashes. However, I implemented a Status Bar and discovered that if I updated the control too quickly, it would stop working. I implemented a delya based both on time and displayed value, and it worked pretty well, with only a very rare occurrence of hanging up.

There is another thread on this forum what discusses what I found in a bit more detail regarding GET_FILTERED_FILE@.

Here is the link: http://forums.silverfrost.com/viewtopic.php?t=3018&highlight=

[LitusSaxonicum]

If /UNDEF fixes the problem, then it has to do with the use of an undefined variable lies at the root of it. Using ALLOCATABLE arrays won't fix it.

[wahorger]

Eddie,

In my case, the use of /UNDEF wasn't the issue. I made sure that the variables were completely initialized, even if they were designated as an output. I also segregated the GET_FILE_FILTERED@ call in a separate file, compiled as a RELEASE version. I could always get one of the instances to fail, but the other 2 instances would sometimes fail, sometimes not. And, it depended on the computer it was run on. Totally inconsistent.

The "upgrade in place" (re: my other posting) made things "different", meaning the original problem seemed to go away, but came back later. The only thing that has worked was the recoding of the user interface to never destroy the user input window.

I now compile my entire system twice, one with /CHECKMATE, the other not. So far (after the coding change mentioned above), they operate the same way.

Bill

[dgurok]

Our problem was not solved with using option /undef, /checkmate or "/release". We wanted to be sure that we do not get some errors during run time. The application works with option /undef, /checkmate etc. fine but the problem with save file dialog still exist.

We have the same case observed. When we reduce our internal parameters which handle our model sizes then it seems that the save file dialog works normal. In general our main application uses ~600 MB memory up to 1,2 GB and more depending on model sizes needed.

[LitusSaxonicum]

... but have you tried /SAVE? This will both reduce stack usage AND preserve the return path to variables that go out of scope when the subprogram in which they are local is closed.

[wahorger]

Oh yeah, all that.

For the DEBUG version:
/Checkmate /persist /DEFINT_KIND 2 /silent /SAVE /ZEROISE /FPP /CFPP /WINDOWS /implicit_none /no_quit

For the RELEASE version:
/persist /DEFINT_KIND 2 /silent /SAVE /ZEROISE /FPP /CFPP /WINDOWS

The differences are that I use the DEBUG compile (/CHECKMATE) to catch the undeclared variables (/implicit_none) and /no_quit to allow all the errors to show when things have gone horribly wrong!

The /persist is to prevent the CMD file from closing before I've had a chance to view the errors in the source.

I like the wide variety of options available for the compile!

Bill

[dgurok]

We compile with option /SAVE and /ZEROISE set. For historical reasons we can't get rid of option /SAVE .

[PaulLaidler]

There is a long history of occasional intermittent problems with the Microsoft function that is called by GET_FILTERED_FILE@.

We are testing an alternative approach that will be used initially in the 64 bit version of ClearWin+. If it proves to be more robust then we could use it in the 32 bit version as well.

[PaulLaidler]

Yes. The occasional and random problems also occur when using other compilers. There may be issues relating to memory usage and/or connectivity problems to remote folders.