forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Error In Using ClearWin+ %PL
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1124

PostPosted: Sun Jul 14, 2019 6:20 am    Post subject: Error In Using ClearWin+ %PL Reply with quote

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, http://forums.silverfrost.com/viewtopic.php?t=4026 .

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
Code:
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.


Last edited by mecej4 on Mon Jul 15, 2019 4:07 pm; edited 5 times in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1978
Location: South Pole, Antarctica

PostPosted: Sun Jul 14, 2019 10:44 am    Post subject: Reply with quote

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 ;(
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5913
Location: Salford, UK

PostPosted: Mon Jul 15, 2019 8:33 am    Post subject: Reply with quote

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...

Code:
      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@.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1124

PostPosted: Mon Jul 15, 2019 9:24 am    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1978
Location: South Pole, Antarctica

PostPosted: Mon Jul 15, 2019 2:41 pm    Post subject: Reply with quote

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.


Last edited by DanRRight on Mon Jul 15, 2019 3:07 pm; edited 1 time in total
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1124

PostPosted: Mon Jul 15, 2019 2:55 pm    Post subject: Re: Reply with quote

DanRRight wrote:
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
Code:
      nfemax4 = nfemax
      i = winio@(chparforsimpleplot_f_e, lxpostprpicwin, lypostprpicwin, nfemax4&
         , xfe, plot_2300, plot_ion_f_e(:, 1), plot_ion_f_e(:, 2))

by
Code:
      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.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1978
Location: South Pole, Antarctica

PostPosted: Mon Jul 15, 2019 3:09 pm    Post subject: Reply with quote

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 Smile. 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 ?


Last edited by DanRRight on Mon Jul 15, 2019 6:10 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5913
Location: Salford, UK

PostPosted: Mon Jul 15, 2019 3:52 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1978
Location: South Pole, Antarctica

PostPosted: Mon Jul 15, 2019 4:09 pm    Post subject: Reply with quote

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... ;((((
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1988
Location: Yateley, Hants, UK

PostPosted: Mon Jul 15, 2019 6:23 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1978
Location: South Pole, Antarctica

PostPosted: Tue Jul 16, 2019 8:51 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5913
Location: Salford, UK

PostPosted: Tue Jul 16, 2019 9:24 am    Post subject: Reply with quote

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.

Code:
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

Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1988
Location: Yateley, Hants, UK

PostPosted: Tue Jul 16, 2019 9:54 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1978
Location: South Pole, Antarctica

PostPosted: Tue Jul 16, 2019 1:00 pm    Post subject: Reply with quote

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.
Code:
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.
Code:
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!
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 5913
Location: Salford, UK

PostPosted: Tue Jul 16, 2019 2:32 pm    Post subject: Reply with quote

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.

Code:
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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group