GUI should never crash by itself

Here is another example of my suggestion to make Clearwin and OpenGL crash only deliberately at the user request.

The get_opengl_mouse_state@ is crashing the 32 bit program (64bit is OK) with error message 'No OpenGL buffers are open'. Not open then not open who cares, why just not wait till it will be opened if it will be opened. It takes one pixel and just microseconds to wait till the next request will come. But no, get the crash into your face because the crash is what fortraneers always used for debugging, they don't know and don't want to know advanced tools

Meantime program should tell the user in the popup bubble about this problem. I can imagine the program on the satellite flying to stars crashing due to that minor reason and no one can restart the program or recompile.

Clearrwin and OpenGL are parts of GUI by definition involving interaction with the humans. Let's people decide to crash the external shell or not!

'Crash' implies a fault in ClearWin+ but this kind of failure is almost always due to a fault in the author's code.

As I have said a number of times before, when ClearWin+ encounters an programmer error, in most cases it has no choice but to terminate the execution.

Most errors of this kind are identified by careful testing during development and I guess that most users are happy to fix these errors one at a time during testing.

There are exceptional cases and this may be one of them but I don't know for sure.

There are over 600 error reports within ClearWin+ and (even if your request were endorsed by other users) it is not possible for us to comply.

I agree with Paul, subject to the caveat that 'crash' means something different to the original programmer and the user, and so this is a question of semantics.

One can give multiple examples of the difference. For example a depressed lunatic flies a plane into an Alp. For the passengers, and the airline, it was definitely a crash, but for the aircraft manufacturer it was fully expected that the aircraft would obey the controls, even as it was giving audible warnings that the ground was becoming awfully near!

To extend this parable further, would you like it if CW+ took the initiative? Rather like the 737 Max's MCAS, that knows better than the pilot!

So, Dan, you program for Windows. Suppose you programmed for 'console'. If you wrote to a not preconnected file without OPENing it first, what would happen? What would you expect the system to do? I suspect that you might see a FORTRAN STOP message! If you expected the user to be asked for a filename, then it would be your responsibility to handle the ERR= part of the WRITE statement. No Fortran I know of would intervene and ask for a file name without that being programmed into the source code. I can't see that CW+ is significantly different, or that it should be.

On the other hand, I sympathise. Programming at the best of times is a frustrating experience. Doing it for a living probably causes insanity in the end. And if not insanity, then programming can certainly stimulate latent Tourrette's Syndrome.

Eddie

Quoted from PaulLaidler 'Crash' implies a fault in ClearWin+ but this kind of failure is almost always due to a fault in the author's code. As I have said a number of times before, when ClearWin+ encounters an programmer error, in most cases it has no choice but to terminate the execution.

Paul, Eddie, John,

I have absolutely different experience. It does not matter if this is user error or fault if program crashes. Of course all is user fault. But all user situations is impossible to anticipate in advance. While in programming the openGL_buffers or %pl it is possible when crash situation is unavoidable to tell users if he wants to ignore that or be safe and do not proceed with the action.

What i am asking for is mostly happening in the following situations : I run for 3 days the program and permanently control how it goes opening different graphs and change the settings using Clearwin+ and OpenGL

In vast majority cases the crashes in CW+ are unnecessary and avoidable. Yes, the user will need to correct the problem after getting warning message (what i am asking for - give me the choice) about problem instead of always 99.9% crashing like today. User needs to try to continue the run even with the faulty GUI. Have you forgotten, Paul? You just made exactly what i am asking with the %pl when you tried to fix the crash of %pl with my example we discussed couple months ago. It is doing exactly what i asked for: if problem surfaced it gives user the chance

1. to cancel the run, ignore plotting of %pl or continue to run at your risk trying to plot the graph. If with some data plot crashes i would prefer not to plot it and try different data to plot. Often effing plot is not that important. But losing 3 days of run is hell important

Other cases i have seen are 2) Two captions %ca somehow may collide in complex GUI ( only one caption per window is allowed). Who cares about damn captions? Give the warning and either plot both or none, i will find that later. But instead they get you the crash

3. no openGl buffers are open like in the example above ? Who cares? Allow user to ignore that

