View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Mon Feb 01, 2021 11:46 am Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2863 Location: South Pole, Antarctica
|
Posted: Mon Feb 01, 2021 6:47 pm Post subject: |
|
|
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.
Last edited by DanRRight on Mon Feb 01, 2021 7:45 pm; edited 1 time in total |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Mon Feb 01, 2021 7:45 pm Post subject: |
|
|
Dan
I thought that you wanted to know why it was crashing. I am now sorry that I wasted my time trying to help. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2863 Location: South Pole, Antarctica
|
Posted: Mon Feb 01, 2021 7:47 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Mon Feb 01, 2021 10:22 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2863 Location: South Pole, Antarctica
|
Posted: Mon Feb 01, 2021 10:34 pm Post subject: |
|
|
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
Last edited by DanRRight on Tue Feb 02, 2021 12:50 am; edited 1 time in total |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2393 Location: Yateley, Hants, UK
|
Posted: Tue Feb 02, 2021 12:06 am Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Sat Feb 06, 2021 12:00 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2863 Location: South Pole, Antarctica
|
Posted: Tue Feb 09, 2021 6:07 am Post subject: |
|
|
Thanks, Paul. Just the info for everyone -- the %wt has to be placed right after %ps like this
Code: | i = winio@('%^`11ps%wt&',ish1, ish2, ish3, ish4, ish5, ish6,&
& ish7, ish8, ish9, ish10, ish11, &
& n_CurrSheetSettings, cbupdateSettings) |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8011 Location: Salford, UK
|
Posted: Tue Feb 09, 2021 10:19 am Post subject: |
|
|
Thanks Dan.
%wt can be placed anywhere within the winio@ sequence that creates the %ps. In other words, not within the %sh child sequences. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2863 Location: South Pole, Antarctica
|
Posted: Fri Mar 17, 2023 11:36 am Post subject: |
|
|
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! |
|
Back to top |
|
|
|