Graphics selections

Another one for you, Paul, sorry.

Clearwin knows when a click and drag (graphics selection) has been done, because it draws the box selection (as a box) or the line selection (as a line). Why doesn't it simply tell the programmer via a clearwin string with a callback_reason of something like GRAPHICS_AREA_SELECTED instead of requiring him (me!) to jump through the hoops of FULL_MOUSE_INPUT and detecting the button down and button release as detailed in the help file? I am struggling to separate this from single clicks.

Also, it would be far more useful if the relevant flags were given as a 5th parameter to get_graphics_selected_area@. Imagining that such a system were implemented, I could then write:

CBR = CLEARWIN_STRING@('CALLBACK_REASON') IF (CBR .EQ. 'MOUSE_LEFT_CLICK) THEN IXP = CLEARWIN_INFO@('GRAPHICS_MOUSE_X') IYP = CLEARWIN_INFO@('GRAPHICS_MOUSE_Y') .... ELSE IF (CBR .EQ. 'MOUSE_RIGHT_CLICK) THEN IXP = CLEARWIN_INFO@('GRAPHICS_MOUSE_X') IYP = CLEARWIN_INFO@('GRAPHICS_MOUSE_Y') ... ELSE IF (CBR .EQ. 'MOUSE_DOUBLE_CLICK) THEN IXP = CLEARWIN_INFO@('GRAPHICS_MOUSE_X') IYP = CLEARWIN_INFO@('GRAPHICS_MOUSE_Y') ... ELSE IF (CBR .EQ. 'GRAPHICS_AREA_SELECTED') THEN CALL GET_GRAPHICS_SELECTED_AREA@ (IX1, IY1, IX2, IY2, IFLAGS) ... ENDIF

or maybe:

CALL GET_GRAPHICS_SELECTED_AREA@ (IX1, IY1, IX2, IY2) CALL GET_GRAPHICS_SELECTION_FLAGS@ (IFLAGS)

I would be interested to know what other folk do about handling selections and clicks together.

Eddie

If you have not seen the following sample before then it may help you.

      winapp
c---------------------------------------------------------------
      include 'gr6.ins'
      integer i
      external gr_func

      cstat=' '
      mstat=0

      i=winio@('%ww[no_border]&')
      i=winio@('%ca[Box Selection]&')
      i=winio@('%mn[E&xit]&','EXIT')
      i=winio@('%ob&')
      i=winio@('%^gr[black,box_selection,full_mouse_input]&',
     +         300,300,gr_func)
c See also set_graphics_selection@
      i=winio@('%cb&')
      i=winio@('%ob[status]%20st%cb',cstat)

      end
c-----------------------------------------------------------
      integer function gr_func()
      include 'gr6.ins'
      integer x1,y1,x2,y2,nstat,a,b

      call get_mouse_info@(x1,y1,nstat)
      write(cstat(1:30),'(3I7)') x1,y1,nstat
      call window_update@(cstat)

      if(and(nstat,MK_LBUTTON).eq.0.and.and(mstat,MK_LBUTTON).ne.0)then
        call get_graphics_selected_area@(x1,y1,x2,y2)
        if(and(nstat,MK_SHIFT).eq.MK_SHIFT) then
          call rectangle@(x1,y1,x2,y2,12)
        elseif(and(nstat,MK_CONTROL).eq.MK_CONTROL) then
          a=0.5*(x2-x1)
          b=0.5*(y2-y1)
          call ellipse@(x1+a,y1+b,a,b,12)
        else
          call draw_line@(x1,y1,x2,y2,12)
        endif
      endif
      mstat=nstat

      gr_func=2
      end

where the include file contains:

      include <windows.ins>
      integer mstat
      character*30 cstat
      common/control/ mstat,cstat

Paul,

I'm afraid that you didn't get my meaning, but thanks anyway. The code you posted is pretty much what is in the help file. This could work fine if I intended the user to click on a button to 'enable' box selection, and click on another button to turn it off. This is often the case when one selects a 'magnifying glass' or other area selection tool in a graphics editing program like CorelDRAW (which I use a lot).

What I am after is being able to sift-out a simple left-click from a right-click from an area selection. CorelDRAW manages this just fine. For example, when working with the nodes on a polyline, it is possible to:

1. select one at a time, by left-clicking close to the node
2. group-select a bunch of them, with a 'box selection' - this is the standard operation for 'click-and-drag' if the initial point is not on a node.
3. if the initial point is ON a node, then click-and-drag MOVES the node
4. right-click on a node drops down a menu
5. right-click or left click not on a node deselects any nodes that are selected.

My ambitions are rather more limited than the level of functionality in CorelDRAW, I might add. The code you posted gets one in rather a tangle sorting out a simple click from a click and drag.

The whole point is that ClearWin has obviously already sorted out that a box selection is in progress, and when it is complete, so that it can draw the box or elastic line in real-time. It is rather a pity that it can't simply report that it has done so - a CLEARWIN_STRING@ seemed the logical thing to me.

My suggestion was simply to save myself the effort of timing all the mouse activity to work out what the heck is intended. I wouldn't have the cheeck to suggest that you do it - but since Clearwin has already done it, it didn't seem like a big deal to make the result available.

I had a little go with the extended cursor cross-hairs (viz: Set_graphics_selection@ (3) ) and found that a right-click would leave an imprint of where the crosshairs had been but a left-click didn't. That doesn't seem to be documented.

Regards

Eddie

The sample program that I posted is fairly comprehensive, illustrating that the callback is called repeatedly as the mouse moves and is clicked and illustrating how you can detect the current mouse state. If necessary you can keep the current state of the mouse buttons for comparison on the next call to the callback.

I cannot think of any further advice that I can offer. Also I cannot think of a way for ClearWin+ to provide you with further information. If you really need it, you could use %mg to detect mouse events directly but I do not see how this would help you.

If you do make any progress with this maybe you might like to report it here for the benefit of other users.

With thanks

Paul

Hi Paul,

I have modified your code thus:

c--------------------------------------------------------------- 
      include <windows.ins> 
      common mode
      external gr_func, tog_fn 
      mode = 1
      i=winio@('%ww[no_border]&') 
      i=winio@('%ca[Box Selection]&') 
      i=winio@('%mn[E&xit,&Toggle]&','EXIT',tog_fn) 
      i=winio@('%ob&') 
      i=winio@('%^gr[white,box_selection,full_mouse_input]&', 
     +         300,300,gr_func) 
      i=winio@('%cb') 
      end 
c----------------------------------------------------------- 
      integer function gr_func() 
      gr_func=2 
      end 
c----------------------------------------------------------- 
      integer function tog_fn() 
      include <windows.ins>
      common mode
      if (mode .eq. 3) then
          mode = 0
          else 
          mode = mode + 1
          endif
      call set_graphics_selection@ (mode)
      tog_fn = 2
      end

At the outset, because we have declared box_selection in the %gr format, a click-and-drag still draws the rectangle. ClearWin already knows how to sort out that an area selection has been made without testing for button press and release. To do so in Fortran code is re-inventing the wheel.

When one clicks the toggle menu I have arranged the program to step through the 4 possible options. With mode = 2, Clearwin also recognises that a rubberband line could be selected.

At this point, I stopped reading the manual, and experimented. This program is the result:

      winapp 
c--------------------------------------------------------------- 
      include <windows.ins> 
      common mode
      integer mstat 
      character*30 cstat 
      common/control/ mstat,cstat
      external gr_func, tog_fn
      mode = 1 
      i=winio@('%ww[no_border]&') 
      i=winio@('%ca[Box Selection]&') 
      i=winio@('%mn[E&xit,&Toggle]&','EXIT',tog_fn) 
      i=winio@('%ob&') 
      i=winio@('%^gr[white,box_selection,full_mouse_input]&', 
     +         300,300,gr_func) 
      i=winio@('%cb&')
      i=winio@('%ob[status]%20st%cb',cstat) 
      end 
c----------------------------------------------------------- 
      integer function gr_func()
      include <windows.ins> 
      integer mstat 
      character*30 cstat 
      common/control/ mstat,cstat
      common mode
      if (mode .eq. 0) then
          gr_func=2
          return
          endif
      call get_graphics_selected_area@(ix1,iy1,ix2,iy2) 
      write(cstat(1:30),'(4I7)') ix1,iy1,ix2,iy2 
      call window_update@(cstat)
      gr_func=2 
      end 
c----------------------------------------------------------- 
      integer function tog_fn() 
      include <windows.ins>
      common mode
      if (mode .eq. 3) then
          mode = 0
          else 
          mode = mode + 1
          endif
      call set_graphics_selection@ (mode)
      tog_fn = 2
      end

I had to put the mode=0 check into gr_func, otherwise the get... causes a program exit. With each mode change, the get_graphics_selected_area@ coords are all reported as -1. In mode=1 or 2, once a left-click has been done, a click-drag reports the start and finish coords, a left-click reports two pairs of identical coords, and a right-click is ignored. In mode=3, both left and right-clicks are ignored by get_graphics_selected_area@, and the -1's continue to be reported. The normal way of getting the coordinates for single clicks works.

Some further investigation looking for MOUSE_LEFT_CLICK and MOUSE_RIGHT_CLICK showed that MOUSE_RIGHT_CLICK is shown when the right mouse button is depressed, but every other callback gives a MOUSE_LEFT_CLICK message. The key seems to be in mode=1 and mode=2 to stop looking for MOUSE_LEFT_CLICK messages, but instead, to look for (ix1,iy1)=(ix2,iy2) as a way to find those single mouse clicks.

So, in answer to my original query, Clearwin doesn't require one to check for button_down and button_up. However, one still needs to have a way to discover that box selection is completed. I have discovered that this can be done because the coordinates reported by get_graphics_selected_area@ don't change.

I'll have to mull the implications of this over for some time!

Regards

Eddie

Your last post appears to incomplete. Also I am having difficulty in understanding what you are aiming to do. Can you describe the effect that you wish to achieve.

It was a long day yesterday, and I didn't notice that the post was truncated. I have contemplated redoing the post, but I'm even more confused after a day of contemplation and experimentation!

I think I will not bother you until I've fixed the problem, or have completely given up!

Eddie

Hi John,

I forgot about it. The point was to get the selection mode depending on which keyboard key was pressed while you did it, rather than choosing the selection mode before starting the click-n-drag operation. In the example, I used the menu item 'Toggle' to change the mode. A full implementation of this paradigm might be to have a palette of operations on a toolbar. When you select a particular operation (tool), then all the click operations and associated keypresses adopt the meanings for that tool. The now-no-longer supported DTP program Adobe PageMaker worked like that.

The other paradigm is not to require pre-selection of a tool, but to make the operation carried out solely a function of how one pressed a key in conjunction with a mouse movement and button click. This is what one does with a touch input with various swipes, pinches etc - all mapped conveniently by Windows into traditional mouse effects.

The graphics program I use (CorelDRAW) has a combination of toolbars (and mighty complicated ones too) and actions that depend on mouse movements etc.

Not that I can remember very well now, but I suspect that I was after effects like CorelDRAW, where not everything needed to be preceded with a 'tool selection'.

Everything is do-able with full_mouse_input, although that tends to overwhelm you with coordinates (see various points in posts in the past).

If you don't use full_mouse_input, then double_click is rather neutered, because it comes with a left_click before and after, which basically means that left_click has to be associated with something benign, or the last left-click operation needs to be undone if it is followed with a double click, and not be done at all if preceded by a double click. - That's another problem.

I went for the toolbar 'palette' option.

Eddie