Error In Using ClearWin+ %PL

After several discussions with DanRRight by private mail regarding a suspected bug in %PL, I agreed to look at his test code, which has been crashing in a way that has eluded demonstration in a short 'reproducer'. See, for example, his thread, https://forums.silverfrost.com/Forum/Topic/3579 .

That code was about 3600 lines long, and needed to read data files as large as 82 MB in order to run. I have reduced the code to a single source file of about 300 lines, with no need for any data files (instead, the plot data are generated from simple sine/cosine expressions). The bug can be reproduced as follows.

1. Download the source file from https://www.dropbox.com/s/uyp7ju3ust7rzbl/crashpl.7z?dl=0 .

2. Using FTN95 8.4, 8.50 or 8.51, compile (32- or 64-bit) and link with any options that you wish, including /CHECKMATE, /UNDEF and /DEBUG.

3. Run the program. It will show a pop-up for a couple of seconds, and then it will show an input window with Dan's controls and file names.

4. Without changing any settings, click on 'Crashing Case'. A plot window will pop up. In the plot window, top left, you will see both 'Plot case 1' and 'Plot Case 2' selected.

5. Deselect one of the two plot cases by clicking on one of the two radio buttons. The graphs will be blanked, and you will receive a crash report (with line numbers if a debugging option was used to compile, machine addresses otherwise). The error message is 'Invalid data value supplied to %PL at address xxxxxxxx'. The line of code in our Fortran source that caused the exception in CLEARWIN64.DLL reads

   call simpleplot_redraw@()

at line 292 of the source file.

P.S.: I am not a user of the WINIO@ facility in ClearWin+, and I realise that a sequence of WINIO@ calls in the wrong order and/or with wrong arguments can cause WINIO@ to fail. In the example, however, there is only a call to redraw@ -- no arguments passed at all. If there was an 'Invalid data value supplied', was it a saved value from one of the previous WINIO@ calls, or was it generated and passed by the Clearwin library itself? If redraw@() causes previously stored WINIO@ calls to be repeated, the user should be told which call it was (and which data values were supplied) that caused the abort.

That was great job, Mecej4! Specifically after navigating among the crazy names of variables given by dehumanizer. I used such names because was sending the part of the code via open network. Typically though, having no time to write explanations to myself, in my codes i always try to give the names to variables so clear and easy to understand that anyone can get a clue what's the code is about and how to use it. Also amazing is that when i scaled down the code to such small sizes before the bug disappeared 😭

There are two main issues here.

First, the failure can be avoided by not using %lw. %lw leaves the window open when the winio@ sequence is completed. In Microsoft parlance it makes the window 'modeless' rather then 'modal'. In this code %lw is not needed. Its use in the main program causes the main program to return whilst it is intended to be still active. This use is questionable but probably OK. The use of %lw in the subroutine is incorrect because the data used by %pl to replot the curves is no longer live.

The use of %lw should be avoided when it is not needed. Occasionally what seems to be legitimate usage can be avoided by using %sc instead in order to provide a startup callback for any necessary initialisation.

Second, if %lw is retained in this code then one of the winio@ calls must be modified in two ways as follows...

      i = winio@(chparforsimpleplot_f_e, lxpostprpicwin, lypostprpicwin, nfemax&
         , xfe, plot_2300, plot_ion_f_e(1, 1), plot_ion_f_e(1, 2))

The use of a colon as an array index causes FTN95 to provide a copy of the array on the stack and this is only valid within the immediate call to winio@, not during the subsequent call to simpleplot_redraw@. Also the original code uses a local value nfemax4 as a temporary for nfemax - the number of points to be plotted. Again the address of this temporary value is only meaningful within the immediate call to winio@ and not during the subsequent call to simpleplot_redraw@.

