Ruler Object Library: 2 Ruler Setup

For each ruler a geode displays, it will need to include three objects: an object of RulerViewClass to display the ruler, a RulerContentClass object to act as the top of the RulerView's visible tree, and a VisRulerClass object, the ruler itself. Also, the geode may wish to include some of the available ruler control objects.

The RulerViews should be alerted when the main GenView scrolls or scales, so set the GenView's GVI_horizLink and GVI_vertLinks to hold the optrs of the RulerViews. A RulerView to the side of the GenView should be linked by the horizontal link; a RulerView above or below the GenView should be linked vertically.

Each RulerView should have a RulerContent as its content. Set this up as you would a normal GenView/VisContent linkage. The RulerContent functions as a VisContent for most purposes; there is some subclassed behavior so that the VisRuler will be notified when the RulerView has detected a scroll or scale event.

A VisRuler should be the child of the RulerContent. If you have more than one VisRuler associated with a view, you should use the VRI_slave links to connect them. When one VisRuler receives certain messages, it will handle them and pass them on to whatever VisRuler has been designated in its VRI_slave field. If this slave ruler itself has a slave, then the message will be relayed again, and so on. Thus the application only has to send messages to one ruler, instead of to all of them. The ruler which is not the target of a VRI_slave link is the view's master ruler, and its VRA_MASTER bit should be set.

If the view only has one ruler associated with it, that ruler's VRA_MASTER bit should be set.

If you will use the ruler library's mouse constraint management support, then the VisRulers must be run in the same thread which manages the main content. The VisRuler messages which deal with mouse positions receive the mouse location parameters on the stack, and thus the handlers must be running in the same thread as the callers. This is not a major restriction: since mouse events are so common, sending them across threads to be processed would lead to slow, jerky responses.

Your application may also include other objects:

RulerTypeControl to allow the user to use different measurement units.
RulerGridControl to draw a grid on the main view to which the user may snap the mouse.
RulerGuideControl to allow the user to manage guidelines.
RulerShowControl to show or hide rulers. Because hidden rulers are set not usable, and thus do not work well with GCN, applications including a RulerShowControl need to do some extra work. This is not difficult, but exactly what needs to be done may vary between applications. For details, see RulerShowControl .
If you will be using any of the ruler controllers, you must provide a way to relay classed events to the VisRuler objects. Whichever object will have the target when the controllers send out their classed events must have a special handler for MSG_META_SEND_CLASSED_EVENT which determines if the message is intended for a member of VisRuler class, and if so passes it to the master VisRuler object. Note that if you are working with the grobj library, a targeted GrObjBody correctly relays classed events to rulers.

Finally, if you wish the VisRuler to take special action on certain mouse events (perhaps providing a mark on the ruler to track the mouse pointer's position), the GenView's content should intercept those mouse events and send messages to the VisRuler (again, the VisRuler at the top of the VRI_slave chain) with the requested action.

GEOS SDK TechDocs |

1 Ruler Features | Next:

3 VisRuler Instance Data