Home
Categories
Dictionary
Glossary
Download
Project Details
Changes Log
What Links Here
FAQ
License

UserInputs application



userInputs
Function invoke services or be notified from services
Distribution UserInputs-bin-.zip
Jar files userInputs.jar
Modules userInputs
Provided services through module configuration
Required services through module configuration
Optional properties triggered
blocking
keepHistory
historySize
showTimeStamp
timeStampFormat
filterEventsForHistory
guiPosition

The built-in userInputs application allows the user to invoke services or be notified from services manually.

Graphical interface


The graphical interface of the module has two panels:
  • The top panel presents the datas for the input or output services for which the userInputs is attached. This panel has two tabs:
    • The values for the datas for each service are presented. For services for which the userInputs application is notified, the last value is presented. For services for which application is a provider, an "Invoke" button allows to invoke the service with the last value fo the data
  • The bottom panel presents the notifications for services for which the userInputs application is notified

userinputs

Properties

GuiPosition property

The optional guiPosition property allows to specify the position of the userInput GUI. The format is <x position;>;<y position;. For example:
      <properties>
         <application name="userInputs" >
            <module name="userInputs" >
               <moduleProperty key="guiPosition" value="500;500" />   
            </module>
         </application>
      </properties>

Triggered property

The optional triggered enumeration property allows to specify in what cases the GUI will be updated when a service is received:
  • always (the default): the data content of each service will be updated whenever this service is received
  • event: only the data content of event Services and request-response Services will be updated whenever a service is received
  • never: the data content of a service will never be updated whenever this service is received
Note that the GUI is not updated when a service which is not selected in the GUI is received.

This property avoid to flood the GUI with notifications and updates if a service is very often notified (for example, a Position service which would be updated each 100 ms).

Blocking property

The optional blocking boolean property specifies if the update of the GUI blocks the execution (default is false).

History properties

Several optional properties allows to specify how the GUI will process several incoming services:
  • keepHistory: true if the content of incoming services at the time of the reception is stored. It means that that values of the datas at the time of the reception of the service will be memorized and shown when clicking on the service in the logger area (by default only the last value of the datas for the service will be shown)
  • historySize: the maximum size of the history (-1 is used for a history with no maximum size). it means that if new services are shown in the logger area after this size has been reached, older services will be removed and clicking on them in the area will show the last version of the datas rather than the one at time of the reception
  • showTimeStamp: true to show the timestamp of the reception for each service. The format of the timestamp depends on the timeStampFormat property
  • timeStampFormat: specifies the format of the time stamp
  • filterEventsForHistory: true if only event services will be kept for the history

Keeping history

It the keepHistory property is set to true, the content of incoming services at the time of the reception will be stored. It means that that values of the datas at the time of the reception of the service will be memorized and shown when clicking on the service in the logger area (by default only the last value of the datas for the service will be shown).

For example if you want to memorize the content for all notifications of a service, and the time stamp for each reception, you can specify the following properties:
      <properties>
         <application name="userInputs" >
            <module name="userInputs" >
               <moduleProperty key="keepHistory" value="true" />   
               <moduleProperty key="showTimeStamp" value="true" />  
            </module>
         </application>
      </properties>

TimeStamp

The showTimeStamp and timeStampFormat properties specifies if and how the time stamp of the reception for each service are shown in the Logger area:
  • showTimeStamp: true to show the timestamp of the reception for each service. The format of the timestamp depends on the timeStampFormat property
  • timeStampFormat: specifies the format of the time stamp
timeStampFormat value:
  • If timeStampFormat value is fromStart (the default), then the timestamp shows the time in seconds and milliseconds since the start of the framework
  • If timeStampFormat value is systemTime, then the timestamp shows the time in milliseconds using the system time (number of milliseconds since epoch)

Examples

The following properties file keep the history and shows the timestamp for services in seconds and milliseconds since the start of the framework:
      <properties>
         <application name="Inputs" >
            <module name="userInputs" >
               <moduleProperty key="keepHistory" value="true" />   
               <moduleProperty key="showTimeStamp" value="true" />  
            </module>
         </application>
      </properties>
The following properties file shows the timestamp in milliseconds using the system time:
      <properties>
         <application name="Inputs" >
            <module name="userInputs" >
               <moduleProperty key="keepHistory" value="true" />   
               <moduleProperty key="showTimeStamp" value="true" />
               <moduleProperty key="timeStampFormat" value="system" />   
            </module>
         </application>
      </properties>

Services

Only the services for which the userInput Module is a provider or subscriber will be taken into account[1]
There are no limitations on the types of services which can be provided or subscribed by the userInput Module
. For example:
      <interfaces>
         <subscribe service="aircraft" />
         <subscribe service="scenario" />
         <subscribe service="caslist" />
         <eventSend service="casactions" />
      </interfaces>

Using the Module to debug the usage of a Service

It is possible to use this Module to "debug" the usage of a Service, to listen to every notifications from this Service.

For example, in the following example, the "debugModule" will be notified from both the request and the response from the computeFlightPlan Service:
      <applications>
         <application name="aircraft">
            <modules>
               <module name="Display" >
                  <interfaces>
                     <requestSend service="computeFlightPlan"/>
                  </interfaces>
               </module>
               <module name="FlightManagementSystem"  >
                  <interfaces>
                     <requestReceived service="computeFlightPlan"/>
                  </interfaces>
               </module>
            </modules>
         </application>
         <application name="debug">
            <deployment>
               <lib url="userInputs.jar" />
            </deployment>
            <modules>
               <module name="debugModule">
                  <interfaces>
                     <listen service="computeFlightPlan"/>
                  </interfaces>
               </module>
            </modules>
         </application>
      </applications>

Showing ObjectType datas

The userInputs module allows to show the values of datas of the ObjectType type.

Notes

  1. ^ There are no limitations on the types of services which can be provided or subscribed by the userInput Module

See also


Categories: builtin-applis

Copyright 2017-2020 Dassault Aviation. All Rights Reserved. Documentation and source under the LGPL v3 licence