4. no %gr was open while some function is trying to find window dimension ? Who cares. Give user the warning but allow user to continue at his own risk (and most probably nothing will happen, user will fix the error later)

5. undefined variable may happen, denormal or out of range number may happen and it will crash the GUI ? OK, i will fix that but why not to tell that and allow to ignore the number and ignore running this %rb, or %dd ? Sometime ('%il%rd', lowLim, highLim, ird) crashed the GUI because ird was set by the program below lowLim

14. and that may go on and on and on....about all the %controls about all problems in CW+ openGL-related stuff (not in the OpenGL itself, it is done by silently ignoring all the problems and never crash or report that) about all draw_characters@ or plot_line@. Let they fail, just leave the warning, that the number is undefined, or out of range, or whatever, but do not crash the GUI and with this damn GUI crash the main program!

Will repeat : the main program being bug-free as much as possible is important. But damn GUI is in vast majority cases just the third order importance visualization tool. Yes, it is good help, it is great in finding names of variables and places when you need to debug, it is amazing eye candy but it is still third order. Of course in some cases GUI error is not acceptable but let's user decide to crash 3 days of continuous running due to damn captions or openGL buffers just 5 minutes before the run completion or not. GUI must never crash.

Eddie, I prefer that if in airplane all pilots got drunk, all monitors got out of power or just the toilet handle broke ( the best metaphor for CW+) , the airplane still safely landed on autopilot. At the end in 99.99% cases Elon Mask car will safely reach the trip San Francisco-Los Angeles by itself. I am asking not about 99.99% but say 90% cases of GUI problems not to end in the crash

If you were to complain that FTN95 crashes then that means there is a fault in FTN95 that we must fix. FTN95 should never crash.

If you were to complain that FTN95 provides a fatal error report when it could soldier on then we can look into it but it is not a crash.

ClearWin+ should never crash but that is not what is being asked for, and other readers might get the impression that ClearWin+ is flaky when it is not.

So I ask, please be careful in your criticism if you want Silverfrost to do well in the market place.

You are might be right, this crashing wording should be named differently. The things we are discussing here is on another level behind the one what people may perceive with the word 'crash' more associated with no reason BSODs of DOS and first Windows era 😃. In our case we are trying to discuss the improvement of programmer's life by changing the paradigm of error reporting. This is like to change the whole programming community approach to reaction in the code flow situation. I'd call it like introducing liberalism in code-to-human interaction. We are discussing here may be a bit too heated way the things others even do not have in the plans, like trying to improve the airplane while they are still living in neanderthal era.

To be fair to Dan, suppose that his program fails to execute as intended because of an error he made that wasn't detected at compile time, but could have been, then should that be something worth rectifying or developing a solution to at SF?

My own feeling is that I am happy in the knowledge that CW+ is not tested for any but the most basic errors at compile time, and that the full development process requires 'live' testing. It probably says as much somewhere in the documentation, although my cursory examination of the start of the ClearWin+ section of FTN95.CHM didn't give me much guidance, although I did note

This DLL will only run on a Win32 platform. which perhaps is incomplete guidance.

I note Paul's recent announcements that go partway to providing a compile-time check on CW+ syntax, and that is a very positive step that needs to be encouraged.

Personally, I find that WINIO@ statements are best with few format codes, as otherwise they can get very confusing, and I think that testing routines before they are incorporated in large programs is a good idea.

Eddie

To make Clearwin to sell i suggest to SF to create say 52 and then 365 small flashy programs with photos and post them every week and then every day. May be to send them in the email like a tip of the day. Every day i open my programs in Clearwin i enjoy them very much. Then i realize that no one else have even a clue how their program could be enjoyable with this tiny addition to Fortran. Decently i am shocked all my life that neither Salford or Silverfrost ever pushed all that to the market. I asked such question here many times and my last answer was that developers do not know themselves what they created because they do not use Fortran, they use C 😃

Or, may be indeed i live in a matrix and in the city called Major Devil where all has no common sense...

Every day i open my programs in Clearwin i enjoy them very much.

To add to that, I have a program enhanced with CW+, and at first, I used to run the DOS/Command line version. I knew on the day I chose the CW+ version in preference that a new day had dawned.

