Native %pl

clear_screen@ is not working with the native %pl and it's not obvious why. I will make a note of this.

Paul, Sorry, I gave wrong name

The draw_rectangle@ and draw_filled_rectangle@ seems worked before in 32 bits but now do not

Dan

You need to include CLEARWIN.INS for these routines or use the equivalent standard module.

While it has not found its way into the enhancement file or the help file, the new %pl option in FTN95 version 8.20

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

works just fine for me. Thanks Paul & Co, this makes the output from %pl look so much better.

John

There are no options with [grid_lines]. It's just one shade of grey and a single pixel width.

The alternative to 'INCLUDE <clearwin.ins>' is 'USE clrwin'.

Quoted from PaulLaidler Dan

You need to include CLEARWIN.INS for these routines or use the equivalent standard module.

Paul,

After installing latest 8.20

1. Unfortunately 'include <clearwin.ins>' still does not work with 8.20, giving the error

   Run-time Error *** Error 29, Call to missing routine : _MODSURFPLOTDEMO!RGB# at 0x00401271.

   00401000 MODSURFPLOTDEMO!CB_SURFPLOT_PLOTTING [+0276] [recur= 1]

   004013b0 main [+03a9]

see mine or John's latest codes from page 12 of this thread

2. But that was an unimportant bug probably, if nothing else was influenced we can live without rectangles. But clearly it's time to fix this single line fortran code which with the new beautiful gridlines just cries with its hell amount of bugs per line of code which need to be fixed. I see 5 bugs and defects. Who sees more?

   use clrwin parameter (N=5) real8 :: x(5) = (/1E1, 1E2, 1E3, 1E4, 1E5/) real8 :: Y(5) = (/2.2, 66., 3333., 1111., 777./)

   i=winio@('%pv%pl[native,framed,gridlines,x_array,y_axis='Y_year',scale=log_log,N_GRAPHS=1]%ff%cn%bt[OK]%es',625,500,n,X,Y)

   end

3. Linear scale numbering also sometimes explodes in unimaginable insanity I stretched the Surfplot on full screen of my 4k monitor. The code is the one we with John discussed on Page12 but changed tiny bit so that the plotted X data maximum is 9 and Y is 80. When posting I zoomed down image to the smaller size to see it in this forum but the problem or two with X axis numbering are clear.

John: I don't have a date for the release of the personal edition 8.2.

Dan: The linker can't find the RGB@ in the module MODSURFPLOTDEMO. It is within that module or CB_SURFPLOT_PLOTTING that you need to say where RGB@ is to be found. As to the 5 bugs, I guess that you want me to locate the code and identify the 'bugs' in the output for myself.

Paul,

I am not sure what RGB@ is implemented as. I thought it would be an in-line or intrinsic function, but if I use the following, I get errors. INTEGER,PARAMETER :: red = rgb@(255,0,0) INTEGER,PARAMETER :: green = rgb@(0,255,0) INTEGER,PARAMETER :: blue = rgb@(0,0,255)

Could this be allowed ?

Also, why 'The linker can't find the RGB@'

John

Quoted from John-Silver Dan, just realised in the plot at the top of p. 12 the last label on X-axis (60) wìshould be 600 ! I think reading what you wrote that was done with simpleplot %pl right ?

John, Yes, this was bug with older Simpleplot %pl. The hack fix for that is simple: just take last X numbers not 599 or 600 but 601 or 610 with x_max=610 if it exists (I forgot if x_max exists for X axis, for the Y axis the y_max definitely exist) or with just adding fake number to the data at the end of X-Y array

With my single line example I found one minor problem more. But it pushed me to lose some time in photoshop for a dozen of plots

Paul, Sorry, I did not understand both your answer and question. In the code on page 12 the offending line 'include <clearwin.ins>' is marked as causing problems. And JohnCampbell confirmed this

As to question about 5 bugs the code is there and John-Silver named almost all of defects (I thought may be I am blinded with devilry 😃 so I asked others to confirm if they also see the bugs and defects)

John Campbell

RGB@ is implemented in salflibc.dll and clearwin64.dll so you won't be able to use it in an initialisation statement.

I normally just declare it as

INTEGER,EXTERNAL::RGB@

John, No, Silicondale had similar problem, and he mentioned the reference on Web Standard which also always was RGB not BGR.

I'm now not using rgb@ for this but coding the colours directly into the standard hex format #rrggbb thus:

        write(plxy,'(a,3z2.2,a)')
     1         '%pl[colour=#', ir(i),ig(i),ib(i), ',x_array]'  

as I think it was Paul who suggested - and it works just fine. Contour plot of a hill as an example -

• Steve

This is to correct an earlier post in this thread relating to the [colour=#rrggbb] option that can be used in %gr, %pl and other format codes.

You can set the %pl line colour via

call winopt@('%pl[colour=#rrggbb]')

where rr is the hex value for the red component etc.

For example:

call winopt@('%pl[colour=#FF0000]')

for red etc.

        write(str,'(a,z6.6,a)') '%pl[colour=#', RGB@(255,0,0), ']'
        print*, str

produces the output

%pl[colour=#0000FF]

which is the wrong order so it is better to use z2.2 for each component in turn.

No it is not a bug. It is a correction to a previous post in this thread where I gave incorrect information. Both #rrggbb and RGB@ work correctly. My post was incorrect.

Hi John. You take today's star prize. The only person in 20 years who understood 'silicondale'. 😄 😄 😄

• Steve

John Campbell

I have had a look at your adaptation of Dan's 'surfplot program demo'.

As you have noted, the displayed results are not the same for %gr and %pl.

1. %pl always uses the Microsoft GDI+ library. If [smooth4] is used with %gr then I begin to get similar output. Note that the background colour for %pl is the default (white) whilst [grey] is being used for %gr. The difference in the display particularly relates to calls to draw_line_between@. There is also another issue with draw_pixel@...

2. draw_pixel@ currently does not work when it accesses the GDI+ library (i.e. when used in a %pl callback). I have fixed this for the next release of the ClearWin+ library. Another problem is that draw_pixel@ is extremely slow for GDI+. I don't have a fix for this at the moment.

My conclusion is:

1. It's not a good idea to use draw_pixel@ in a %pl callback function because at the moment it gives the wrong result and it remains extremely slow.

2. In this kind of intensive graphics code, draw_line_between@ gives different results when accessing the Microsoft GDI+ library and when compared to the older GDI library (the basic MoveTo and LineTo functions). I have tried various smoothing modes and have not been able to create a match.

This kind of issue should only affect detailed surface plotting. There should be no problem when drawing simple lines and curves from a %pl callback function.

p.s. Edited to change from set_pixel@ to draw_pixel@ and to remove a comment about the Microsoft GDI+ library.

The issue relating to draw_line_between@ in the post above has now been fixed. At the moment draw_pixel@ remains exceedingly slow when using GDI+.

The result is that the two methods (one using %gr, the other using %pl) will now produce essentially the same output.

Paul If the speeds in %pl and %gr mode are still different may be good would be to introduce GDI_off@ function which will allow surface plotting in %pl mode run with %gr speed and then when plotting done GDI_on@ will allow other plotting (lines, axis, ticks and texts) run with better quality? This will be logical with Clearwin+ ideology to control everything for better adjustments if needed.

John

You have to look at what is produced by the format code Z6.6. Try it and see what you get.

Dan

Unfortunately that would involve a lot of work. At some point I will have another go at getting draw_pixel@ to respond more quickly.

John

There are slight differences because the image size is different. That might be the only difference.