Friday, 30 August 2013

Dynamic Feedback

When a transaction is initiated by the user that takes more than a few seconds to complete, it is good practice to provide status updates to the user to indicate that progress is being made and the transaction is still being processed.

For Windows applications, the developer can easily update a progress bar or status field and use the Gen REFRESH command to update the user interface to provide this feedback. This approach is often difficult to achieve on browser applications because the 'client' logic is executing on the application server.

The Rapide runtime has been architected to allow dynamic feedback during the execution of a transaction with a 'server push' approach where the Rapide runtime is able to send updates to the user interface without requiring user intervention on the browser. The Gen REFRESH command is supported and any updates to export views will be sent to the user interface to allow status updates to the user.

There is an example of this is in the demo application.

Thursday, 22 August 2013

Rapide Canvas Example

Another canvas control example has been implemented in the Rapide Controls demo. This shows a damage diagram for a car and has some controls to allow the user to specify areas that are damaged.

This is a good example of how use of a canvas is the best way of visualising data.

Wednesday, 21 August 2013

Rapide Browser Control

Rapide now supports the placement of a browser control in the window design. An example use of this is to support the display of PDF reports. Take a look at the PDF example in the Rapide Controls Demo.

Rapide Extension Libraries

A new feature in Rapide is the ability to directly access native Java libraries using Gen action diagram code. This makes it much easier to take advantage of a wide variety of Java libraries compared with using external action block code.

The first extension library developed is for the Apache PDFBox library which allows creation of PDF documents.

Additional libraries will be supported based on demand.

For more details, visit the Rapide web site.

Rapide Canvas Control

Canvas is a new type of control available in Rapide. A Canvas is a widget placed on the window that can then be 'drawn on' using action diagram functions and hence provides a more dynamic way of visualising data.

In the example below, a battery meter is drawn using a blank battery bitmap and a superimposed user drawn rectangle and text, with the width and colour depending on the charge level.

The action diagram code used to draw the battery is shown below.

Tuesday, 20 August 2013

Rapide Library Changes

The first implementation of the Rapide functions library used Gen functions which are implemented in the model using a custom function definition. In developing the functions, we found these to be rather restrictive since they are limited to a minimum of 1 parameter and a maximum of 5 parameters. In addition, change to the functions are distribution of new functions required maintenance of a separate functions model and adoptions / migrates to receive the changes.

We have therefore developed a new interface to the Rapide functions library that is implemented using methods and properties and coded in the model using dot notation statements.

The example below shows a simple action diagram that interfaces to the device camera.

Friday, 2 August 2013

Rapide Sashes

A new feature has been added to Rapide - a resizeable sash.

A sash is a horizontal or vertical control that is placed on a window and which can be moved in a vertical or horizontal direction by the user. The purpose of the sash is that other controls can be tracked against the position of the sash, for example to allow the user to adjust how much space is provided for a listbox.

In the example below, a vertical sash divides two list boxes whose sizes are tracked to the position of the sash.

Moving the sash control to the right adjusts the sizes of the listboxes since it is specified in the Rapide Designer that they track the position of the sash control.


Individual Model Backups

Whilst you should have a regular backup of the entire CSE (and GuardIEn) database for disaster recovery purposes, this backup would only allow you to restore the entire encyclopaedia.

What happens if you have a problem with one model caused by a corruption or 'user error'?

A common technique for backing up individual models from the CSE is to run a frequent download "with upload option" of the model to create an update.trn for the model to be used in case of an issue with the model. if you need to revert to the backup version of the model, you can rename or delete the current model and upload from the update.trn file created by the download.

A major problem with this approach is that it creates a new model in the CSE that does not retain ancestry with other models in the same project. You then need to adopt the model, which might be very time-consuming if it needs to be adopted to multiple models, and can also be error-prone since if any of the objects that previously had ancestry have since been renamed in one of the models, the adoption will not re-establish ancestry.

The technique that we use is to run an extract with apply option instead. This creates a child model which can then be loaded back into the CSE with ancestry retained. Child models are not very usable, so there is an additional step involved to copy the child model to create a full model and then delete the child model. However ancestry is retained.

At IET we have a weekend automated script (executed as a user defined task using the Task Assistant) that extracts all of our current models to a backup file as additional level of backup over and above the database backups and archive logs. Thankfully we have not yet had to use them, but it is comforting to know that they are available.