The New Era began when I not only chose the CW+ version, but arrived at the point where it was rock-steady, and functioned properly in a Windows fashion.

Eddie

Another good analogy if what we discuss about crashing here is this. Remember how early browsers started to adopt the tabs? You got dozens of tabs in the browser and one of tabs freezes by some reason. Years ago that caused the whole browser to freeze or crash. Then developers started to give you the warning that the tab may slow down the browsing. Then they offered you to close the JavaScript loop casing the problems. Often this was already too late, the whole browser was slow like hell so you needed to use Task Manager to kill the process. Then they offered you to close the tab after warning and this already did not affect other tabs. Finally they solved the problem completely and one tab does not cause any problems to other tabs or browser no matter what happened in faulty tab, users just not even know what is happening under the hood. That story was mostly with the Firefox. Opera solved that long ago.

Our programs with Clearwin are like these multitab browsers, they are doing a lot of things at the same time. You start long simulation and at the same time can see the results without interruption. Or also at the same time do another task, estimate something, or analyse data. During this multitasking one minor task like plotting data may crash the plot, or solution gets to division by zero ets. You can not predict everything what may happen, this is like a small universe before you secure all outcomes will go many years. The program with Clearwin has to be crash resistant, small problem in its part, related to GUI do not have to kill the whole program

So the whole approach to resolving the conflicts which will always exist in real simulations has to evolve with the trend. But again GUI should never crash as the only way of exposing you programming error.

Today i was running the long task, all was fine, but after closing and calling the plot for second time i got the crash 'Too many links specified for %PL plot' in the line winop@('%pl[link=lines]'). Holy smoke...If Clearwin instead told me that there will be a crash i'd aborted this line and fixed the issue later (hell know what that error means and how it happened, all other dozens of WINIOPs were not affected but this one decided to kick in. May be it did not close with the closed windows or does not like my %lw, so many choices and possibilities for conflicts).

And with this GUI crash 'Run-time error 18: This routine has been entered recursively (-ANSI mode)' users and developers have to work together. The routine is user's callback, not the Clearwin's one. But Clearwin called it when the user clicked on the tab 'Next Plot' before older one finished plotting. This recursive calling might happen with the regular Fortran routines too and there such situation might indicate the true errors justifying the crash or stop into debugger, for example. But in our case of GUI the crash is not acceptable because the user just tried to see successive outputs too fast

I've been interested in this thread, mainly because it describes some things I had to handle in my code to handle the Windows environment.

And the same things had to be handled in under Visual C++ (126/32-bit Windows 95) in a previous incarnation of some of this code.

It's a Windows issue. It's not ClearWin or FTN95. But you need to be aware so you can handle the outlier conditions.

Sometimes, it takes time (or a LOT of time) for a window/dialog to free up the resources that were allocated for its creation. Using VC++, it turns out that the window could disappear (be destroyed) BEFORE the 'CLOSE' message was intercepted and processed by the defined closing routine. And, since the pointer to the data is contained in the window structure (think of %ud on the window itself), once the window was destroyed, the clean up of my data could not take place because the pointer no longer pointed to my data.

One example: With ClearWin. I allow the user to set a scale factor for their data/menu screen. If it is too large to fit the physical screen, I detect that, then start an automated process to resize the window appropriately by changing the scale factor until it is 'reasonable'. I had to allow a 1 second delay between the destruction of the window and the creation of its new counterpart. Without that delay, the program would crash. Technically, it shouldn't, but it most certainly did.

Even if you have a 'single thread' program, there are some processes/tasks that occur asynchronously to your code. And your program has to accommodate that.

Bill,

There are some really important points in your post. Like the fact that a Window closes taking with it all the information required to exit gracefully. The CW+ analogue is the WINIO@ return code, which must be SAVEd or in COMMON. Once you know that’s a problem, it then becomes the programmer’s responsibility not to let it happen.

With scaling a window, perhaps this is where FREEZE_WINDOW_CONTENTS@ (and UNFREEZE_WINDOW_CONTENTS@) might come in handy? We forget such things with the speed of modern computers.

