Welcome to our forums
Question, is there a way to interrogate the clearwin data to determine the currently applied %pl dx and dy values?
I think I already know the answer as I cannot see a documented function something like: GET_PLOT_DBL@(id, option, index, fval), but it may exist?
Ken
I am unable to remove my first post of today, something went horribly wrong. Perhaps the forum admin can do this?
The question above, stems from the code at the link below, which shows that the value returned by change_plot_dbl@ to adjust dx is always zero, even when the requested change is not made (maybe a silly value, or a value which would cause the text to overlap depending on the plot aspect ratio).
If a non-zero value was returned (as implied in the documentation), the code could detect this and 'try again' with an alternative value. Consequently, the fortran code cannot keep track of the current dx value.
This means that if I use %pl without gridlines, if I then draw the grid lines within the %pl call back, the dx spacing may, or may not correspond to the value that was specified in the last call change_plot_dbl@ for dx.
At the moment, I cannot see a way to ensure that the %pl call back uses the correct dx value when drawing the vertical gridlines, i.e. aligned with the numbers on the x axis.
I was not initially looking at the return value from change_plot_dbl@ when I observed this occasionally occurring, and I thought the return value would provide a solution, but this does not appear to be the case.
Same issue can occur with the dy value.
Is this a possible bug in change_plot_dbl@ ? https://www.dropbox.com/scl/fi/or7hmrqffpb2jpduhsjy3/dxproblem.f95?rlkey=rflboeyfatxygn50qbopqfdr9&dl=0
Ken
I have tested your sample program.
After clicking the CB4 button I get -521, -511, -501 on the x axis. The same for both 32 and 64 bits.
Am I missing the point?
Paul,
I knew this would be difficult to explain.
You and I can, but the fortran code cannot view the graph, so how can the code keep track of the presently applied dx value after the last call to change_plot_dbl@, since this always returns zero?
Consider the sample program (which is rather artificial), where CB1 and CB5 are called in sequence.
When the window is formed, %pl is setting its own xmin, xmax, and dx.
After the call to CB1 Xmin, and xmax are changed to “nice” values i.e. – 520 and -500.
After the call to CB5 which fails to set the dx value to 20, the more complex / extended program logic thinks the values are:
Xmin = -520 Xmax = -500 dx = 20
But in reality they are:
Xmin = -520 Xmax = -500 dx = 10
Additional code, which now attempts to draw the vertical grid lines based on a dx value of 20 which it thinks has been applied, means that the grid line which is required in the actual grid produced (with dx =10) at Xmin + dx = -520 + 10 is omitted. The resulting graph is shown below:
This is the issue which started me off looking at the return value from change_plot_dbl@.
Perhaps the solution to my problem is simply to prevent the case where dx = (xmax – xmin) ever occurring, but that may generate another problem when the x/y grid aspect ratio is low (x axis becomes cluttered). I will explore this further. (An even simpler solution, remove the option to redraw the grid lines and use the default %pl gridlines, but they become somewhat lost under all the other data in the graph.)
I’m now curious, under what circumstances does change_plot_dbl@ actually return a non-zero value?
This may better illustrate the issue.
program dxdy2
use clrwin
implicit none
integer iw, cb1, pl_cb ; external cb1, pl_cb
real*8 xmin, xmax, dx, ymin, ymax
common xmin, xmax, dx, ymin, ymax
xmin = -520.d0 ;xmax = -500.d0 ; dx=20.d0 ; ymin = 230.d0 ; ymax = 250.d0
iw = winio@('%mn[Exit]&','exit')
call winop@('%pl[native,x_array,frame,etched,external_ticks,smoothing=5,axes_pen=2,link=user]')
iw = winio@('%^pl&', 600,600,2,[xmin,xmax],[ymin,ymax], pl_cb)
iw = winio@('%^bn[CB1]',cb1)
end program dxdy2
integer function cb1()
use clrwin
implicit none
integer :: i(3)
real*8 xmin, xmax, dx, ymin, ymax
common xmin, xmax, dx, ymin, ymax
i(1) = change_plot_dbl@(0,'x_min', 0,xmin)
i(2) = change_plot_dbl@(0,'x_max', 0,xmax)
i(3) = change_plot_dbl@(0,'dx', 0,dx)
print*, i
call simpleplot_redraw@()
cb1 = 2
end function cb1
integer function pl_cb()
use clrwin
real*8 xmin, xmax, dx, ymin, ymax, x
common xmin, xmax, dx, ymin, ymax
logical, save :: first = .true.
if (clearwin_string@('CALLBACK_REASON') .eq. 'PLOT_ADJUST') then
if (first) then
first = .false.
else
x = xmin ! Should really be x = xmin+dx
call set_plot_mode@(1) ; call set_line_width@(3)
do while (x .le. xmax) ! Should really be x .lt. xmax
call draw_line_betweenD@(x,ymin,x,ymax,rgb@(255,0,0))
x = x + dx
end do
call set_line_width@(1) ; call set_plot_mode@(0)
first = .false.
end if
end if
pl_cb = 2
end function pl_cb
Issue now resolved by changing slightly the code that selects the desired xmin, xmax and dx values.
Examining the value returned by change_plot_dbl@ was the wrong path to follow, although it seemed logical on Thursday morning!
A very presentable contour plot:
It looks very impressive.
Paul,
I have looked at this a little more closely, as my 'fix' fails in one test.
In the following code, the failure of change_plot_dbl@ to change the dy value is demonstrated.
There are three %pl regions which are created sequentially. In each case the pl graph frame is initially the unit square. The callback associated with the button CB, calls change_plot_dbl@ to change the following values:
x_min = -5, x_max = 5, dx = 5, y_min = -5, y_max = 5, and dy = 5
and thereafter calls simpleplot_redraw@.
The code works as expected for the first two cases, but fails in the final case where the plotted dy value is 2.5 rather than the requested 5.
The only difference is that the final case has the %pl margins explicitly specified via a call to winop. The presence of this margin specification appears to be the cause of the problem.
program p
use clrwin
implicit none
integer iw
integer cd ; external cb
iw = winio@('%mn[Exit]&','exit')
iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
call winop@('%pl[native,x_array,frame,link=user]')
iw = winio@('%pl&', 500,500,2,[0.d0,1.d0],[0.d0,1.d0])
iw = winio@('%sf%^bn[CB]',cb)
iw = winio@('%mn[Exit]&','exit')
iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
call winop@('%pl[native,x_array,frame,link=user]')
iw = winio@('%pl&', 1344,876,2,[0.d0,1.d0],[0.d0,1.d0])
iw = winio@('%sf%^bn[CB]',cb)
iw = winio@('%mn[Exit]&','exit')
iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
call winop@('%pl[native,x_array,frame,link=user]')
call winop@('%pl[margin=(294,60,294,60)]')
iw = winio@('%pl&', 1344,876,2,[0.d0,1.d0],[0.d0,1.d0])
iw = winio@('%sf%^bn[CB]',cb)
end program p
integer function cb()
use clrwin
integer i
i = change_plot_dbl@(0,'x_min',0,-5.d0)
i = change_plot_dbl@(0,'x_max',0, 5.d0)
i = change_plot_dbl@(0,'dx', 0, 5.d0)
i = change_plot_dbl@(0,'y_min',0,-5.d0)
i = change_plot_dbl@(0,'y_max',0, 5.d0)
i = change_plot_dbl@(0,'dy', 0, 5.d0)
call simpleplot_redraw@()
cb = 2
end function cb
The solution to the last problem is to ensure that the ratio of (top margin + bottom margin)/graphics_height is greater than 0.2
Thanks for the feedback Ken.
Here is some background information for the general reader.
The functions CHANGE_PLOT_INT@, CHANGE_PLOT_DBL@ and CHANGE_PLOT_CHR@ return the integer value zero on success. Other values indicate an error. These functions change the data but the user will need to call a routine like SIMPLEPLOT_REDRAW@ in order to redraw the graph. At that point the graph ought to be redrawn in the form that would appear if the new data had be used at the outset.
This may help to identify the source of the problem.
The same issue can be replicated without calling CHANGE_PLOT_DBL@.
program p
use clrwin
! This example shows that specifying the dy value via winop@ before the window is
! formed fails to set dy to the required value i.e. 5 - when the margins are
! specified. The plotted value is 2.5
! The correct dy value is obtained if the call to winop@ with the margin spec is
! commented out.
iw = winio@('%mn[Exit]&','exit')
iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
call winop@('%pl[native,x_array,frame,link=user]')
call winop@('%pl[x_min=-5, x_max=5, dx=5, y_min=-5, y_max=5, dy=5]')
call winop@('%pl[margin=(294,60,294,60)]') ! Comment out this line to get dy = 5
iw = winio@('%pl', 1344, 876, 2, [0.d0,1.d0], [0.d0,1.d0])
! With the margin spec in place, the required dy value 5, is obtained if in the winop@ call dy = 9.
iw = winio@('%mn[Exit]&','exit')
iw = winio@('%fn[Consolas]%ts%bf&',1.5d0)
call winop@('%pl[native,x_array,frame,link=user]')
call winop@('%pl[x_min=-5, x_max=5, dx=5, y_min=-5, y_max=5, dy=9]')
call winop@('%pl[margin=(294,60,294,60)]')
iw = winio@('%pl', 1344, 876, 2, [0.d0,1.d0], [0.d0,1.d0])
end program p
PS In the first case, the %pl graph dy cannot be corrected at runtime by the addition of the option [params].
Ken
I have logged this issue for investigation.
Ken
I can see in the ClearWin+ code where this value is limited but a change might affect user's existing code.
I have added an option CLEARWIN_OPTION@('no_pl_dy_limit') that will allow you to experiment with this internal limit removed.
Our code changes are currently locked pending a full release so if I send you the update now it may be out of step with the next release.
I could send you updated DLLs on this understanding.
Paul,
Yes, the 'no_pl_dy_limit' is probably the solution I am looking for. I have tried, but failed to work out the functioning of that limit which I have long suspected is in the Clearwin code.
A 'no_pl_dy_limit' would certainly provide a solution to an issue encountered previously. A common range in the electrical world for % voltage is y_min=97.5, y_max=102.5, and most power transformers have a 1.25% taps on the HV side, so dy = 1.25 and it is not possible to use these values in a %pl plot.
I am certain the dy increment value I am requesting is reasonable, but I guess what is reasonable, may be a moot point!
If you could provide a 64 bit dll, I can experiment with that. Issues with upcoming full release understood. Many thanks for taking the time to look at this.