Welcome to our forums
Thanks Paul, indeed, the dx and dy allows the fine tuning of amount of numbering labels. I updated the code above on page 15 to include the dx and dy steps
CALL winop@('%pl[dx=0.1,dy=0.1]')
UPDATE. After further play with this feature i found that it only worked for this specific sizes around 900x600. When i took much larger plot size for example 3600 x 2000 (initially or after resize using mouse) the program forgets this 0.1 step and starts to behave like before, placing large amount of numbers with smaller then user requested dx and dy steps.
I understand that if labels become too crowded that they start to overlap the code should decrease their amount up to just one label or even zero for very small thumbnail images, but for larger images the dx=fval and dy=fval have to stay as user requested, in our example dx=0.1, dy=0.1
Also is it planned to have something like this to update dynamically ?
CALL winop@('%pl[dx@]',dx_dval)
John,
**Paul, **
Looks like get_plot_point@ has a bug. Look at this code which plots line from min left to max right of screen. Code places point at (X,Y) = (1,1). Try to change limits in small range and see all is OK until min values become positive
module surfplot2mod
use clrwin
integer (7) ihandleSP2
real*8 x(2),y(2), xEllipse, yEllipse
real*8 xAxisMin, xAxisMax, yAxisMin, yAxisMax
CONTAINS
INTEGER FUNCTION plotSP()
x(1)=xAxisMin
x(2)=xAxisMax
y(1)=yAxisMin
y(2)=yAxisMax
call simpleplot_redraw@
ixR=7; iYr=7
call get_plot_point@(1d0, 1d0, xEllipse, yEllipse)
call draw_filled_ellipse@ (nint(xEllipse), nint(yEllipse),ixR,iYr,rgb@(244,0,0) )
call UPDATE_WINDOW@(ihandleSP2)
plotSP= 2
end function plotSP
!......................................................
INTEGER FUNCTION clearPL()
INTEGER errstate
errstate = change_plot_int@(0,'link',graph1,link_none)
CALL simpleplot_redraw@()
clearPL = 2
END FUNCTION clearPL
end module surfplot2mod
!.......................
Program SurfPlot2
use surfplot2mod
xAxisMin =-4
xAxisMax = 5
yAxisMin =-4
yAxisMax = 5
x(1)=xAxisMin
x(2)=xAxisMax
y(1)=yAxisMin
y(2)=yAxisMax
i = winio@ ('%ww%nr&')
call winop@ ('%pl[native,x_array,N_GRAPHS=1]')
call winop@ ('%pl[scale=linear]')
CALL winop@('%pl[tick_len=9]')
CALL winop@('%pl[dx=1.]')
CALL winop@('%pl[dy=1.]')
i = winio@ ('%sf%ts%bf&', 2d0)
call winop@ ('%pl[framed,axes_pen=3,width=3,x_axis='Length',y_axis='Width']')
i = winio@ ('%pv%pl&',800,600,2,x,y)!
i = winio@ ('%sf%ts%ff&', 1d0)
i = winio@ ('Set Xmin, Xmax%ta%df%9^rf%df%9^rf%ff&', 1d0,xAxisMin,'+', clearPL, plotSP, 1d0, xAxisMax,'+', clearPL, plotSP)
i = winio@ ('Set Ymin, Ymax%ta%df%9^rf%df%9^rf%ff&', 1d0,yAxisMin,'+', clearPL, plotSP, 1d0, yAxisMax,'+', clearPL, plotSP)
i = winio@ ('%cn%^bt[PLOT]%^bt[Clear]%ff&', '+', clearPL, plotSP, clearPL)
i = winio@ ('%ac[Esc]&', 'exit')
i = winio@ ('%hw%lw', ihandleSP2, lw_SP2)
jj = plotSP()
end
I can't see a problem at the moment. Which 'min values' are you referring to?
Paul, Apologies for raising this again, but can I reiterate my suggestion for an option to place the text for the scales external to the frame. It's one limitation of the present %pl which I cannot devise a 'work around' before the call to %pl, and it really spoils plots like this one.
In this example I am drawing the circles after the plot is formed (there is an invisible graph plotted first to establish the frames).
A quick fix is to use set_opacity@(128) but that results in the plot looking rather 'wishy - washy' as we say in Glasgow.
I do have an idea of how I could fix this - but it involves generating two other plots and copying the graphic areas containing the scales into the final plot in which the scales have been suppressed by making the text the same colour as the back-ground - all a bit messy. Hence my gentle reminder.
I cannot simply set the text colour to white before the call to %pl, and add the scale text via the call back as the user specified dx and dy values are not always used.
Same plot, using set_opacity@ tricks:-
It's OK, but external scales would be better
Thanks Ken 😄
Quoted from PaulLaidler I can't see a problem at the moment. Which 'min values' are you referring to?
Paul, I already wrote my suspicion that you guys at SF do not use debugger, but that you also do not use FTN95 I started to suspect after beginning of this thread 😃 😃 😃 This is why the one-line code with 6 bugs I published here at least 3 times and twice sent by PM was not fixed for so long time 😃 😃 😃
So suspecting this I added %df and %9^rd specially to simplify the process of choosing numbers - just click and see that the red dot is at X=1 or 2 , 3 or 4 when Xmin is 0, 1, 2 or 3 but it had to be always at X=1 at any Xmin. Same for Ymin (here watch also how axis name Width becomes not centered, and minus sign is too far from the numbers). But for that it is necessary to compile the code and make an EXE file not just look at the source and do the calculation in the head. 😃 In your head this code works fine and has no errors because compilers are different !!! 😃
Was just kidding. Or may be not?
Ken,
Hope your suggestion will be realized. But there exist another option. I do not know how difficult is to realize it. It requires the letters with the cast like here. Doable easily? Our students with Python doing this, looks perfect.
Dan
Can you check the code that you have posted. I may be missing something but I don't think it does what you say. Try running it after copying it back to your computer.
Ken
I have noted your request. In the meantime one way to fix the presentation is to draw the axes with an offset.
CALL winop@('%pl[y_axis=Amplitude@(-30,0)]')
Dan
I have tried to work out what your program is intended to do but I can't make it out. It plants an 'ellipse' at (1,1) and the range for the axes is changed via %rf edits. But the changed values are not implemented in the drawing of the graph.
If, in your version of the program, the 'ellipse' is not drawn when the xAxisMax value goes negative then that is what should happen.
Apart from the fact that the program is not functional, the only error I can see is that the parameters graph1 (=1) and link_none (=0) have not been defined or set.
Paul, I checked the code above and all works like i described. Not sure undefined variable was important and not sure i fixed this undefined error correctly, but there is no undefined errors right now in little bit edited code below.
Now i hope that all users with older then 8.20 versions can reproduce this bug as i commented two lines setting dx= and dy=. This compiler needs more active users, this will help its development.
Do the following: for simplicity do not change anything but Xmin
You may play further and see that at Xmin=2 the red dot moved to 3. You may also edit the code and set position of red dot at any place, for example at 3,3 call get_plot_point@(3d0, 3d0, xEllipse, yEllipse) But as soon as Xmin becomes >0.5 the displayed position of red dot will be wrong
module surfplot2mod
use clrwin
integer (7) ihandleSP2
real*8 x(2),y(2), xEllipse, yEllipse
real*8 xAxisMin, xAxisMax, yAxisMin, yAxisMax
CONTAINS
INTEGER FUNCTION plotSP()
x(1)=xAxisMin
x(2)=xAxisMax
y(1)=yAxisMin
y(2)=yAxisMax
call simpleplot_redraw@
ixR=7; iYr=7
call get_plot_point@(1d0, 1d0, xEllipse, yEllipse)
call draw_filled_ellipse@ (nint(xEllipse), nint(yEllipse),ixR,iYr,rgb@(244,0,0) )
call UPDATE_WINDOW@(ihandleSP2)
plotSP= 2
end function plotSP
!......................................................
INTEGER FUNCTION clearPL()
CALL simpleplot_redraw@()
clearPL = 2
END FUNCTION clearPL
end module surfplot2mod
!.......................
Program SurfPlot2
use surfplot2mod
xAxisMin =-4
xAxisMax = 5
yAxisMin =-4
yAxisMax = 5
x(1)=xAxisMin
x(2)=xAxisMax
y(1)=yAxisMin
y(2)=yAxisMax
i = winio@ ('%ww%nr&')
call winop@ ('%pl[native,x_array,N_GRAPHS=1]')
call winop@ ('%pl[scale=linear]')
CALL winop@('%pl[tick_len=9]')
! CALL winop@('%pl[dx=1.]')
! CALL winop@('%pl[dy=1.]')
i = winio@ ('%sf%ts%bf&', 2d0)
call winop@ ('%pl[framed,axes_pen=3,width=3,x_axis='Length',y_axis='Width']')
i = winio@ ('%pv%pl&',800,600,2,x,y)!
i = winio@ ('%sf%ts%ff&', 1d0)
i = winio@ ('Set Xmin, Xmax%ta%df%9^rf%df%9^rf%ff&',1d-1,xAxisMin,'+', clearPL, plotSP, 1d0, xAxisMax,'+', clearPL, plotSP)
i = winio@ ('Set Ymin, Ymax%ta%df%9^rf%df%9^rf%ff&',1d-1,yAxisMin,'+', clearPL, plotSP, 1d0, yAxisMax,'+', clearPL, plotSP)
i = winio@ ('%cn%^bt[PLOT]%^bt[Clear]%ff&', '+', clearPL, plotSP, clearPL)
i = winio@ ('%ac[Esc]&', 'exit')
i = winio@ ('%hw%lw', ihandleSP2, lw_SP2)
jj = plotSP()
end
Dan
I haven't worked out exactly what is wrong with your code. Either it's related to the order that the callbacks are called or maybe a callback is being called from a callback. If the latter then perhaps PERMIT_ANOTHER_CALLBACK@ might fix it. Anyway here is a modified version of your code that does what I assume you want.
MODULE surfplot2mod
USE clrwin
INTEGER(7) ihandleSP2
REAL*8 x(2),y(2), xEllipse, yEllipse
REAL*8 xAxisMin, xAxisMax, yAxisMin, yAxisMax
CONTAINS
INTEGER FUNCTION plCB()
ixR=7; iYr=7
CALL get_plot_point@(1d0, 1d0, xEllipse, yEllipse)
CALL draw_filled_ellipse@(nint(xEllipse), nint(yEllipse),ixR,iYr,rgb@(244,0,0))
CALL update_window@(ihandleSP2)
plCB = 2
END FUNCTION plCB
!......................................................
INTEGER FUNCTION plotSP()
x(1)=xAxisMin
x(2)=xAxisMax
y(1)=yAxisMin
y(2)=yAxisMax
CALL simpleplot_redraw@
plotSP = plCB()
plotSP= 2
END FUNCTION plotSP
END MODULE surfplot2mod
!.......................
PROGRAM SurfPlot2
USE surfplot2mod
xAxisMin =-4
xAxisMax = 5
yAxisMin =-4
yAxisMax = 5
x(1)=xAxisMin
x(2)=xAxisMax
y(1)=yAxisMin
y(2)=yAxisMax
i = winio@ ('%ww%nr&')
CALL winop@ ('%pl[native,x_array,N_GRAPHS=1]')
CALL winop@ ('%pl[scale=linear]')
CALL winop@('%pl[tick_len=9]')
CALL winop@('%pl[dy=1.0]')
i = winio@ ('%sf%ts%bf&', 2d0)
CALL winop@ ('%pl[framed,axes_pen=3,width=3,x_axis='Length',y_axis='Width']')
i = winio@ ('%pv%^pl&',800,600,2,x,y,plCB)
i = winio@ ('%sf%ts%ff&', 1d0)
i = winio@ ('Set Xmin, Xmax%ta%df%9^rf%df%9^rf%ff&',1.d0,xAxisMin,plotSP,1d0,xAxisMax,plotSP)
i = winio@ ('Set Ymin, Ymax%ta%df%9^rf%df%9^rf%ff&',1.d0,yAxisMin,plotSP,1d0,yAxisMax,plotSP)
i = winio@ ('%cn%^bt[PLOT]%ff&',plotSP)
i = winio@ ('%ac[Esc]&', 'exit')
i = winio@ ('%hw%lw', ihandleSP2, lw_SP2)
END
Paul, I see exactly the same problem in you code. The doubledevilry ... like the two headed ridge nearby called Diablo 😃
All, Please check that if you increase Xmin > 0.5 the red dot moves instead to stay still at x=1 like it should
**Thanks, John. ** Letters jammed are OK. I see last month Paul started with scaling option, hopefully he will complete it in the future so that scaling will work with all elements of the plot (text sizes, borders, line widths). Right now it scales only plotting area, as i remember
**This message is to all, **
Can you please run my code in the page 17 choosing 'PL' option gradually decreasing the size of plotting area to zero ? Do you see that the ring pattern is plotted OK? I see all OK, John gets empty plotting area
Things are beginning to make sense...
On a different thread https://forums.silverfrost.com/Forum/Topic/3104 you will find a reference to unwanted callback reasons '?'. One way that these occur is when an action in a callback function leads to another callback function being called. This malfunction is now blocked in the latest ClearWin+ that I am using and which has not yet been released.
This means that you will be getting a different experience from me. It also means that the root problem is (almost certainly) that of one callback leading immediately to a call to another (or worse still) a call to itself.
You might observe this by tracking the callback reason but I suggest that you put this issue on the back burner until you get the next release of the ClearWin+ library.
Paul,
Another one for you to look at I am afraid. GET_PLOT_POINT@ only works properly if the range between xmin and xmax spans zero, and the range between ymin and ymax also spans zero.
The following code illustrates the issue. With the initial values, the point is drawn at the correct coordinates (0.5,0.50), but if you change xmin to 0.5 for example, the point is incorrectly drawn at (1.0,0.5). Same occurs with the y axis.
Regards
Ken
module main_mod
implicit none
integer, parameter :: dp = kind(1.d0)
real(kind=dp):: xmin=0.d0, xmax=1.d0, ymin=0.d0, ymax=1.d0, x = 0.5d0, y = 0.5d0
contains
integer function main01()
include<windows.ins>
integer i
i = winio@('%ws&','Range values for plot')
i = winio@('%nl%ws%ta%rf%ta%ws%ta%rf&', 'Xmin', xmin, 'Xmax', xmax)
i = winio@('%nl%ws%ta%rf%ta%ws%ta%rf&' ,'Ymin', ymin, 'Ymax', ymax)
i = winio@('%nl%ws&','Point to be plotted')
i = winio@('%nl%ws%ta%rf&','X',x)
i = winio@('%nl%ws%ta%rf&','Y',y)
i = winio@('%ta%^bb[plot]',plot)
main01= 1
end function main01
integer function plot()
include<windows.ins>
integer i
real(kind=dp) x1(2), y1(2)
if ( (xmax .le. xmin) .or. (ymax .le. ymin) ) then
write(6,*) 'ERROR in input data'
plot = 1
return
end if
x1(1) = xmin ; x1(2) = xmax ; y1(1) = ymin ; y1(2) = ymax
i = winio@('%^pl[native,x_array,colour=white,gridlines,framed]&',400,400,2,x1,y1, update)
i = winio@('%ff%cn%bb[OK]')
plot = 1
end function plot
integer function update()
include<windows.ins>
real(kind=dp) xpix, ypix
call GET_PLOT_POINT@(x,y,xpix,ypix)
call draw_filled_ellipse@(nint(xpix),nint(ypix),2,2,rgb@(0,0,0))
update = 1
end function update
end module main_mod
program main
use main_mod
implicit none
integer i
i = main01()
end program main
And a picture. Two examples, left is correct, right is not.
==================== A little more:-
Thinking about this, maybe the function is returning the correct coordinates if the axis were placed over the origin at (0,0). Maybe we need another function that takes account of any displacement of the plot origin from (0,0,)? I guess what I saying is that the returned value is not the one I naturally thought the function would return. Hope this make sense.
Problem solved. get_plot_point2 demonstrates that I thought GET_PLOT_POINT@ would do. Note that you need to explicitly know xmin for this to work.
module main_mod
implicit none
integer, parameter :: dp = kind(1.d0)
real(kind=dp):: xmin=0.d0, xmax=1.d0, ymin=0.d0, ymax=1.d0, x = 0.5d0, y = 0.5d0
contains
integer function main01()
include<windows.ins>
integer i
i = winio@('%ws&','Range values for plot')
i = winio@('%nl%ws%ta%rf%ta%ws%ta%rf&', 'Xmin', xmin, 'Xmax', xmax)
i = winio@('%nl%ws%ta%rf%ta%ws%ta%rf&' ,'Ymin', ymin, 'Ymax', ymax)
i = winio@('%nl%ws&','Point to be plotted')
i = winio@('%nl%ws%ta%rf&','X',x)
i = winio@('%nl%ws%ta%rf&','Y',y)
i = winio@('%ta%^bb[plot]',plot)
main01= 1
end function main01
integer function plot()
include<windows.ins>
integer i
real(kind=dp) x1(2), y1(2)
if ( (xmax .le. xmin) .or. (ymax .le. ymin) ) then
write(6,*) 'ERROR in input data'
plot = 1
return
end if
x1(1) = xmin ; x1(2) = xmax ; y1(1) = ymin ; y1(2) = ymax
i = winio@('%^pl[native,x_array,colour=white,gridlines,framed]&',400,400,2,x1,y1, update)
i = winio@('%ff%cn%bb[OK]')
plot = 1
end function plot
integer function update()
include<windows.ins>
real(kind=dp) xpix, ypix
!call GET_PLOT_POINT@(x,y,xpix,ypix)
call get_plot_point2(x, y, xmin, ymin, xpix, ypix)
call draw_filled_ellipse@(nint(xpix),nint(ypix),2,2,rgb@(0,0,0))
update = 1
end function update
subroutine get_plot_point2(x, y, xmin, ymin, xpix, ypix)
include<windows.ins>
real(kind=dp), intent(in) :: xmin, ymin, x, y
real(kind=dp), intent(out) :: xpix, ypix
real(kind=dp) :: xpix0, ypix0, xminpix, yminpix
call GET_PLOT_POINT@(0.d0,0.d0,xpix0,ypix0)
call GET_PLOT_POINT@(xmin,ymin,xminpix,yminpix)
call GET_PLOT_POINT@(x,y,xpix,ypix)
xpix = xpix - (xminpix - xpix0)
ypix = ypix - (yminpix - ypix0)
end subroutine get_plot_point2
end module main_mod
program main
use main_mod
implicit none
integer i
i = main01()
end program main
Ken, How about Xmin=Ymin=-2 Xmax=Ymax=3 ?
Yes Dan, I was too quick there. Solved a particular case rather than the general. One of the pleasures (?) of this game. Ken
I HAVE DELETED THE CODE I POSTED HERE EARLIER AS IT STILL GENERATED AN ERROR IN SOME TEST CASES
Thanks for the feedback. Ken's first sample reveals a bug in GET_PLOT_POINT@ that has now been fixed. Hopefully the alternative approaches will no longer be needed with the next release.
Ken's sample also reveals missing tick marks and grid lines and issue is currently outstanding.
Paul,
I stumbled upon this yesterday by accident when one of my colleagues put 'silly' data into one of my applications.
Do you have a timescale for making an updated DLL available? I am beginning to use %pl in earnest now with my applications. I guess you may have been working on the scale issues we have been collectively grumbling about for 6 months now?
Thanks
Ken
Ken
I am not sure when we will release a new ClearWin+. We may have to wait till the personal edition for v8.2 is released otherwise we could easily get out of step for some users.
I will see if it is possible to make a new ClearWin+ only work with v8.20.