Birth defect of Clearwin

14. OK, we are close to the end of needed major fixes and improvements for the native PL to make it absolutely perfect. All people do XY plotting and all need and definitely will appreciate them (excluding neo-Luddites). May be only few suggestions are left. One is to improve stability of LOG plotting when there are many functions plotted which needs more efforts from my side to make a demo. Another is more general suggestion for a whole Clearwin controls alignments we will discuss some time later. Both were somewhat discussed before in this forum.

Now let's return to this code I posted above again. This suggestion was also already discussed before but may be it was not clearly articulated.

use clrwin
 parameter (N = 2*2*2)
 real*8 X(N), Y(N)
 Data X/0.01,0.1,1,10, 100,1000,10000,100000/
 Data Y/0.011,0.044,0.33,2.2,66,3333,1111,777/

!... Regular Plot
 call winop@('%pl[x_axis='X Axis Title',y_axis='Y Axis Title']')
 i=winio@('%ww%pv%pl[native,x_array,scale=log_log,N_GRAPHS=1]%lw', 800,600, n, X, Y, ilw)

!...  Design Mode Plot
 i=winio@('%sf%ts%bf%es&', 2d0)
 call winop@('%pl[x_axis='X Axis Title',y_axis='Y Axis Title',file=zSetts.set]')
 i=winio@('%ww%pv%pl[native,x_array,scale=log_log,N_GRAPHS=1]',  800,600, n, X, Y)

 end

We can find screen coordinates XX and YY for each point on this screen using

 call get_plot_point@(X,  Y,  YY,  YY) 

(why XX and YY are not INTEGER but REAL*8 by the way? They change from 1 to 800 and from 1 to 600 only) but because the internal code always puts all tics on each axis based on its own considerations on how they should ideally look for the human eye, we never know what are screen coordinates for the 4 key X and Y (and XX and YY) axial intersections of the graph will be. We will know beginning and end points of X and Y coordinate points only if we set up them manually.

But the %PL code of course knows what beginning and end values of X and Y and XX and YY are internally because without their knowledge it is impossible to make any graphs.

The function is needed which returns the knowledge of these 4 pairs of X and Y and 4 pairs of XX and YY coordinates to the user.

This query [14] from Dan is related to margin size. If there was a procedure to recover the pixel size of the top, bottom, left and right margins (in the case where these have not been fixed by the user), then finding the pixel coordinates of the 4 straight lines that define the “frame” of the plot would be straightforward using the existing functions since the overall width and height of the graphics region is known, or can be found if a %pv is applied (such a resizing changes the margin size if not initially fixed).

This missing procedure is one of the reasons I tend to work with fixed margins, rather than letting %pl choose its own margins, and I generally also specify the axes range in the winop@ calls before graph is formed. Both approaches circumvent the particular problem being raised here.

Some of these issues have now been addressed.

1. The %pl scale:LINEAR,LOG_LINEAR,LINEAR_LOG or LOG_LOG will be adjustable when configuring a %pl graph. The option will appear as the last item in the main listview box of the configuration dialog.

2. SEMILOGY and LINX_LOGY will be provided as alternatives to LOG_LINEAR. SEMILOGX and LOGX_LINY will be provided as alternatives to LINEAR_LOG.

3. I have looked at the suggestion for a routine to supply the margins but I can't see a satisfactory way to do this without a major review of the code. As noted, the margins can be supplied by the user as [margin=(4,5,6,7)] and this is perhaps the simplest and best way to resolve this issue.

Thanks for taking the time to look at the margin question. By strange coincidence I looked at this again the other week and tried to back engineer how the margin sizes are calculated within clearwin.

This is what came up with:

       top    = int( 0.1 * max( graphics_width, graphics_depth ) )
       right  = top
       bottom = top
       left   = int( 1.5 * right )

Which seems to work well for aligning margin draw operations in the %pl “PLOT_ADJUST” call back – even when the user resizes the window and the %pl has a %pv.

module pl_margin
use clrwin
implicit none
integer :: screen_width, screen_depth, graphics_width, graphics_depth
contains
  integer function start()
  integer iw
   screen_width   = clearwin_info@('SCREEN_WIDTH')
   screen_depth   = clearwin_info@('SCREEN_DEPTH')
   graphics_width = int(0.5*screen_width)
   graphics_depth = int(0.5*screen_depth)
   call WINOP_INT@('%pl[n_graphs]', 1)
   call winop@('%pl[n_graphs=1, x_array, framed, etched, link=user]')
   iw = winio@('%fn[Arial]%ts&',2.d0)
   iw = winio@('%ww&')
   iw = winio@('%bg%`bg[white]&',rgb@(220,220,220))
   iw = winio@('%pv%^pl&',graphics_width,graphics_depth, 2, [0.d0,1.d0], [0.d0,1.d0], pl_cb)
   iw = winio@('')
   start = 2
  end function start

  integer function pl_cb()
  character(len=256) :: callback_reason, clearwin_string@
  integer :: left, top, right, bottom
    callback_reason = clearwin_string@('CALLBACK_REASON')
    if ( callback_reason  .eq. 'RESIZE' ) then
       graphics_width = clearwin_info@('GRAPHICS_WIDTH')
       graphics_depth = clearwin_info@('GRAPHICS_DEPTH')      
    else if ( callback_reason .eq. 'PLOT_ADJUST' ) then
       ! Calculate margins
       top    = int( 0.1 * max( graphics_width, graphics_depth ) )
       right  = top
       bottom = top
       left   = int( 1.5 * right )
       write(*,'(a,I4)') 'Graphics width = ', graphics_width
       write(*,'(a,I4)') 'Graphics depth = ', graphics_depth
       write(*,'(a,I4)') 'Top            = ', top
       write(*,'(a,I4)') 'Right          = ', right
       write(*,'(a,I4)') 'Bottom         = ', bottom
       write(*,'(a,I4/)') 'Left           = ', left
       ! Draw 3 rectangles based on these margins to show they align with frame
       call draw_filled_rectangle@(left, 1, graphics_width-right, top, rgb@(255,0,0))
       call draw_filled_rectangle@(graphics_width-right, 1, graphics_width, top, rgb@(0,255,0))
       call draw_filled_rectangle@(graphics_width-right, top, graphics_width, graphics_depth-bottom, rgb@(0,0,255))
    end if
    pl_cb = 2
  end function pl_cb

