Is it possible to get data points from a graph?

As i wrote before i still do not understand how this code works. What specifically do you mean with cleaning the buffer, why it is needed and how it can be done?

Does %mg following any changes in WM_KEYDOWN (and this variable seems tracks any keyboard presses in Windows) and if it sees change in WM_KEYDOWN it calls call-back function? is this how it works?

I was testing this approach for a while and initially all was ok as well as it is seems ok with the small example i wrote above. But installing it into large code i found recently it stopped to work properly. I have to push button several times to get action. Could be other bug, the code is almost out of damn 32-bit OS stack limit 1.6GB ...

Basically you need to get some idea of how the Windows messaging works particularly via the Windows API SendMessage. %mg provides a way for ClearWin+ to pick up a message (in this case a key down message) and pass it on to you the user. So if you look up SendMessage and find out what is delivered with the ID WM_KEYDOWN then you will see how the parameters wparam and lparam are used for this message.

The traditional way of handling keyboard input was to put the actions into a buffer so that programs could pick up the information via a sutable read buffer function. A number of key strokes can thus be stored before a program starts to get them. get_wkey@ either emulates this kind of buffer or uses an existing one provided by the system (the former I think).

What I was trying to say was that there is a possiblitily for a particular WM_KEYDOWN to get out of sync with the first key in the keyboard buffer, in which case the wparam info will not match the result of the call to get_wkey@.

I will put this into followup and investigate how both methods differ later after resolving more serious issue -- why my code above stopped working when placed in the larger code which is balancing near the limit of another 'buffer' - stack size approaching now 1.4GB almost nothing leaving for the code (here even debugger sometimes hiccups showing A = 0 in the equation A = B + C with B>0 and C>0 requiring Windows reboot)

Yes, handling keyboard could sometimes be tricky. In regards of your initial code example on the first page of this thread with full_mouse_input: is there any way in Clearwin to handle mouse scroll wheel ?

Dan,

is there any way in Clearwin to handle mouse scroll wheel ?

This has been covered before, see:-

https://forums.silverfrost.com/Forum/Topic/619&highlight=scroll+wheel

http://forums.silverfrost.com/viewtopic.php?p=1976#1976

cheers, John

Thanks...I've made this small addition to the code above to demonstrate it, please check if this is how wheel supposed to work?

!
!     compile FTN95 filename.f95 /link
!
!--------------------------------------------------------------- 
      include <windows.ins> 
      integer  gr_func,mg_func 
      external gr_func,mg_func 
      character*40 cstat 
      common cstat 

      integer, parameter:: WM_MOUSEWHEEL = Z'020A' 
      integer  OnMouseWheel
      external OnMouseWheel

      cstat=' ' 
      i=winio@('%ww[no_border]&') 
      i=winio@('%ca[Sample]&') 
      i=winio@('%mn[E&xit]&','EXIT') 
      i=winio@('%ob&') 
      i=winio@('%mg&', WM_KEYDOWN, mg_func) 
      i=winio@('%mg&', WM_MOUSEWHEEL, OnMouseWheel)
      i=winio@('%^gr[black,full_mouse_input]&',300,300,gr_func) 
      i=winio@('%cb%ob[status]%20st%cb',cstat) 
      end 
!----------------------------------------------------------- 
      integer function mg_func() 
      include <windows.ins> 
      integer wparam,i 
      character*40 cstat 
      common cstat 
      integer key, get_wkey@ 
      save i 
      data i/0/ 
      i=i+1 

      key=get_wkey@() 

      cstat(i:i)= char(key) 
      call window_update@(cstat) 
      if(i > 39) i=0 
      mg_func=1 
      end 
!----------------------------------------------------------- 
      integer function OnMouseWheel()
      use mswin
      integer wparam

      wparam = clearwin_info@('MESSAGE_WPARAM') 
      wheel_rot = HIWORD@(wparam) / 120 ! rotations reported as *120 
      print*,'wheel_rot=',wheel_rot

      OnMouseWheel=1 
      end function OnMouseWheel
!-----------------------------------------------------------
      integer function gr_func() 
!     Process mouse keys here      
      gr_func=1 
      end 

     

Dan, yes, rightly or wrongly that's how I use it. I don't find the actual value reported is much use, so I just check for a negative or positive value and act on that.

