Silverfrost Forums

Welcome to our forums

New Video

17 Jun 2020 10:54 (Edited: 19 Jun 2020 7:39) #25681

A new video is available here...

https://www.youtube.com/watch?v=5SwhDmHNq7o

It describes a new feature of ClearWin+ that allows you to configure SimplePlot graphs (%pl).

In order to use this new feature you will need to update your DLLs and clearwin.ins. These, together with the samples used in the video can be downloaded from here...

https://www.dropbox.com/s/pb473st2vqlof5g/SimplePlot.zip?dl=0

clearwin.ins and clrwin.mod must be copied to the \Silverfrost\FTN95\Include\ folder which is a subfolder of the one that contains FTN95.exe.

p.s. With the current download, the new feature does not work in 32 bit mode.

p.p.s The above download has been deleted because of the problems identified below. Here is a new link... https://www.dropbox.com/s/55cu3lbhvwv1m14/SimplePlot.zip?dl=0

17 Jun 2020 4:50 #25691

Paul,

I did like your new video – I watched it twice!

Unfortunately I do seem to have corrupted by installation. So reinstalled and went back to a clean copy of Silverfrost FTN95 version 8.61 (February 2020), which tested OK using the following simple code:

use clrwin 
do ii = 1, 2
i = winio@('%^bt[Close]','exit')
end do
end

Then I copied across the new FTN and Plato executables, everything is OK with the above code.

Then I copied across the new debuggers, again everything is OK.

I copied across only todays DLLS and Lib files, again everything is OK. (The reason for this will become apparent below.)

Copied across todays clearwin.ins, into the include directory and again everything is OK.

Copied today’s clrwin.mod file into the include directory.

Now the 64 bit compiler is OK on the above test code, but Win32 bit complains

','exit') end do end

Then I copied across the new FTN and Plato executables, everything is OK with the above code.

Then I copied across the new debuggers, again everything is OK.

I copied across only todays DLLS and Lib files, again everything is OK. (The reason for this will become apparent below.)

Copied across todays clearwin.ins, into the include directory and again everything is OK.

Copied today’s clrwin.mod file into the include directory.

Now the 64 bit compiler is OK on the above test code, but Win32 bit complains

','exit') end do end

Then I copied across the new FTN and Plato executables, everything is OK with the above code.

Then I copied across the new debuggers, again everything is OK.

I copied across only todays DLLS and Lib files, again everything is OK. (The reason for this will become apparent below.)

Copied across todays clearwin.ins, into the include directory and again everything is OK.

Copied today’s clrwin.mod file into the include directory.

Now the 64 bit compiler is OK on the above test code, but Win32 bit complains

','exit') end do end

Then I copied across the new FTN and Plato executables, everything is OK with the above code.

Then I copied across the new debuggers, again everything is OK.

I copied across only todays DLLS and Lib files, again everything is OK. (The reason for this will become apparent below.)

Copied across todays clearwin.ins, into the include directory and again everything is OK.

Copied today’s clrwin.mod file into the include directory.

Now the 64 bit compiler is OK on the above test code, but Win32 bit complains [quote:eb9faf9b90]Desktop\pr.F95(1) : error 681 - Error while reading MODULE definition file for CLRWIN

At this stage I cannot compile your examples in today’s down load. Win32 fails with the error above, and 64 fails [quote:eb9faf9b90]The following symbols were not defined: WINOP_CHR@

I’ve go through this process a number of times now, and cannot see that I am missing anything, so this is a cry for help!

Ken

18 Jun 2020 6:46 #25692

Ken

Please check...

  1. that the DLLs are installed in the same folder as FTN95.exe.

  2. clearwin.ins and clrwin.mod are installed in the subfolder called INCLUDE that is at the same level as FTN95.exe.

  3. there are no other older DLLs on the PATH.

After that we may need to wait to see if anyone else has a problem with this update.

18 Jun 2020 10:46 #25693

Paul,

Congratulations! I also watched your video several times and the new features are excellent! Just one note - would it be possible to add option SCALE to the new options? To have graphically and numerically expressed scale in the graphics area (below the graphics) would be excellent!

