forums.silverfrost.com

[PaulLaidler]

This failure arises because ClearWin+ is accessing the sheet control variables ish1, ish2, ish3... after the function MainSettings has gone out of scope.

You can give these variables the SAVE attribute or declare them at the top level of the module (for example).

I can't see anything about this in the documentation for %sh or %ps so I will add warnings at both places.

[DanRRight]

Paul, the point is that no matter what is saved or not saved, in scope or out of scope, variables defined or undefined, the Clearwin does not have to crash, it must be rock stable, this is not the Fortran (where crash is the hint for the errors) but just additional facility, the graphics interface. Nothing bad will happen if Clearwin will have internal bugs but still not crash. Users just will inform the developers about odd behavior but will be able still to live with the bug. At least it is much better that property sheet will for example due to its bugs not start second time you call it than it will crash and take down with it the rest of Fortran code which ran simulation for 12 hours. With bad but not crashing GUI the Fortran code will continue its run and most probably will save the data in other forms besides GUI completing the run.

Users do not have to know about sources of errors in Clearwin, who cares that ish1 have to be in scope? 99.9% of Fortran users even do not know and will never interested what in scope means. Why %PS not doing this internally? Not enough memory for additional code to handle that inside %PS? Or additional code which handles all user insane moves torturing GUI will slow down the GUI? When the user interacts with the property sheet the GUIs human-to-computer input-output with the mouse and keyboard response time is approximately 0.1 second, enough for 1000 additional internal checks for anything bad programmer might do.

My larger code still crashes with SAVE. Adding SAVE is by the way counterintuitive

Fortranish approach to GUI development - one step aside and you got crash, abort, access violation - is hell wrong, currently it's like you got tiny scratch of your finger, or piece of dust got into your eye and this immediately causes the death of the entire human.

[PaulLaidler]

Dan

I thought that you wanted to know why it was crashing. I am now sorry that I wasted my time trying to help.

[DanRRight]

We already discussed this, see above about your SAVE suggestion in 2009. This is not a workaround i was asking for. Sorry i was not clear though mentioned this several times

[PaulLaidler]

Dan

Using SAVE (or something similar) is not a work around. The designer of %ps/%sh would have stipulated this a requirement.

If I have read it correctly, the documentation is at fault and should have explained this (I can say this because I wrote that part and can take the blame).

Hopefully this issue can now be considered as closed.

[DanRRight]

Paul, For the short demo reproducer above it might be considered closed, but the demo was just the ill model for clearly different reason of %ps crash. Because i use SAVE in other code and this does not help. And i can not scale larger code down to small reproducer.

The idea i tried to articulate was to give you an example of crashing %ps which you guys would try to fix without SAVE. There was a hope that this will fix other reasons of crash. Such other reasons of crash i saw in larger code - undefined variables. Could be also other reasons.

When such conflicts appear isn't it possible to deflect the %ps from crashing and complete closing windows more amicably with warning or without but just not crashing? This was another less desirable but possible resolution behind my post

[LitusSaxonicum]

I dislike having to use SAVE because it goes against all my early experiences of Fortran where I was told repeatedly that you can't rely on a local variable holding its value after exitting a routine then re-entering it - even when the compiler was such that local variables did keep their values. It was something you just couldn't - or shouldn't - rely on.

The traditional alternative is to keep all those handles and return code variables in COMMON, or if you prefer, use MODULES to make the scope of those variables greater than just the routine where they are used.

Eddie

[PaulLaidler]

A new format %wt has been added to winio@. New DLLs that include this addition are available for users of FTN95 v8.70. Please make a request to me via a personal message.

%wt has no options. It provides a "wait" instruction when the window is being closed with the result that control is not returned to the user until after the closure has been completed.

This could prevent certain failures (for example with %ps or %lv) where ClearWin+ attempts to access user's "control variables" when they no longer exist in their code.

It would be nice if this safety factor could be added without using %wt but it is not possible to predict the resulting possible side effects on existing code that uses the ClearWin+ library.

In the case of Dan's failure, %wt provides a possible alternative to using SAVE (say) on the control variables. Using %wt "fixes" the failure for the sample provided above but the sample may not reveal all that is going wrong.

[DanRRight]

Thanks, Paul. Just the info for everyone -- the %wt has to be placed right after %ps like this

[PaulLaidler]

Thanks Dan.

%wt can be placed anywhere within the winio@ sequence that creates the %ps. In other words, not within the %sh child sequences.

[DanRRight]

This "bug of the century" crashing property sheets %ps for 15-20 years

which was discussed here many times

disappeared

when i moved to Linux and ran FTN95 from it!