Eddie

Hi Eddie!

Thanks for the hints.

Bill

Respect to reporting the error caused by the recursive re-entrance - may be easier would be to have the ability to switch this diagnostics off for the specific callbacks which have the chance to congest. These are all the callbacks like in

i=winio@('%^gr[...]',ix,iy, cb_mouseMove)

i=winio@('%^pl[...]',ix,iy, cb_mouseMove)

i=winio@('%^og[...]',ix,iy, cb_mouseMove)

i=winio@('%^bm[...]', cb_Plot)

i=winio@('%^bt[...]', cb_Plot)

i=winio@('%^tt[...]', cb_Plot)

etc. Before (say, a year ago) the method worked to introduce the global var!able iAmBusyProcessingSh!t and check as first statement of callback if it is 0 or 1. If it is 1 you immediately exit. If it is 0 then change it to iAmBusyProcessingSh!t=1 and stay 1 till the plot ends only becoming iAmBusyProcessingSh!t=0 at the exit of callback function.

But recently something changed and you get the program stop immediately at the entrance of callback before any executable statements succeed to handle the situation

Dan

I would need a simple working program that illustrates the failure before making any comment.

Quoted from DanRRight Today i was running the long task, all was fine, but after closing and calling the plot for second time i got the crash 'Too many links specified for %PL plot' in the line winop@('%pl[link=lines]'). Holy smoke...If Clearwin instead told me that there will be a crash i'd aborted this line and fixed the issue later (hell know what that error means and how it happened, all other dozens of WINIOPs were not affected but this one decided to kick in. May be it does not like my %lw... so many choices and possibilities for conflicts).

I finally cornered the source of this bug though in the extracted demo the bug is not reproduced. The reason was in the relatively new option

CALL winop@('%pl[gridlines]')

When i remove it the code does not crash when i close and open the same window with gfidlines again. Gridlines work perfectly in several other cases but this one crash with the error on the line

call winop@('%pl[link-none]')

If i remove this line the error moves on the next winop@ and so on.

Another observation is that winop@('%pl[gridlines]') not always has any effect (does not plot any gridlines) with this specific subprogram

UPDATE: I think found the reason for the crash. Things are that CALL winop@('%pl[gridlines]') has to be placed before i=winio@('%pl[options],.....) but i was placed it after. It appears gridline option is sensitive to this matter

To my mind the order should make no difference.

John, Look at this simple example use clrwin parameter (N=5) real*8 X(N), Y(N) Data X/1e1, 1e2, 1e3, 1e4, 1e5/ Data Y/2.2, 66, 8333, 1111, 777/

   i=winio@('%fn[Tahoma]%bf%ts&',2.3d0)
   CALL winop@('%pl[gridlines]') 
   call winop@('%pl[axes_pen=3,frame_pen=3,width=3,x_axis='X Axis Title',y_axis='Y Axis Title']') 
   i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]&', 925,700, n, X, Y) 
   i=winio@('%es') 
   end

If you place CALL winop@('%pl[gridlines]') after i=winio@('%ww%pv%pl[native... (I specially made for that %es as a separate line) the gridlines are not plotted.

   use clrwin
   parameter (N=5)
   real*8 X(N), Y(N)
   Data X/1e1, 1e2, 1e3,  1e4, 1e5/
   Data Y/2.2, 66, 8333, 1111, 777/

   i=winio@('%fn[Tahoma]%bf%ts&',2.3d0)
   call winop@('%pl[axes_pen=3,frame_pen=3,width=3,x_axis='X Axis Title',y_axis='Y Axis Title']')
   i=winio@('%ww%pv%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]&', 925,700, n, X, Y)
   CALL winop@('%pl[gridlines]')
   i=winio@('%es')
   end

In more complex situation the wrongly positioned gridlines will cause conflicts with other code and the crash

This behaviour is what I would expect. The graph is created at

%pl[native,framed,x_array,scale=log_log,N_GRAPHS=1]

so the following

so the following [quote:77b0940114]%pl[gridlines] comes too late for this graph.

You can use winop@('%pl... ) multiple times before winio@('%pl...) but you can only use the latter form once for each graph.