end module pl_margin

program main
use pl_margin
  i = start()
end program main

Ken

Here is the current code which might change with future developments...

  if(!spb->margin_supplied)
  {
    int m = 0.1*max(width,height);
    if(m < 28)  m  = 28;
    mptr->bottom = mptr->right = m;
    int hoffset = m/2;
    int voffset = 0;
    mptr->left = m + hoffset;
    mptr->top  = m + voffset;
  }

Thanks Paul, that’s useful. I almost got it right!

Two more small defects need fixing. They appear with no apparent reason, the attempts to make a demo extracting smaller snippets from the larger code reveals no errors in the code. Both causing program to crash instead of just stopping the code and asking how to proceed - ignore this problem and just do not execute the command or crash with the diagnostics message like many other Clearwin controls problems are currently being resolved

First is causing crash with 'Too many %CA formats'.

Another crashing with 'To many line styles such as [style=0] used with [link=curves]'.

Both these errors periodically kill a whole debugging day to find the reason and with %ca I could not find the solution for 20 years and in such cases just choose not to use %ca at all. The hint: this crash appears when many warning windows start to flood the screen, they appear for a split of a second and disappear by the next similar message which is made such a way that it also automatically closes previous window.

Same with any stiles, I just do not use any plot settings before calling %pl and rely instead on the settings in Designer's Mode. In some cases such preliminary settings together with Designers Mode are still desirable to use.

Dan

When you get into these kinds of coding failures I suggest

1. using /debug mode
2. when you get an error report, select the option to 'quit with traceback' and then use the reported code line numbers in the traceback to locate the fault.

In extreme cases you could step one line at a time using the debugger.

I can understand that, if you repeatedly ignore error reports then eventually ClearWin+ will get lost in the confusion.

Don't forget to be careful with your use of ampersands to end each Window.

Paul, That is exactly what my message was about. Of course I use /debug when revealing any error and doing that for 30+ years (3x longer than you guys at Silverfrost, as the fact that you have a debugger and it is the major golden compiler feature and selling point the Silverfrost and all its users 'discovered' only when moved to 64bits a decade ago 😃 😃 😃 ) , the problem is that these two controls do not offer 'quit with traceback' which i suggested to fix.

Right now the code simply crashes at %pl line in debugger with the complaint about too many styles (or about %ca with another case mentioned in previous message). The only I did not potentially do trying to understand your message correctly is that I have not tried the latest version of FTN95. May be you already fixed that. But I have to wait several days until my runs on my personal mini-super-compuPer finish. All 3-4 versions after 9.03 did not completely work with one of another of my code ( sometimes I was forced to use even 8.73 )

Dan

The option to continue after %ca and %pl errors has been provided for a number of years. If you are not seeing this option then the error dialog might be hidden behind another Window though this seems unlikely. Keep an eye on the taskbar when this happens.

Otherwise I don't have enough information to be able to work out what is going wrong for you.

One more Clearwin shortcoming is that when you renew the plot with the call to simpleplot_update@ everything on the plot area is renewed but not the title and x and y captions.

I reported the problem with combination of button color change %bc%bt in special circumstances when the window is set to be with %lw at its end: initially the color of button is the one you have set it, but after one click it changes, and next time also changes etc. This devilry is still there.

Now with FTN95 9.14 in addition to that the button got one more strange defect I can only show in video not pictures or describe by words. When I click on a button starting some callback which in turn starts some run and %sl displays the progress of tun, this run does not start until I remove the mouse pointer from the button (not pushing anything, just keeping the pointer on button). If I remove mouse pointer from the button and hovering it touch the button again (without any clicks just place mouse pointer on a button) the run stops. Miracle?

By the way by coincidence this was a Saturday Devilry from my buggy desk. I get them in uncountable amount every damn day not just from FTN95 but from everything, even the things which naturally should go with 50% probability in average go my way only after 3 faulty attempts

As always, I can only attempt to fix things that can be demonstrated in sample code that I can compile and run.

This still waits for my free time to create a reproducer. Also I got several other problems where the problem disappears in the reproducer. This is very annoying issue. The gang control %ga also has an issue and it disappears in reproducers. And all these addons like 'COPY', 'PASTE' if you use them inside the text window control %cw. Latest guys are specifically brutal, they just cause access violations in the running codes if you run several of them simultaneously. I mentioned that long ago and they are still not fixed because it is hard to make the reproducers

Sometimes I get the reproducer to show the problem but the effect disappears when used on other computer. I ran today 15 years old program and it has some minor but annoying complains with the current 9.14 Fortran. I can send Fortran reproducer to anyone who wants to try and confirm it, just PM me. I made it to catch another bug a decade ago and spent in total a month on it. That two decades old bug living in our computers and still laughing on us