Accelerator and Mnemonic Keys

A common practice in designing Windows GUI applications is to use mnemonic and accelerator keys for push buttons, menu items, check boxes and radio buttons. Examples might might include Alt+F for the File menu or Ctrl+P for a push button.

When you run the application in a browser, the browser application itself (i.e. Internet Explorer, Chrome, Firefox) will have its own set of short-cut keys. If the user enters a short-cut key combination that the browser accepts, then this function will be performed in both the browser and the Rapide application. For example, if your application uses Ctrl+T, then if the user enters this key combination, the specified function will be performed by the Rapide application AND a new tab will be opened since Ctrl+T is the keyboard short-cut in most browsers to open a new tab.

It is therefore recommended that you do not use mnemonic and accelerator keys in your application that conflict with the browser since the behaviour is unpredictable and will be confusing to the user.

The Rapide Generator plug-in Consistency Check will now warn you if you are using a conflicting mnemonic or accelerator key combination. The list of keys that the check uses are defined in a file that can be edited to provide your own specific list. 

Sorting Listbox Data

Since day 1 Rapide has provided a capability to allow users to sort the data in a desktop and browser listbox by clicking on the column heading. The actual sort logic is coded in an event in the Gen action diagram since this offers maximum flexibility for the developer, for example to provide complex sort logic involving multiple columns or even hidden columns.

The Rapide Designer now provides a utility tool to automatically generate the action diagram events for all relevant listboxes at once. This will allow you to easily support consistent sort functionality for all listboxes.

There are a few points to bear in mind when using sorted listboxes.

Firstly you need to decide if you will initially re-sort the data when the list is first displayed, or use the sort sequence from the logic that populated the group view, usually as returned from the server.

Secondly, when the data changes (for example you allow the user to edit rows or re-populate the listbox), you need to re-sort the listbox data. Since the Rapide generated sort event generates the sort string, this often simply requires you to include a SORT statement within any event that repopulates the group view.

Thirdly, if your listbox does not contain all of the possible data and a paging function is available, then you need to consider whether a sort function is appropriate.

Exit State CGVALUE

When you reference an exitstate in an action diagram or dialog flow, for example to test the value, you use a statement that references the exitstate name, for example:

IF exitstate IS EQUAL TO database_updated

The generated code does not test the exitstate name, instead it tests a special property of the exitstate called CGVALUE. The advantage of testing the CGVALUE is that this does not change if the exitstate name is changed or when the exitstate is migrated between models.

When you create an exitstate on the toolset, an initial value is assigned, but when the model is uploaded to the encyclopaedia, a new model-wide CGVALUE is assigned to the exitstate that will differ from the value initially assigned in the toolset. This means that any code generated on the toolset prior to re-downloading the model or subset will still use the old value but any newly generated code will reference the new value.

Therefore when you create a new exitstate, you should ensure that any code generated on the toolset that references the new exitstate is re-generated once you have re-downloaded the model/subset to ensure that the CGVALUE is consistent.

Rapide uses the CGVALUE in the window XML files and for externalising the exitstate messages in the strings file and hence you will also need to regenerate the Rapide window manager files and the strings file as well as the generated code.

Rapide Listeners

Listeners are a new feature in Rapide that can be used to synchronise common data between multiple windows, allowing dynamic applications where the displayed data is always up to date.

Sophisticated user interfaces that display the same data in multiple windows often need to have a mechanism to refresh the common data when it changes. In the past this has been difficult to achieve with CA Gen and therefore the developer either ignores the requirement or has to use complex logic to implement the refresh capability.

With Rapide, the developer can register a Listener on a specific object or multiple objects using wild cards or multiple Listeners. The Listener can then trigger an event when the object changes, thus enabling synchronisation of common data between multiple views of the same object.

For example, an order processing application contains multiple windows that display purchase order details.

• Each window that displays purchase order details registers its interest with the listener using an action diagram function
• When the purchase order details change, the developer uses an action diagram function to notify the listener that the object has changed
• The listener automatically posts update events to the interested windows which can then retrieve the details they require and update their display