This section describes how to use the Vortex OpenSplice Modeler for generating DDS-compliant source code. The DDS code generated by the Vortex OpenSplice Modeler removes the need for programmers to manually write the DDS components of their applications; the Modeler does it for them using an easy-to-use, Eclipse-based graphical interface.
The OpenSplice HDE (version 6.1 or above) must be installed and configured in order to generate code for OpenSplice from Vortex OpenSplice Modeler. Vortex Lite (version 1.2 or above) must be installed and configured in order to generate code targeting Vortex Lite from Vortex OpenSplice Modeler. |
The principal purpose of the Vortex OpenSplice Modeler is to generate DDS-compliant source code. The Modeler achieves this aim and is able to generate:
The Modeler can generate code either at the Module or Application level. If a Module is exported, then this simply exports all Applications within the Module. This will automatically generate the Vortex OpenSplice IDL and typed interfaces for any data types used by that Application when generating code for an Application.
Code generation can be set to target either of the following DDS Implementations:
The code generated by the Modeler can be saved to either a Java or C++ Project within the user’s workspace.
These folders are created in Java-based projects:
These folders are created in C++-based projects:
Additionally for Windows, the code generated by the Modeler can be saved to a Visual Studio Project [1] .
The folders created are exactly the same as described above. However, additional Visual Studio-specific files are created that allow the project to be imported into Visual Studio. These files are:
For Visual Studio 2005 and 2008:
For Visual Studio 2013:
An application can be exported by:
Step 1
Right-clicking on the Application in the Project Explorer OR the Diagram Editor.
Step 2
Choosing Generate Application Code.
All of the Applications within a module can be exported by:
Step 1
Right-clicking on the Module containing the Applications to be exported.
Step 2
Choosing Export Module. The Export Application dialog will be displayed (whether one or more applications are selected for code exportation).
Export Application dialog
Step 3
The Project Name text box contains the name of the export project. Accept the default name or enter a new project name.
Step 4
Select the desired DDS target platform from the Target DDS Implementation drop-down menu.
Step 5
Select the desired target language from the Target Language drop-down menu.
Step 6
Step 7
When creating a project with a new name you can save the project in a location of your choice. Do this by using the Browse button or by directly changing the fields in the Directory text box.
Step 8
Check the Generate main method check box to generate a class containing a main method for the chosen language.
Step 9
The Language Options expandable gives additional options for the project creation.
Step 10
The IDL Options expandable enables you to export additional IDL Types that have not been associated with any entities in the model. To do this you must:
- Expand IDL Options
- Click the Add button
- Choose the IDL Types to be exported (supported Types are Struct, Constant, and Enum) in the Selection dialog
- Click the OK button.
Step 11
Click the Finish button to accept the options and export the Application.
The conditions and details relating to the generation of the Java source code for each model component is described in this section.
All generated entities (except Partitions, Topics, ContentFilteredTopics and code generated by the Vortex OpenSplice IDL Pre-Processor) exist in a single Java class file. This class file has the same name as the Application that it represents, and it contains static wrapper classes for all of the DDS entities contained by that Application in the model.
The class hierarchy within an Application class file closely follows the hierarchy which appears in the model.
The following conditions apply for all generated entities:
An Application component contains the configured DDS entities that you wish to use in your own application code.
Code can only be generated for modeled DDS entities such as DomainParticipants, Publishers, Subscribers, Listeners, DataReaders, DataWriters, Partitions, Waitsets and Conditions if they are contained or connected to entities within the Application component.
Each Application is generated into its own Eclipse Java project, with both project name and Java class name reflecting the fully scoped name of the Application in the model.
Example 1
For example, an Application called MyApplication located in the com/prismtech module would result in a Java project called MyApplication. Within that project, located in the generated folder, there would be a source file called MyApplication.java under the com.prismtech package.
There are a number of generated artefacts in the Application class, itself:
static classes for all Listeners, Waitsets and Conditions associated with the Application and its contained Entities
static classes for all DomainParticipants contained by that Application (these classes, in turn, contain static classes for the entities that they contain - this is explained in subsequent sections)
a static WrapperException Wrapper class for error handling at runtime
a start() method for creating and initializing all Entities contained by the Application
Although Topics and ContentFilteredTopics are not directly
contained within an Application, any DataReaders or DataWriters
that use them will create them.
a stop() method for deleting all Entities contained by the Application
The start() and stop() methods are used to control Application lifecycle. The start() method will configure and start all contained Entities, whilst the stop() method will attempt to cleanly shutdown the Application and delete all Entities.
Example 2
The following code would be used to start an Application called com.prismtech.MyApplication:
com.prismtech.MyApplication.start ();
Alternatively, the MyApplication class can be imported using a Java import statement, simplifying the code:
MyApplication.start();
All DDS entities contained by the Application should be configured and ready to use after invoking the start() method. The QoS Policy values for these entities will be set, according to values of their QoS Sets, and any default QoS policy values will be set on the appropriate Entities.
DomainParticipants are generated as nested static classes contained directly by the generated Application class.
A DomainParticipant wrapper class contains:
The getDomainParticipant() method will return the underlying DDS DomainParticipant Entity. This method is statically invoked.
Example
Continuing with the com.prismtech.MyApplication Application class example from above, if this class contains a DomainParticipant called MyAppDP, then the code to access the DomainParticipant would be:
DDS.DomainParticipant participant =
com.prismtech.MyApplication.MyAppDP.getDomainParticipant ();
The containing Application must have been started via its
start() method, otherwise a null object reference will be
returned.
The typed attach() and detach() listener methods are described under Listeners.
Publishers are generated as nested static classes contained directly by a generated DomainParticipant class.
A Publisher wrapper class contains :
The getPublisher() method will return the underlying DDS Publisher Entity. This method is statically invoked.
Example
Continuing with the com.prismtech.MyApplication Application class from above, if this class contains a DomainParticipant called MyAppDP, and a Publisher called MyPublisher, then the code to access the Publisher would be:
DDS.Publisher publisher =
com.prismtech.MyApplication.MyAppDP.MyPublisher.getPublisher ();
The containing Application must have been started via its
start() method, otherwise a null object reference will be
returned.
Subscribers are generated as nested static classes contained directly by a generated DomainParticipant class.
A Subscriber wrapper class contains:
The getSubscriber() method will return the underlying DDS Subscriber Entity. This method is statically invoked.
Example
Continuing with the com.prismtech.MyApplication Application class from above, if this class contained a DomainParticipant called MyAppDP, and a Subscriber called MySubscriber, then the code to access the Subscriber would be:
DDS.Subscriber subscriber =
com.prismtech.MyApplication.MyAppDP.MySubscriber.
getSubscriber ();
The containing Application must have been started via its
start() method, otherwise a null object reference will be
returned.
DataReaders are generated as nested static classes contained directly by a generated Subscriber class.
A DataReader wrapper class contains:
The getDataReader() method will return the typed underlying DDS DataReader Entity. This method is statically invoked.
Example
Continuing with the com.prismtech.MyApplication Application class from above, if this class contained a DomainParticipant called MyAppDP, a Subscriber called MySubscriber, and a DataReader called MyReader, then the code to access the DataReader would be:
<typed DataReader class> reader =
com.prismtech.MyApplication.MyAppDP.MySubscriber.
MyReader.getDataReader ();
The containing Application must have been started via its
start() method, otherwise a null object reference will be
returned.
DataWriters are generated as nested static classes contained directly by a generated Publisher class.
A DataWriter wrapper class contains:
The getDataWriter() method will return the typed underlying DDS DataWriter Entity. This method is statically invoked.
Example
Continuing with the com.prismtech.MyApplication Application class from above, if this class contained a DomainParticipant called MyAppDP, a Subscriber called MySubscriber, and a DataWriter called MyWriter, then the code to access the DataWriter would be:
<typed DataWriter class> writer =
com.prismtech.MyApplication.MyAppDP.MySubscriber.
MyWriter.getDataWriter ();
The containing Application must have been started via its
start() method, otherwise a null object reference will be
returned.
Listeners are generated as abstract nested static classes contained directly by the generated Application class. This class acts as a base class for the user’s Listener implementation.
The user must:
Each Listener class contains:
For each generated Application that contained Entities with
associated listeners, typed methods for attaching and detaching
listeners will be generated on that Entity’s nested wrapper
class.
The user must extend the generated Listener class, then instantiate the class within their own application code, and finally install the listener on the relevant entity via the appropriate typed attach() method.
Example
For a listener called Listener1, with an interest in the communication status on_data_available, the following base class would be generated:
public abstract class Listener1 implements DDS.DomainParticipantListener {
public final int STATUS_MASK =
DDS.DATA_AVAILABLE_STATUS.value;
public final void on_data_on_readers(DDS.Subscriber subscriber) {
}
public final void on_offered_incompatible_qos(
DDS.DataWriter dataWriter,
DDS.OfferedIncompatibleQosStatus status) {
}
public abstract void on_data_available(DDS.DataReader dataReader);
public final void on_requested_incompatible_qos(
DDS.DataReader dataReader,
DDS.RequestedIncompatibleQosStatus status) {
}
public final void on_subscription_match(
DDS.DataReader dataReader,
DDS.SubscriptionMatchStatus status) {
}
public final void on_requested_deadline_missed(
DDS.DataReader dataReader,
DDS.RequestedDeadlineMissedStatus status) {
}
public final void on_offered_deadline_missed(
DDS.DataWriter dataWriter,
DDS.OfferedDeadlineMissedStatus status) {
}
public final void on_sample_rejected(
DDS.DataReader dataReader,
DDS.SampleRejectedStatus status) {
}
public final void on_liveliness_lost(
DDS.DataWriter dataWriter,
DDS.LivelinessLostStatus status) {
}
public final void on_inconsistent_topic(
DDS.Topic topic,
DDS.InconsistentTopicStatus status) {
}
public final void on_publication_match(
DDS.DataWriter dataWriter,
DDS.PublicationMatchStatus status) {
}
public final void on_sample_lost(
DDS.DataReader dataReader,
DDS.SampleLostStatus status) {
}
public final void on_liveliness_changed(
DDS.DataReader dataReader,
DDS.LivelinessChangedStatus status) {
}
}
The user should then extend this class and implement the on_data_available() method.
If the Listener is attached to the DomainParticipant MyParticipant in the model, then within the class, for the application containing MyParticipant, we would find a static wrapper class representing MyParticipant containing the methods :
public static int attach (Listener1 listener);
public static int detach (Listener1 listener);
The user would instantiate the class that they implemented before passing the object reference to the attach() method to connect the listener. The user would call the detach() method to disconnect the listener.
WaitSets are generated as nested static classes contained directly in the generated Application class.
A WaitSet wrapper class has:
Example
Continuing with the com.prismtech.MyApplication Application class example from above, if this class contains a WaitSet called MyWaitSet, then the code to access the WaitSet would be:
DDS.WaitSet waitset =
com.prismtech.MyApplication.MyWaitSet.getWaitSet();
The Application must be running before the WaitSet is started.
Also, the WaitSet must be started using the start() method or a
null object reference will be returned by the getWaitSet()
method.
All Conditions are generated as nested static classes contained directly in the generated Application class.
A StatusCondition wrapper class has:
Example
In DDS, each Entity owns exactly one StatusCondition. Therefore, a StatusCondition does not need to be created, but only retrieved through the Entity which it is associated within the model. (Note that the start() method does not start the statusCondition; it just gets a handle on the DDS entity.)
Continuing with the com.prismtech.MyApplication Application class example from above, if this class contains a StatusCondition called MySC, a DomainParticipant called MyAppDP and a Subscriber called MySubscriber which is associated with the MySC, then the code for accessing the StatusCondition would be:
DDS.StatusCondition statusCondition =
com.prismtech.MyApplication.MySC.
getStatusCondition();
A ReadCondition wrapper class has:
Example
Continuing with the com.prismtech.MyApplication Application class example, if this class contained a DomainParticipant called MyAddDP, a Subscriber called MySubscriber, a WaitSet called MyWaitSet, and a ReadCondition called MyRC, then the code to access the ReadCondition would be:
DDS.ReadCondition readCondition =
com.prismtech.MyApplication.MyRC.getReadCondition();
All ReadConditions are created lazily when the getReadCondition() method is called.
A QueryCondition wrapper class has:
Example
Continuing with the com.prismtech.MyApplication Application class example, if this class contained a DomainParticipant called MyAddDP, a Subscriber called MySubscriber, a WaitSet called MyWaitSet, and a QueryCondition called MyQC, then the code to access the QueryCondition would be:
DDS.QueryCondition queryCondition =
com.prismtech.MyApplication.MyQC.getQueryCondition();
QueryConditions are created lazily when the getQueryCondition() method is called, like the ReadCondition.
The setQueryParameters() method must be called with the
appropriate argument before the getQueryCondition() method is
called, otherwise an exception is raised.
A GuardCondition wrapper class contains:
Example
Continuing with the com.prismtech.MyApplication Application class example, if this class contained a WaitSet called MyWaitSet, and a GuardCondition called MyGC, then the code to access the GuardCondition would be:
DDS.GuardCondition guardCondition =
com.prismtech.MyApplication.MyGC.getGuardCondition();
The GuardConditions are created lazily by the getGuardCondition() method.
The Java code for the Modeler Partition component (in the model) is generated as an abstract class; this class can be used to get and set a name in the Partition QoS of connected Publishers and Subscribers.
The generated Partition class is assigned the name of the Partition used in the name model.
A class containing static methods to get and set the name of that Partition is generated for each Partition connected to a Publisher or Subscriber, as defined in the model. The methods listed below are defined in this class:
The Partition wrapper class also contains the following methods:
Exceptions are used to handle errors in the Wrappers. Most Entity Wrappers’ methods can throw a WrapperException.
A WrapperException is thrown when an error is encountered while performing a DDS API call or, less frequently, when an internal error in the Wrapper occurs.
An example of the first case is when a Wrapper must create a DomainParticipant but a call to create_participant fails.
An example of the second case is when the user starts a QueryCondition Wrapper but the QueryParameters have not been defined.
In all cases, WrapperException provides enough information to know where the errors occurred; for example, what was the error code returned by the DDS call.
The WrapperException class is generated as a direct nested class in generated Application and Topic wrapper classes.
The C++ generated files are placed in a project’s generated folder. All modules, entities and other (scoped) items placed in this folder will correspond to a folder in the Project Manager tree.
All entity names are postfixed by the word Wrapper in order to
avoid conflicts between C++ name spaces and class names.
Three files are generated for each entity. Their filenames use a convention whereby they take the entity’s name and add it to a suffix associated with the file type. The generated files and their filename conventions are:
An abstract base class called Wrapper.h.
An entity called Publisher1, for example, would produce Publisher1Wrapper.h. Publisher1Wrapper.h is the interface that the application developer should use.
A class header file called WrapperImplementation.h.
Publisher1WrapperImplementation.h would be produced for a Publisher1 entity. This class implements the abstract base class and should not be used by application developers.
An implementation file called WrapperImplementation.cpp.
Publisher1WrapperImplementation.cpp would be generated for a Publisher1 entity. This file contains the class method’s implementations.
The following conditions apply for all generated entities:
An Application component contains the configured DDS Entities that you wish to use in your application code.
Each application is generated into its own Eclipse C++, Visual Studio 2005, or Visual Studio 2008 project.
For example, an application called MyApplication located in the com/prismtech module would result in a source file called MyApplicationWrapper.h in the com::prismtech namespace.
The Application class contains several generated methods:
The start() and stop() methods are used to control the Application’s lifecycle. The start() member function configures and starts all contained Entities, whilst the stop() member function attempts to cleanly shut down the Application and delete all Entities.
Example
The following code starts an Application called com::prismtech::MyApplication:
com::prismtech::MyApplicationWrapper* myApp =
new com::prismtech::MyApplicationWrapperImplementation;
myApp->start();
It is important to note that for all entities in the model, only
the generated abstract base classes (*Wrapper.h) should be
included in the business logic. The only exception is when the
application wrapper has to be instantiated, then the application
wrapper implementation header must be included. For example:
#include "com/prismtech/MyApplicationWrapperImplementation.h"
#include "com/prismtech/MyApplicationWrapper.h"
All DDS entities contained by the Application should be configured and ready to use after the start() member function is invoked. The QoS Policy values for these entities are set according to values of their QoS Sets. Any default QoS policy values will be set on the appropriate Entities.
DomainParticipants are generated in the <domainparticipant_name>Wrapper.h, <domainparticipant_name>WrapperImplementation.h and <domainparticipant_name>WrapperImplementation.cpp class files.
A DomainParticipant wrapper class contains:
The getDomainParticipant() member function returns the underlying DDS DomainParticipant Entity.
The get<entity_name>Wrapper() member function returns the modeled entity’s wrappers, which are then used, in turn, to retrieve the underlying DDS Entity.
The attach() member function can either be used on the corresponding wrapper class or on the desired DDS entity directly.
Listeners are described in Listeners.
Example
Continuing with the com::prismtech::MyApplication Application class example from above, if the MyApplication model contains a DomainParticipant called MyDP, then the code to access the DomainParticipant would be:
DDS::DomainParticipant* domainparticipant =
myApp->getMyDPWrapper()->getDomainParticipant();
The containing Application must have been started with its
start() member function or a null pointer will be returned.
Publishers are generated in the <publisher_name>Wrapper.h, <publisher_name>WrapperImplementation.h and <publisher_name>WrapperImplementation.cpp class files.
A Publisher wrapper class contains:
The getPublisher() member function returns the underlying DDS Publisher Entity.
The get<entity_name>Wrapper() member function returns the modeled entity’s wrapper, which is used in turn to retrieve the underlying DDS Entity.
The attach() member function can either be used on the corresponding wrapper class or called on the desired DDS entity directly.
Listeners are described in Listeners.
Example
Continuing with the com::prismtech::MyApplication Application class example from above, if this class contains a DomainParticipant called MyDP and a Publisher called MyPublisher, then the code to access the Publisher is:
DDS::Publisher* publisher =
myApp->getMyDPWrapper()->getMyPublisherWrapper()->
getPublisher();
The containing Application must have been started with its
start() member function or a null pointer will be returned.
Subscribers are generated in the <subscriber_name>Wrapper.h, <subscriber_name>WrapperImplementation.h and <subscriber_name>WrapperImplementation.cpp class files.
A Subscriber wrapper class contains:
The getSubscriber() member function returns the underlying DDS Subscriber Entity.
get<entity_name>Wrapper() returns the modeled entity’s wrapper with which the underlying DDS Entity can be retrieved.
The attach() member function can either be used on the corresponding wrapper class, or called on the desired DDS entity directly.
Listeners are described in Listeners.
Example
Continuing with the com::prismtech::MyApplication Application class from above, if this class contains a DomainParticipant called MyDP, and a Subscriber called MySubscriber, then the code to access the Subscriber would be:
DDS::Subscriber* subscriber =
myApp->getMyDPWrapper()->getMySubscriberWrapper()->
getSubscriber();
The containing Application must have been started with its
start() member function or a null pointer will be returned.
DataReaders are generated in the <reader_name>Wrapper.h, <reader_name>WrapperImplementation.h and <reader_name>WrapperImplementation.cpp class files.
A DataReader wrapper class contains:
The getDataReader() member function returns the typed underlying DDS DataReader Entity.
The attach() member function can either be used on the corresponding wrapper class or called on the desired DDS entity directly.
Listeners are described in Listeners.
Example
Continuing with the com::prismtech::MyApplication Application class from above, if this class contains a DomainParticipant called MyDP, a Subscriber called MySubscriber, and a DataReader called MyReader, then the code to access the DataReader would be:
DDS::DataReader* reader =
myApp->getMyDPWrapper()->getMySubscriberWrapper()->
getMyReaderWrapper()->getDataReader();
The containing Application must have been started with its
start() member function or a null pointer will be returned.
DataWriters are generated in the <writer_name>Wrapper.h, <writer_name>WrapperImplementation.h and <writer_name>WrapperImplementation.cpp class files.
A DataWriterswrapper class contains:
The getDataWriter() member function returns the typed underlying DDS DataWriters Entity.
The attach() member function can either be used on the corresponding wrapper class or called on the desired DDS entity directly.
Listeners are described in Listeners.
Example
Continuing with the com::prismtech::MyApplication Application class from above, if this class contains a DomainParticipant called MyDP, a Publisher called MyPublisher and a DataWriter called MyWriter, then the code to access the DataWriter would be:
DDS::DataWriter* writer =
myApp->getMyDPWrapper()->getMyPublisherWrapper()->
getMyWriterWrapper()->getDataWriter();
The containing Application must have been started with its
start() member function or a null pointer will be returned.
Each listener that is defined in the model has a file, <listener name>.h [2] , generated for it which acts as a base class for the user’s listener implementation. This class must be subclassed.
The generated class subclasses the corresponding entity listener from the OMG DDS DCPS API for the DDS entity that the listener is connected to in the model.
Function declarations are inserted as comments for all the enabled listener functions. These serve as an easy reference for what users must provide in their implementation.
The generated listener class also contains the status mask (as defined in the model). The value is accessible through the getStatusMask() member function.
A dummy implementation is inserted for all disabled listener member functions so these functions do not need to be present in the user’s listener implementations.
These listeners can be used by either invoking the attach() member function on the corresponding wrapper class or directly on the desired DDS entity.
When the listener must be attached to the DDS entity at its creation time, then the wrapper’s attach() member function should be used. In this case, it must be called before invoking start(), so as to be aware of all triggered events.
Please note that when calling attach() on the wrapper class, the
listener will be duplicated and held in a _var auto pointer.
Once the user’s code is not interested any more in receiving
notifications through a listener, detach() should be called.
Example
For a listener called Listener1, with an interest in the communication status on_data_available, the following base class will be generated:
#ifndef _MODULE1_APPLICATION1_LISTENER1_H_
#define _MODULE1_APPLICATION1_LISTENER1_H_
#include <ccpp_dds_dcps.h>
namespace Module1
{
namespace Application1
{
class Listener1 : virtual public DDS::DataReaderListener
{
public:
Listener1() :
m_statusMask(0 | DDS::DATA_AVAILABLE_STATUS)
{
}
int getStatusMask() const
{
return m_statusMask;
}
DDS::Boolean _local_is_a (const char * repositryID)
{
return false || DDS::DataReaderListener::_local_is_a (repositryID);
}
// DO NOT OVERRIDE THIS METHOD
// It is disabled in the status mask
void on_sample_rejected (DDS::DataReader_ptr dataReader,
const DDS::SampleRejectedStatus& status)
{
}
// Implement this method, it's enabled in the status mask
// void on_data_available (DDS::DataReader_ptr dataReader)
// DO NOT OVERRIDE THIS METHOD
// It is disabled in the status mask
void on_subscription_matched (DDS::DataReader_ptr dataReader,
const DDS::SubscriptionMatchedStatus& status)
{
}
// DO NOT OVERRIDE THIS METHOD
// It is disabled in the status mask
void on_requested_incompatible_qos (
DDS::DataReader_ptr dataReader,
const DDS::RequestedIncompatibleQosStatus& status)
{
}
// DO NOT OVERRIDE THIS METHOD
// It is disabled in the status mask
void on_sample_lost (DDS::DataReader_ptr dataReader,
const DDS::SampleLostStatus& status)
{
}
// DO NOT OVERRIDE THIS METHOD
// It is disabled in the status mask
void on_liveliness_changed (DDS::DataReader_ptr dataReader,
const DDS::LivelinessChangedStatus& status)
{
}
// DO NOT OVERRIDE THIS METHOD
// It is disabled in the status mask
void on_requested_deadline_missed(DDS::DataReader_ptr dataReader,
const DDS::RequestedDeadlineMissedStatus& status)
{
}
private:
const DDS::StatusMask m_statusMask;
};
};
};
#endif
// _MODULE1_APPLICATION1_LISTENER1_H_
The user should now inherit from this class and implement the on_data_available() method.
If the Listener is attached to the DomainParticipant Participant1 in the model, then within the generated wrapper implementation class, for Participant1, we would find a method:
virtual void attach(Module1::Application1::Listener1* listener) = 0;
The user would call the detach() member function to disconnect the listener.
Waitsets are generated in the <waitset_name>Wrapper.h, <waitset_name>WrapperImplementation.h and <waitset_name>WrapperImplementation.cpp class files.
A WaitSet wrapper class has:
Example
Continuing the com::prismtech::MyApplication Application class example from above, if this class contains a WaitSet called MyWaitSet, then the code to access the WaitSet would be:
DDS::WaitSet* waitset =
myApp->getMyWaitSetWrapper()->getWaitSet();
All Conditions are generated in the <condition_name>Wrapper.h, <condition_name>WrapperImplementation.h and <condition_name>WrapperImplementation.cpp class files.
It is important to note that before accessing the DDS Condition
with the getCondition() member function, the condition wrapper
must have been started with start(). If the condition is
attached to a WaitSets, it will be started upon the start of the
WaitSet.
A StatusCondition wrapper class has:
Example
Each Entity owns exactly one StatusCondition in DDS. Therefore, a StatusCondition does not need to be created, but only retrieved through the Entity which it is associated with, within the model.
Continuing the com::prismtech::MyApplication Application class example from above, if this class contains a StatusCondition called MySC then the code for accessing the StatusCondtion would be:
DDS::StatusCondition* statusCondition =
myApp->getMySCWrapper()->getCondition();
A ReadCondition wrapper class has:
Example
Continuing the com::prismtech::MyApplication Application class example from above, if the MyApplication model has a ReadCondition called MyRC, then the code to access the ReadCondition would be:
DDS::ReadCondition* readCondition =
myApp->getMyRCWrapper()->getCondition();
A QueryCondition wrapper class has:
Example
Continuing the com::prismtech::MyApplication Application class example from above, if the MyApplication model contains a QueryCondition called MyQC, then the code to access the QueryCondition would be:
DDS::QueryCondition* queryCondition =
myApp->getMyQCWrapper()->getCondition();
The setQueryParameters() member function must be called with the
appropriate argument before the getCondition() member function
is called or an exception will be raised.
A GuardCondition wrapper class contains:
Example
Continuing the com::prismtech::MyApplication Application class example, if the MyApplication model contains a GuardCondition called MyGC, then the code to access the GuardCondition would be:
DDS::GuardCondition* guardCondition =
myApp->getMyGCWrapper()->getCondition();
The C++ code for the Modeler Partition component (in the model) is generated in the Wrapper.h, WrapperImplementation.h and WrapperImplementation.cpp class files.
The generated code can be used to get and set the names of connected Publishers and Subscribers in the Partition QoS.
The generated Partition class is assigned the same name as the name of the Partition in the model.
This class defines the following methods:
Footnotes
[1] | Refer to the Modeler Release Notes for the Visual Studio supported versions. |
[2] | Where <listener name> is the name of the listener. |