Wimp.Drag

New Calls

        Wimp_DragBox

        *Configure WimpFlags

Wimp_DragBox

Entry: R1 <= 0 ==> cancel dragbox, else:
R1 --> block:
+0 window handle (for codes 1..4)
+4 reason code:
1 drag window position
2 drag window size
3 drag window horizontal scroll bar
4 drag window vertical scroll bar
5 drag box - fixed size
6 drag box - rubber box
7 drag point - invisible box
8 drag fixed box - user-supplied subroutines
9 drag rubber box- user-supplied subroutines
10 as (8), but don't cancel when buttons released
11 as (9), but don't cancel when buttons released
+8 initial position of drag box (x0, y0, x1, y1)
+24 parent box (other box restricted to this box (x0, y0, x1, y1)
this box is computed from the window data for codes 1..4
+40 R12 value to pass to subroutines (for types 7..11)
+44 address of subroutine to call to draw box
+48 address of subroutine to call to remove box
+52 address of subroutine to call to move box (<=0 ==> can't)
         User-supplied subroutines:
         Entry:  SVC mode, 
                 R0-R3 = new box coordinates (as derived by mouse movements)
                 R4-R7 = previous box coordinates (undefined unless moving)
         Exit:   R0-R3 = actual box coordinates (normally unchanged)

The new drag reason codes are 8..11, and the action of codes 1..4 has also changed. In the new Wimp, bits 0..3 of the configured Wimp flags determine the action of drag codes 1..4. If the equivalent bit in the flags is zero, the action is as before (on Wimp 1.20), but if it is 1, then the window is 'continuously' dragged, another Open_Window_Request being returned every time the mouse is moved, rather than just at the end when the buttons are released.

The new reason codes from 8 to 11 can be used for all sorts of effects, since the caller is free to supply any subroutines he likes to update the 'box' (or whatever it is!). Note that if a program wishes to drag an object across the Wimp screen while other tasks are running, it should use this facility to do so, since the Wimp will tell the application when to remove its 'object' due to other programs wishing to write to the screen - without this, it is not possible to maintain the screen display correctly in such an environment.

The Wimp performs its usual code to deal with rotating dot-dash patterns when calling user-supplied subroutines, so facilitating the drawing of arbitrary shapes using such patterns. The basic method is that the Wimp EORs the patterns onto the screen - if the box has moved, then there is nothing for it but to EOR the old box off the screen, followed by EORing the new box onto the screen, but if the box has not moved, then the Wimp reprograms the dot-dash pattern so that a single EOR of the box is sufficient to 'rotate' it. This means that the user-supplied 'move' subroutine must check to see if the new coordinates are different from the old ones - if they are, then it must EOR off the old box and EOR on the new, whereas if they are the same, it should simply EOR the box once. Note that the Wimp will have programmed the dot-dash pattern appropriately for this, so the result will not be correct unless this procedure is followed.

Of course, the subroutines supplied could also be used to manipulate a sprite around the screen, by saving the contents of the screen and restoring them appropriately. This is left as an exercise to the reader!