OK. And it shows larger values then +1 and -1 when you move it fast, like 6-7, right? I am trying to understand if this hidden trickery is PC specific, mouse driver specific or OS specific...

Dan, you must have quicker fingers than me, if I try really hard I might get a 4 !

I don't think this is important though, for every ratchet on the scroll wheel I get a returned value, so simply the more you rotate the wheel the more returns you see, I think that this is sufficient for a continuous zoom in/out effect on a graphics screen for instance.

Just make your mouse and keyboard a bit faster then in default settings, John 😃

Well, well, I have eventually found how to manage Simpleplot plots within a %dw graphic window, and how to get the value of the points inside it. As it seems to work very well, I would like to share my findings in this respect, as it could be usefull for someone else. Here is the code for a simple plot (remember that one has to link it with the simpleplot.dll library). My previous solution was based on a pure use of Simpleplot and Simpleplot windows, which is not very nice if one is deeply involved with a Clearwin approach. The powerful facilities of the old Simpleplot are extremely useful for making almost any graphics (thanks David Butland & Co.!).

Agustin

MODULE SPWIN ! Contains definition of values to pass to DDDATA INTEGER,PARAMETER :: SIMPLE_WINDOWS_WINDOW=1,SIMPLE_WINDOWS_PRINTER=2, & &SIMPLE_WINDOWS_DIB=4,SIMPLE_WINDOWS_METAFILE=8,SIMPLE_PERCENT=0,SIMPLE_PIXELS=1,SIMPLE_MM=2 TYPE SIMPLE_WINDOWS_DATA_STRUCT_T INTEGER :: iOpc ! Corresponds to C++ long int INTEGER :: iPtr ! Address of OpCode specific data END TYPE SIMPLE_WINDOWS_DATA_STRUCT_T TYPE SIMPLE_WINDOWS_HDC_DATA_T INTEGER :: hDC ! device context handle INTEGER :: iWidth, iHeight ! plotting area END TYPE SIMPLE_WINDOWS_HDC_DATA_T TYPE SIMPLE_WINDOWS_SIZE_T INTEGER :: iUnits ! SIMPLE_PERCENT, ..._PIXELS, ..._MM INTEGER :: iWidth, iHeight, iDepth END TYPE SIMPLE_WINDOWS_SIZE_T TYPE SIMPLE_WINDOWS_ORIGIN_T INTEGER :: iUnits ! SIMPLE_PERCENT, ..._PIXELS, ..._MM INTEGER :: iX, iY END TYPE SIMPLE_WINDOWS_ORIGIN_T TYPE HDC_DIM_TYPE INTEGER*4 iBitmapDC, iWidth, iHeight END TYPE HDC_DIM_TYPE TYPE (HDC_DIM_TYPE) :: HDC_DIM INTEGER, PARAMETER :: SIMPLE_WINDOWS_END_LIST = 0 INTEGER, PARAMETER :: SIMPLE_WINDOWS_SET_WINDOWNAME = 6 INTEGER, PARAMETER :: SIMPLE_WINDOWS_SET_HDC_DIM = 7

! Useful definition of data structure to hold BitmapDC to pass to SIMPLEPLOT

Contains

SUBROUTINE SP_SupplyBitmap ! Pass Bitmap to SIMPLEPLOT ! Set up a Static (SAVEd) array of OpCodes. Each OpCode consists of an ! OpCode ID followed by an optional address of a data structure. ! The parameter block address is passed to SIMPLEPLOT by SUBROUTINE DDDATA. ! ! In this example: ! SIMPLE_WINDOWS_SET_HDC_DIM specifies that the next integer is the address ! of a data structure consisting of a Bitmap DC followed by its dimensions ! SIMPLE_WINDOWS_END_LIST is the mandatory end of list item which does not ! require the address of a structure TYPE(SIMPLE_WINDOWS_DATA_STRUCT_T), DIMENSION(2) :: OpCodes SAVE OpCodes OpCodes(1)%iOpc = SIMPLE_WINDOWS_SET_HDC_DIM ! hDC + dimensions OpCodes(1)%iPtr = LOC(HDC_DIM) ! See definition of SPWIN above OpCodes(2)%iOpc = SIMPLE_WINDOWS_END_LIST! End of list CALL DDDATA(LOC(OpCodes))! Notify SIMPLEPLOT CALL DEVNAM('WINDOW') ! Select Window CALL OWNNEW(.TRUE.) ! Inhibit 'Continue' button END subroutine SP_SupplyBitmap SUBROUTINE UpdateWin CALL OUTBUF ! Flush buffers CALL WINDOW_UPDATE@(HDC_DIM%iBitmapDC) ! Copy Bitmap to window END subroutine UpdateWin END MODULE SPWIN

