RISC OS uses dragging in a consistent way throughout Desktop to provide a wonderful user experience. The Wimp provides an easy way to provide dragging within an application.
There are two main types of drag operations:
# | Operation | Description |
---|---|---|
1 | System | Used to drag a window’s position, size or scroll offsets. This is mostly used with windows that have no title bar, or those with no Adjust Size icon |
2 | User | Used for moving or re-sizing objects within a window |
The Wimp and the application must work together to allow dragging. A brief summary of how the Wimp and the application work together are shown below.
1 | User starts a drag using the mouse button (Select or Adjust mouse buttons only) |
2 | Wimp issues the Mouse_Click event code |
3 | Application responds to mouse click event code and initiates Wimp_DragBox to start the drag process |
4 | User ends the drag |
5 | Wimp issues a User_Drag_Box? to signal the end of a drag |
6 | Application handles the drag, ensuring the all related windows are updated correctly |
Window work areas and icons can be easily configured to respond to dragging. This is achieved by the Button Flags? within the window definition. The Button Flag tells the Wimp which (if any) button clicks and drags it should respond to.
Although a window or icon can be set to respond to drags, it does not exclude other mouse clicks. The result of this, is that the Wimp will still issue a Mouse_Click event code specifying a single mouse click.
Likewise, upon the end of drag the Wimp may issue a Mouse_Click event code specifying a Double Click. The Button flag specifies this.
Applications must ensure that windows are updated correctly during a drag. An object could be re-sized or moved within a window, or it could also be moved between windows themselves. Updating of a window should use Wimp_UpdateWindow.
Applications that require a drag to be confined to a window must handle the situation if the mouse pointer nears the edge of the window. i.e. scroll the window in the chosen direction or remain unmoved.
If a scroll has been initiated whereby the mouse button can be released afterwards, it leaves the possibility for further mouse clicks during a drag. e.g opening a menu etc.. . An application should be written to take into account this possibility.
To keep track of the drag, the application should stop following the drag on a Pointer_Leaving_Window event code, and start again on a Pointer_Entering_Window.