Property sheet crash

Dan,

Not sure what crash is ?

With your code, when I go to file>settings>debug I get: 'A variable for %rd has not been given an initial value. Do you want to continue? Click No to abort.'

I select Yes and do this 5 or 6 times and get to the menu. repeating the process sees the modified values lost, which confirms my suspicions.

(not sure if this version has kpol6 listed, as kpol6 is required for my modified code.)

Also my default compile initially falied, as I have /implicit_none in ftn95.cfg but compiled as ftn95 aa2.f90 /link /check /-imp ( This suggested the problem I identified)

There may be other problems I am not identifying ?

With the modified module, the program appeared to run as required. ( so not /64 and integer(7) problems )

Dan, I replicated your crash with 11 sheets. Removing the 11th sheet from the code and the crash is eliminated. I wonder if there may perhaps be a maximum of 10 permitted sheets with the coding of the DLL? Paul may have a view on that. Ken

I compiled and linked Dan's code using FTN95 8.70 with /opt /p6. I then ran the resulting program, then clicked on File->Settings; in the new tabbed window that popped up, I clicked the radio-button Selection->PrintScreen Density, then Ok.

At this point I received an Access Violation window, 'The instruction at address 00000000 attempted to read from location 00000000'.

I then repeated all the steps above, but with /64 instead of /p6. The resulting EXE did not crash this time.

• Didn't I mention before that anyone who is not using property sheet is losing a lot and their programs most probably look like sh#t and are barely usable? ... Dan

I have never been able to make property sheets work, nor half a dozen other CW+ facilities, and have managed to work around without them. CW+ doesn't have some facilities that would be useful, and have managed to work around their absence. Windows evolution makes some things that looked great when developed, but a few years later look very dated. I've also managed to work round that.

None of the deficiencies of CW+, or of me as a programmer or application designer, stop the system being absolutely brilliant and usable to produce fully featured Windows applications - none of which need to use property sheets or for that matter, some of the other facilities.

Personally, I'd think that an application that crashes unexpectedly, thereby losing your work, isn't even barely usable, no matter how brilliant it looks up to that point. Now what was that epithet? Shot? Shut? Sheet?

Eddie

Thank you all for trying.

Updated compiler and the %PS still crashes.

Eddie, the key words were 'most probably'. Of course you can recreate similar functionality and/or adopt it to fit specific device better and even make it look more modern, but even if it crashes in some cases (i have dozens working OK and one only can crash if i forgot to call it via workaround) the %PS is still so great that i can not live without it. Besides i found bearable workarounds till it will be fixed. I'd find more if it was really needed. I'd even stress that almost no one with large codes can live without it and have manageable code. Recreation of similar functionality in house in such cases will not worth efforts. Also Microsoft and Paul slowly but steadily update look and feel of CWP. You also can do that so it will not look any boring or dated. As to crashing - Paul will fix it eventually. And will make new bugs possibly even in your workarounds 😃

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.

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.

Dan

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

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

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.

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

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

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.

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

        i = winio@('%^`11ps%wt&',ish1, ish2, ish3, ish4, ish5, ish6,&
     &  ish7, ish8, ish9, ish10, ish11,   &
     &  n_CurrSheetSettings, cbupdateSettings)

Thanks Dan.

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

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 under WINE !