However, at this moment I can confirm Ken´s observations:

When I compiled your sample (simple0.f95), always getting the following error:

https://i.postimg.cc/8PHtMPrL/PL-new-features-compiler-problems.jpg

I also checked your last advise and everything (folder, files) is as it should be, despite of it the compiler returns above mentioned error.

Martin

18 Jun 2020 10:58 #25694

I forgot to add x64 linker message:

https://i.postimg.cc/0QywgPN1/PL-new-features-linker-problems-x64.jpg

18 Jun 2020 11:26 #25695

It looks like the clrwin module will not work until you have a new FTN95. In the meantime the new feature will only be available when using 'INCLUDE <clearwin.ins>' rather than 'USE clrwin'.

Notice also my postscript above. At the moment this is 64 bit only.

I assume that you will be able to use everything in the download apart from the new clrwin.mod. In other words, you should be able to install the DLLs and use them as normal. But when testing the new feature you will need to use the new clearwin.ins for now.

18 Jun 2020 1:17 #25696

Thanks Paul, That works for me now.

18 Jun 2020 1:20 (Edited: 18 Jun 2020 3:27) #25697

I spent a few minutes trying to troubleshoot the problems with clearwin.mod. I ran into the same error as Kenneth_Smith, and decided to try building the modules using the latest source file from the 8.61 distribution. (PS: mistakenly, when I first wrote this response, I thought that I had actually included the clearwin.ins in Paul's Simpleplot.zip):

2020-06-11 17:21:16 ....A        45384         9976  clearwin.ins

using the following wrapper:

module clearwin
include 'clearwin.ins'
end module

The 8.62.1 compiler complained:

1/0142)       INTEGER*4 RGB@
*** The return type of native intrinsic functions such as RGB@ cannot be declared within a module (In include file

In the INS file, we have the declaration of RGB@ split into two separate lines: the type declaration on line 142, and the EXTERNAL declaration on line 145.

I tried the following combined declaration:

      INTEGER*4, EXTERNAL :: RGB@

and produced 32-bit and 64-bit module files. Using these module files instead of the ones in the FTN95 include directory, I found that Kenneth's test program could be compiled and built, 32-bit and 64-bit modes.

18 Jun 2020 1:37 #25698

mecej4

That's a good idea but if you use the clearwin.ins in the download then it does not contain RGB@ and it does have the new routine (WINOP_CHR@) used in the demo.

In fact I should probably upload a clrwin.mod compiled with an old FTN95.exe.

18 Jun 2020 2:36 #25699

What constitutes 'new' and 'old'?

E

18 Jun 2020 2:43 #25700

I should be grateful if someone would try the mod files from here... https://www.dropbox.com/s/01lb17y24uonv23/clrwin.zip?dl=0

If these work then I will create a new download that also works for 32 bits.

Eddie: I think that v8.61 is probably OK.

18 Jun 2020 3:28 #25701

Paul, these mod files appear to have no issue having run the test code above in 32 and 64, with USE CLRWIN. The sample code in yesterday's download is also OK for 64 bit.

18 Jun 2020 3:37 #25702

Paul, the new MOD and MOD64 files in your clrwin.zip work fine.

19 Jun 2020 7:43 #25706

Here is a link to a new download. Please make sure that clearwin.ins, clrwin.mod and clrwin.mod64 are installed into the INCLUDE folder that is a subfolder of the folder which contains FTN95.exe.

https://www.dropbox.com/s/55cu3lbhvwv1m14/SimplePlot.zip?dl=0

19 Jun 2020 10:08 #25707

Great job - thanks Paul!

It works problem free at the moment!

Martin

19 Jun 2020 10:26 #25708

Paul,

Thanks for this new addition to the library. I spent a few hours playing around with your examples and adding to them last night. I do like the idea of configuring a graph and seeing the changes instantly! The final version of the animation I posted a link to recently contains 38 plots in the %pl region and it took me a lot of time to get the final appearance I was trying to get to – I could almost certainly got there much quicker using this addition.

Your efforts are very much appreciated.

Ken

19 Jun 2020 12:37 #25709

Unfortunately, there appears to be an unwanted side effect of changing over to the new DLLs. The following code behaves differently!.

With the new DLLs, a call to SIMPLEPLOT_REDRAW@() does not trigger the %pl call back function. Consequently, the text which is drawn at 20,20 is erased when the %tt button generates a new set of data and then calls SIMPLEPLOT_REDRAW@().

Can somebody please confirm my observation.

Thanks

Ken

module test_mod
use clrwin
implicit none
integer, parameter :: dp = kind(1.d0)
integer, parameter :: n = 100
real(kind=dp) x(n), y(n)
contains

integer function run()
integer i
integer, save :: iw
i = generate_data()
call winop@('%pl[native,x_array,framed,gridlines,axes_pen=4]')
iw = winio@('%^pl&',800,600,n,x,y,pl_cb)
iw = winio@('%^tt[New data]&', new_data_cb)
iw = winio@(' ')
run = 1
end function run

integer function pl_cb()
character(len=30) cb_reason
  cb_reason = clearwin_string@('callback_reason')
  print*, cb_reason
  if (cb_reason .eq. 'PLOT_ADJUST') then
    call rotate_font@(0.d0)
    call draw_characters@('Some text',40,40,rgb@(255,0,0))
  end if
  pl_cb = 2
end function pl_cb

integer function new_data_cb()
integer i
i = generate_data()
call simpleplot_redraw@()
new_data_cb = 2
end function new_data_cb

integer function generate_data()
integer i
real(kind=dp) amp, omega
x(1) = 0.d0
do i = 2, n, 1  ; x(i) = x(i-1)+0.001d0  ; end do
omega = 2.d0*4.d0*atan(1.d0)*50.d0
amp = 10.d0*random@()
do i = 1, n, 1  ;  y(i) = amp*sin(omega*x(i))  ; end do
generate_data = 1
end function generate_data

end module test_mod

program main
use test_mod
i = run()
end program main
19 Jun 2020 1:38 #25710

I have similar observation, Ken.

When I zoom in/out the graphics (although I did not use the option [params] yet, I just wanted to test my original code with the new DLL´s), a call to SIMPLEPLOT_REDRAW@() causes that (in my case) both captions on both axes dismiss.

And then, when I just move the cursor back to the graphics area, the graphics is automatically zoomed to its extents as originally displayed without I pressed the zoom in/out buttons, what is unwanted. It needs to be investigated (the new DLL´s).

In the meantime, I had to copy back the older DLL´s to avoid these problems.

19 Jun 2020 1:40 #25711

Ken

This change was deliberate and in response to someone's (was it you?) code failing because of re-entry to the callback when calling simple_plot_redraw@.

So I blocked calling the callback from simple_plot_redraw. I think that this is probably best because users probably don't intend or expect this to happen.

There are various way around this.

  1. I could simply remove the block and let users fend for themselves.

  2. I could add code to ClearWin+ that is the equivalent of permit_another_callback@() in this context.

  3. You could change your code in order to do the drawing directly after calling simpleplot_redraw@. In this program it would be this...

    integer function new_data_cb() integer i i = generate_data() call simpleplot_redraw@() call rotate_font@(0.d0) call draw_characters@('Some text',40,40,rgb@(255,0,0)) new_data_cb = 2 end function new_data_cb

19 Jun 2020 2:46 #25714

Paul,

Yes, I think you may well have made the change in response to something else I was grumbling about a few months back (attempting to zoom into an area on the %pl using box selection – I can see that works now).

I can work around the change. It just means moving code that’s currently in the %pl call back within a “if ‘plot_adjust’ ” structure to a subroutine, and calling that subroutine instead, and also calling the same subroutine after all calls to simpleplot_redraw@().

Not a major problem I think – after getting over the initial shock of loosing all the text on my last animation.

Martin will need to do the same with his code.

Ken

PS remember to include a call to SELECT_GRAPHICS_OBJECT@ in the new subroutine.
If there’s more than one graphics region open, the current region may not be the one you want to operate on.

[color=blue:bd51d8225c]PPS it works![/color:bd51d8225c] https://youtu.be/D3y3NjXaBbg

Please login to reply.