Paul has provided a good analysis of the reason why the test codes were aborting. I have verified that the various versions that I have no longer abort if I avoid passing temporary array copies as arguments to WINIO@ (Paul's 'second issue'), but I see that users of ClearWin+ will have to remember and obey a rule that writers of console I/O Fortran programs never worry about.

Any variables (scalar, array, etc.) that are passed as arguments to WINIO@ calls must remain in scope (i.e., valid areas of memory) as long as there is a possibility that any of the output graphics (curves, axes, labels, etc.) will have to be refreshed in the future (e.g., by a call to SimplePlot_Redraw@). If any such arguments are local variables in a subprogram, no redrawing of the same windows should be performed in any independent subprogram, where these variables would likely be out of scope. In the example code, the arrays being plotted were declared in a module used in the subprograms, so they stayed in scope. As Paul pointed out, some scalar arguments were local variables, and that may have caused some of the crashes.

Dan will have to inspect his entire production code for instances of stale arguments being passed to ClearWin+, and he will probably not get much help from the compiler in catching such instances (except from post-crash tracebacks).

Thanks mecej4 and Paul. So what have you specifically changed to make the crashing case to work in respond to radiobuttons? I took quick look and tried the changes you have suggested (changed : to 1 and used nfemax as number of point), the case does not crash, but it still does not work as intended demonstrated by previous Working Case.

The %lw typically has to be present because in normal well fledged GUI there are many windows which have to be opened at the same time.

Quoted from DanRRight So what have you specifically changed to make the crashing case work in respond on radiobuttons?

In the abridged version that I posted on DropBox (see link in OP), replace

      nfemax4 = nfemax
      i = winio@(chparforsimpleplot_f_e, lxpostprpicwin, lypostprpicwin, nfemax4&
         , xfe, plot_2300, plot_ion_f_e(:, 1), plot_ion_f_e(:, 2))

by

      i = winio@(chparforsimpleplot_f_e, lxpostprpicwin, lypostprpicwin, nfemax&
         , xfe, plot_2300, plot_ion_f_e(1, 1), plot_ion_f_e(1, 2))

For the issues regarding why the 'crashing case' does not behave in the same way as your 'working case', I cannot help. I had observed several GUI issues with the program while reducing the size of your code, but ignored them; I assumed that those were in your court for resolution. For example, if I changed the font size of the text in the plot using your GUI and selected 'OK', the graph got blanked, following which I was back in the previous window and needed to click on 'crashing case' to have the plot redrawn, which then happened with the changed font size.

This is exactly what i have done. Does it work with you and clicking on radiobuttons makes plots ON and OFF?

UPDATE. Ah, ok, i do not see this functionality was programmed into. OK this case seems is closed. Again thanks to both of you. Searching Amazon now for the whiskey present 😃. One of two darkest spots i experienced in Clearwin is now gone. May be good would be to mention that forbidden usage in the Help to %PL for other users not to lose a year.

In summary, can we conclude that the colon and local variable for number of points were the reason of crash? But why SAVE of all variables i also tried to use in declaration did not help in this case ?

Dan

Yes these two things are sufficient to explain the failure. The colon means that you are passing an array section and as a result FTN95 creates a local copy of the array for you. Also the number points to plot was originally a local variable.

This sample provides for at least two windows that are simultaneously open whilst at the same time does not need to use %lw at all. It is quite possible that the cases where you are forced to use %lw are significantly fewer than you think. In particular using %sc provides a means of initialising a window and this is often an alternative to using %lw that avoids its pitfalls.

Just a note where %lw is a must: there are numerous temporal windows with different warnings and infos which dissolve or disappear by themselves after some period of time or after just hovering the mouse if you use %sv.

And the best example of numerous opened windows is trading software all have seen on multiple monitors of Wall Street traders. There 100s of windows with stock charts are opened simultaneously and filled with the data in real time. So the %lw usage typically increases sometimes to enormous magnitude as people learn Clearwin.

So now thing does not crash and works in demo but devilry does not go off easily. I still have problem with the same functionality in my larger code - damn thing still does not react on radiobuttons... OMG... 😭(((

Although Paul has said in the past that ClearWin+ is simply a wrapper for Windows functionality, it is, sometimes very clearly, rather more than just that. The consequences are that if you wish to use the Windows functionality in a way that Microsoft did not envisage and support, then you may well meet some insurmountable problems. Moreover, the same applies with the way that SilverFrost has implemented ClearWin+ ... there are assumptions built into the code. The paradigm of having multiple windows open in a given application, which is what Dan must be doing to have used %lw multiple times, is one that I find quite awkward both to program and to use. I have a slide scanner with software that does so and the problem I face with it (because I only use it occasionally) is that when I have closed some windows down, I don’t always know how to restart them. On the other hand, windows that only contain tools do allow you to position them wherever you like and that is convenient as the CW+ toolbar locations are rather static. I also find that I don’t have the mental agility to cope with too many windows open at the same time as inevitably I close one that I want to minimise. I also have some (adult) users that are less than 1/3 of my age, and they don’t seem to have the mental agility either, so maybe it isn’t just senility. The use of multiple windows active at the same time as one of those things that you can do but don’t have to. When I started with CW+, I was putting a minimise icon with %mi on all my dialog boxes – you can, but it isn’t the ‘norm’. That meant that they could be seen on the taskbar (not a problem in very old Windows versions without one) and also but worse, that you got the system menu whether you liked it or not. The point is that the norm is not to. Things like this boil down to whether you use FTN95/CW+ ‘your way’ (as the front page of the Silverfrost website tells you that you can), or stick to the general conventions in the way that Windows apps normally do. There is a problem even if you do conform, and that is that Microsoft’s flagship Office apps don’t conform, doing things that are hard to impossible to emulate with CW+, or even breaking their own rules. In the former case we have the ‘ribbon’, and in the latter, crowding the caption bar with ‘extras’. Dan adduces the multiple Windows that are all open and update in real time as on the trading floor of a Stock Exchange. Who is to say that each Window is the child of a single parent, and not a separate application? ClearWin+ has the tools to let some applications launch others, and to pass messages containing data and commands between them. It also has the ability to share memory. No doubt this is not so convenient as to have all functionality wrapped up in the same application, but it does have the benefit that each component can be compiled and tested separately, which may have some benefits if one is swamped by the complexity of the whole system when debugging. Dan’s other complaint, about radio buttons not acting as command buttons, is another example of a reinvention of what they are supposed to do. We discussed this in another post some time ago. I found Paul’s explanations a model of clarity and helpful, but it does point out that there is seemingly no way to find out what is causing the problem without recourse to this forum: simply reading the documentation is not enough. Incidentally, Dan mentions %sv – one can of course also make a Window volatile using %ww. Presumably, using %sv the window reappears after a period of inactivity, whereas with %ww[volatile] it needs to be reinvoked. Eddie

If design allowed after opening multiple windows with graphics, text, clearwin controls and opengl %og and native %pl on them update them directionally with simpleplot_update@, users would more actively used multiwindows. Specifically this is true with %pl because it is easy to create the plot. The %gr allows directional update. I think %og like %pl does not.

The following program illustrates the point that you can have more than one window open without using %lw. In this sample the secondary window is said to be 'modal'.

You only need %lw (or something equivalent to it) when the user is allowed to interact with the primary window without closing the secondary window.

This is illustrated in a simple text editor such as Notepad where the 'Find' dialog can be left open whilst continuing to edit the text. Such a window is said to be 'modeless'.

Modeless dialogs are more difficult to program and should be avoided where possible.

module mymod
integer val
contains
 integer function cb()
  integer iw,winio@
  iw = winio@('%ca[Data input]&')
  iw = winio@('Input: %rd&', val)
  iw = winio@('%2nl%cn%bt[OK]')
  cb = 1
 end function
end module

program main
use mymod
integer iw,winio@
val = 0
iw = winio@('%ca[Main Window]&')
iw = winio@('%nl%cnData: %`rd&', val)
iw = winio@('%2nl%cn&')
iw = winio@('%^bt[Settings]',cb)
end

Dan,

I don't always understand your point precisely, because of the way you (don't) use the definite and indefinite articles, or possessive pronouns etc. Do you mean your design, or* SF's design* of CW+?

In any case, lest I was inadequately clear, you can meet all your objectives by having separate applications for your %og and %pl windows.

You can start them with start_pprocess@. When you want them to update, send them a Windows message using send_text_message@, which you can read in the separate application using clearwin_string@('MESSAGE_TEXT') (and reply to it if you like with reply_to_text_message@) You set the message handling callback with %rm.

If the data to transfer is too long for a message, put it in a file, and get the remote window app to read the file. If it is soon after creation, the read will come from the disk buffer, and be quick.

As I said you can used shared memory instead, but I have never done that.

Say you wanted to start 2 %og windows using start_pprocess@ you can use the same application twice, but in the parameter list tell it what class name to use with %nc when setting up the window.

Also, if you have a problem updating a window, simply close it and re-open it with the new data. I'm presuming you run on a fast computer1

Eddie

Paul, My point was not in opening more windows, but in keeping all of them operational. Of course anyone can open any amount of windows. Here is your code where i only added few radiobuttons just to pretend that Main window may have decent amount of action which may go in realtime. Click on radiobutton - they work.

module mymod 
integer val 
contains 
 integer function cb() 
  integer iw,winio@ 
  iw = winio@('%ww[independent]%es&') 
  iw = winio@('%ca[Data input]&') 
  iw = winio@('Input: %rd&', val) 
  iw = winio@('%2nl%cn%bt[OK]') 
  cb = 1 
 end function 
end module 

program main 
use mymod 
integer iw,winio@ 
val = 0
irb1=1; irb2=1; irb3=1; irb4=1 
iw = winio@('%ww[independent]%es&') 
iw = winio@('%ca[Main Window]&') 
iw = winio@('%nl%cnData: %`rd%ff&', val) 
iw = winio@('%rb[Am i locked out?]%ff&', irb1) 
iw = winio@('%rb[Am i locked out?]%ff&', irb2) 
iw = winio@('%rb[Am i locked out?]%ff&', irb3) 
iw = winio@('%rb[Am i locked out?]%ff&', irb4) 
iw = winio@('%gr[color=#ecccf4]%ff&', 300,200) 
iw = winio@('%2nl%cn&') 
iw = winio@('%^bt[More Settings]',cb) 

end 

Now click on More Settings and then try clicking on radiobuttons. Ooops, you lock yourself off ! You can not control these radiobuttons and can not do anything till you close this window.

Another code adds %lw.

module mymod 
integer val 
contains 
 integer function cb() 
  integer iw,winio@ 
  iw = winio@('%ww%es&') 
  iw = winio@('%ca[Data input]&') 
  iw = winio@('Input: %rd&', val) 
  iw = winio@('%2nl%cn%bt[OK]&') 
  iw = winio@('%lw[owned]',ilw) 
  cb = 1 
 end function 
end module 

program main 
use mymod 
integer iw,winio@ 
val = 0
irb1=0; irb2=0; irb3=0; irb4=0 
iw = winio@('%ww%es&') 
iw = winio@('%ca[Main Window]&') 
iw = winio@('%nl%cnData: %`rd%ff&', val) 
iw = winio@('%rb[Am i locked out?]%ff&', irb1) 
iw = winio@('%rb[Am i locked out?]%ff&', irb2) 
iw = winio@('%rb[Am i locked out?]%ff&', irb3) 
iw = winio@('%rb[Am i locked out?]%ff&', irb4) 
iw = winio@('%gr[color=#ecccf4]%ff&', 300,200) 
iw = winio@('%2nl%cn&') 
iw = winio@('%^bt[More Settings]',cb) 
end 

Try to click on radiobuttons while More Settings are open - they work. Without %lw your Main window becomes like a car with driver which fell asleep

Of course there may exist recent additions to Clearwin which i did not know. Like %ww[independent] which i have thought may add this functionality. I added it here and it does not do anything in this post context.

Eddie, I used start_pprocess@ extensively in the past and i tell you : i hate it! Sometimes it worked sometimes not. Now it works OK but much easier to work without middleman called Windows Command Prompt. And i agree my not approved dialect of ClrearWin+English only becomes worse getting probably on nerves of all natives. This is a result of living in the country where all talk like me or worse and somehow understand each other. I have seen amazing examples how 2 y.o. international kids played together while originally had no English at all. And totally amazing that their zero-English mothers even became friends!

The locking out has something to do with using %ww[independent] twice.

Certainly you can use %lw if you are particularly careful.

Here is a simple extension of our sample.

module mymod 
implicit none
integer val,isClosed 
contains 
 integer function closing()
   isClosed = 1
   closing = 0
 end function
 integer function cb() 
  integer iw,ilw,winio@
  if(isClosed == 0)then 
    cb = 0
  else
    iw = winio@('%ww[toolwindow]&')
    iw = winio@('%ca[Data input]&') 
    iw = winio@('Input: %rd&', val) 
    iw = winio@('%2nl%cn%bt[Close]&') 
    iw = winio@('%lw[owned]&',ilw)
    iw = winio@('%es&')
    iw = winio@('%cc', closing) 
    isClosed = 0
    cb = 1 
  endif  
 end function 
end module 

program main 
use mymod 
implicit none
integer irb1,irb2,irb3,irb4,iw,winio@ 
val = 0 
isClosed = 1
irb1=0; irb2=0; irb3=0; irb4=0 
iw = winio@('%ww%es&') 
iw = winio@('%ca[Main Window]&') 
iw = winio@('%nl%cnData: %`rd%ff&', val) 
iw = winio@('%rb[Am i locked out?]%ff&', irb1) 
iw = winio@('%rb[Am i locked out?]%ff&', irb2) 
iw = winio@('%rb[Am i locked out?]%ff&', irb3) 
iw = winio@('%rb[Am i locked out?]%ff&', irb4) 
iw = winio@('%gr[color=#ecccf4]%ff&', 300,200) 
iw = winio@('%2nl%cn&') 
iw = winio@('%~^bt[More Settings]',isClosed,cb) 
end

Paul, Do you still use %lw here ? If take it off things still do work same way like in your first example

Or as often happens i missed the point in the hurry and you advertise using 'toolwindow' option?

Eddie, To be more clear, if i could, or if %pl had 3D options based on OpenGL, i'd use many (tens!) of OpenGL windows, like i use many 2D XY and surface plots currently (but that is my own graphics routines based on %gr and Clearwin allows switching content data stream on specific graphics window)

Yes. The latest sample now uses %lw in the secondary window so that both windows can be open and either window can have the focus.

I'd also ask to add the check of validity of operations like you have just added in %PL to prevent crashes and give user an option to ignore the execution or continue and crash but now into openGL function swap_opengl_buffers() in 64bit version if Silverfrost has control on that. Sometimes it crashing