 |
VR-Forces 5.0.2 Developer's Guide
|
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Properties Friends Macros Groups Pages
|
VR-Forces 5.0.2 Developer's Guide
|
When thinking of visuals and their creation, there are two types of visual containers.
Those visualizers that are created in the network thread Visualizers and State Listeners and have classes created from the agents to display network data and positioning on the map area. And those visuals that are created in the main thread (or, unpublished objects). This section deals with the unpublished local objects.
Local Objects are visualized in much the same way as objects from the network are visualized. A makVrv::DtElementDefinition for a particular entity type is looked up in the appropriate makVrv::DtEntityTypeMapper and then visualized using a makVrv::DtVisualizerSet. The difference between the network visualizer and the local object visualizer is that the actual vizualizer classes are maintained in the main thread, not the network thread. They are maintained and created by a makVrf::DtEntityFacadeCollection or makVrf::DtEnvironmentalFacadeCollection class (see ). These facades are created from the makVrf::DtGuiLocalObjectManager. The makVrf::DtGuiLocatlObjectManager is the place where you can create and modify visuals that are not published on the network (see Create Local Object in GUI (guiLocalCreateObject)). Each local object created will create a makVrv::DtStateView with makVrv::DtSimState data (for makVrv::DtVrlinkSimulatedEntityState or makVrf::DtVrlinkSimulatedEnvironmentProcess) to represent the data as seen on the "network" for the visuals. Any changes to the data via the state view or via the local object manager will result in a change in the visual on the map area. Following is code that is used to create an enviromental locally and an entity locally. Note that you do not need to do this (this is done by the local object manager) but is given as reference so you can see what is created to support the creation of a local object.
The makVrf::DtVrfObjectManipulationManager is the main class for creating or editing objects locally or on the network. The object manipulation manager will make use of the Local Object Management to create local representations of the objects before creating on the network or updating on the network. If the user has decided to create these objects locally only (which they can do for environmentals) then the objects will be maintainend in the local object manager. The object manipulation manager will use subclasses of makVrf::DtVrfObjectManipulationHandlerBaseClass to create and manipulate local representations of obbjects. These classes will implement specific API for sending create or update messages over the network for the particular entity being created or updating. The same handlers are used for creation and edting. The following handlers are currently registered:
The Custom Control Object (customControlObject) shows an example of how to intall a subclass of a handler to allow for additional data to be added or retrieved from a created object.
The flow of object creation comes from either the create menu, or, more likely, the creation palettes. Either method will ultimate call the makVrf::DtVrfObjectManipulationManager class create method. In the create method you pass an object type to create, a force, and a flag. The flags you can provide are:
A single local object is created for the object to be created. Once an object wants to be created, the handler that supports that object creation becomes the current handler being edited. Also, the makVrf::DtVrfObjectModifierDialogManager is notified of the creation or editing of an object so an appropriate properties dialog for that object can be displayed (Object Modifier Dialog Manager). When the user clicks the mouse to create the object for a single point *or double clicks for a multi point) object the createVrfObject method of the particular handler is called. At that point the creation flag and whether or not the object is going to be created locally or on the network is used to determine what happens. The typical action is the makVrf::DtGuiThreadVrfRemoteController is used to create the entity or environmental on the network. In the case of a single point object the user is kept in create mode until a right mouse click is given. In multi point object creation mode the object creation is stopped. Once the create operation is complete the local object is destroyed and only the network created objects will remain. There are a few signals you can connect to in order to be made aware of what is going on during the creation process. These signals are all sent from the object creation manager
When editing an object, the objects state view is retrieved (State View Collection Manager) and forced to update in order to get the latest object information. This is true for an object created on the network or created locally as the editing process is the same. Once the object data has been updated, the makVrf::DtGuiLocalObjectManager is used to create an exact visual copy of the object to use for editing and the original object hidden from the display. This is to allow editing of an object without having it change on the screen due to network changes. The Object Modifier Dialog Manager is also notified to present the correct dialog for object properties. Any changes made to the object are made in the objects facade so the user can see what will be reflected on the network. Once the user is done with changes and updates the object, the handler's modifyVrfObject method is called to either update the object on the network via the makVrf::DtGuiThreadVrfRemoteController or via the local object manager. Once the updates have been sent, a small delay in destroying the local object is introduced to try and give the network a chance to update on the network and then relect the objects data on the network before destroying the locally created object and showing the original. If there are times you see a delay in updates (i.e. via either an object move or other visual update) this is due to delay in receiving the update from the network.
vrfGuiVisualFacades Entity and Environmental Visual Facades The makVrf::DtEntityFacadeCollection and makVrf::DtEnvironmentalFacadeCollection are classes that are used to wrap makVrv::DtVisualizerSet classes and allow a higher level API for manipulation of these objects. The gui local object manager will keep a list of the state view and facades for any local objects that are currently in the system. While you can use the facades to change the view of these objects, it is recommended that you use the local object manager's update methods to do the actual update. This will change the state view, which will have the effect of also updating the visuals. Any changes to facades not made in the state data will be undone the next time the state view is updated. See Create Local Object in GUI (guiLocalCreateObject).
The makVrf::DtVrfObjectModifierDialogManager is a classes closely associated with the makVrf::DtVrfObjectManipulationManager class. When an object is to be created or edited there is also a property dialog that is created to allow for the editing of the various properties associated with an object (style, force, color, location, etc). The modifier dialog manager class is structured in much the same way as the manipulation manager in that there are dialog creators associated with object types that are to be created or edited:
The Custom Control Object (customControlObject) shows how you can replace a dialog with one of your own. You can replace the dialog creators by specific entity type or object class. The dialog manager will connect to the object managers various signals
in order to know when to show a particular property dialog. The manager will then use the makVrf::DtAutoHidePanel (see The Palette and Editing Panel) to add (or remove) a tab that will represent the new properties dialog being created. When the user presses this tab the associated property dialog will either be shown or hidden.