,,,the rest of the code,,,

module subroutines

integer*4 flag_1,ans
real*4 :: xout=0.0,yout=0.0,xp1,yp1
real*8 :: xoutr,youtr

contains integer function gr2_func() call get_points gr2_func=1 end function gr2_func

subroutine Simpleplot_plots use mswin use spwin INTEGER, PARAMETER :: NARR = 8 REAL, DIMENSION(NARR) :: XARR = (/0.0, 2.0, 3.0, 4.0, 5.0, 6.0, 8.0, 10.0/) REAL, DIMENSION(NARR) :: YARR = (/0.0, 0.8, 0.5, 0.14, 0.8, 0.8, 0.35, 0.9/) HDC_DIM%iWidth = 600 HDC_DIM%iHeight = 450 HDC_DIM%iBitmapDC = GET_Bitmap_DC@(HDC_DIM%iWidth, HDC_DIM%iHeight) CALL SP_SupplyBitmap ! Pass Bitmap to SIMPLEPLOT call initsp call pgfull(.true.) CALL SCALES(0.0, 10.0, 1, 0.0, 1.0, 1) ! specify plotting scales CALL AXES7('x-axis', 'y-axis') ! start picture & draw pair of axes CALL BRKNCV(XARR, YARR, NARR, 0) ! draw curve of data call Updatewin end subroutine simpleplot_plots

subroutine get_points use mswin use spwin flag_1=clearwin_info@('GRAPHICS_MOUSE_FLAGS') if(flag_1==1) then xp1=clearwin_info@('GRAPHICS_MOUSE_x') yp1=HDC_DIM%iHeight-clearwin_info@('GRAPHICS_MOUSE_y') call pen(12) call kxyxy(0,xp1,yp1,5,xout,yout) xoutr=xout youtr=yout !in case one wants to mark the points....
call markpt(xout,yout,5) call updatewin
endif end subroutine get_points
end module subroutines

Program demo use spwin use mswin use subroutines external gr2_func call simpleplot_plots ans=winio@('%ca[A Simple Plot]%bg[grey]&') ans = winio@('%^dw[full_mouse_input]&',HDC_DIM%iBitmapDC,gr2_func) ! Pass bitmapDC to ClearWin ans=winio@('%ff x = %rf %ta y = %rf&',xoutr,youtr) ans=winio@('%ff%cn%6`bt[Close]') end program demo

Did you find also the solution for shifted axis labels in Simpleplot?

All x axis labels are shifted to the left, all Y axis labels to the bottom instead of being centered respect tick marks. You are permanently guessing which tick this label is marking - left or right, upper or lower.

That couple of defects (and another was CGA 4bit palette for color graphs) is so damn retarded, that it maddened me to the extent of not accepting Simpleplot at all. I wrote to the author a decade ago when he was still supporting it. Got no respond.

Well, well, nobody is perfect in this world......the answer is no, I have not found a solution for that problem, although I can say that in the case of the x-axis the labels can be centred using the subroutine AXLBJS('**', 'Centre'), but the y-axis still shows a small shift downwards at each tick, but the shift is not so critical, at least in my case, that makes the graph confusing as you say (if you try my example you will see that the labels are almost touching the ticks, so that the identification of ticks with labels seems to be rather obvious, but I have not checked it with all possible types of graphs!). Obviously I would prefer to see that the 'centre' argument in the subroutine really produces a centred label, as one should expect for such a name, but what are my other options?: a) make the graph using only FTN95 subroutines (I do not know how to do that in a simple and easy way); b) use SIMDEM (which I tried twice and found not as easy to do as with Simpleplot, i.e. there is a learning curve that requires more time than what I want to spend at the moment); c) use DSLIN subroutines for FTN95 (same as SIMDEM); d) buy something like GINO (too expensive for me, and the examples they show in the web site show also no centred y-labels! that's funny...).

Best regards,

Agustin