ITpsViewSetup and ITpsViewActivation

© Copyri ght 200 7 - 2009 ABB . All ri ghts res erved.

3.3.6. ITpsViewSetup and ITpsViewActivation

An application that TAF needs to initialize must have a default (empty) constructor and must implement the interface ITpsViewSetup, which specifies the two methods Install and

Uninstall.

Install and Uninstall

Install is called when the application is created in TAF. The parameters are used by TAF and should not be modified. It is recommended to add code for further initiations and allocation of system resources in this method, e.g. load assemblies, open communication channels, etc.

When the user closes the application Uninstall is called. This happens right before the application is deleted. It is recommended to add code for disposal of system resources in this method, e.g. unload assemblies, close sockets, etc.

ITpsViewActivation

All custom applications should implement the ITpsViewActivation interface, which specifies the two methods Activate and Deactivate. These are used by TAF to notify applications when they get focus and when they lose it.

Activate and Deactivate

Activate is run every time the application gets focus. This happens at initialization, after the ITpsViewSetup.Install method has been run, and when the user presses the application icon in the task bar.

Deactivate, accordingly, is run every time the application loses focus. This happens when the user closes the application, before the ITpsViewSetup.Uninstall method has been run, and when the user presses another application icon in the task bar.

NOTE!

It is recommended to activate and deactivate timers in these methods. This way timers will not run when other applications are in focus, thus saving processor power. For the same reason, any subscription to controller events should be disabled in Deactivate and enabled again in Activate. Note that current values should be read before enabling the subscription. Simple code examples

This table shows the basic things that the ITpsView methods are used for in a custom appli- cation:

Method Usage

Install Create the Controller object: VB:

AController = New Controller

C#:

aController = new Controller();

3.3.6. ITpsViewSetup and ITpsViewActivation © Copyri ght 200 7 - 2009 ABB . All ri ghts res erved.

Activate Add subscription to controller event: VB:

AddHandler AController.OperatingModeChanged, AddressOf UpdateUI

C#:

AController.OperatingModeChanged += new OperatingModeChangedEventHandler(UpdateUI);

Deactivate Remove subscription to controller event: VB:

RemoveHandler AController.OperatingModeChanged, AddressOf

UpdateUI

C#:

AController.OperatingModeChanged -= new OperatingModeChangedEventHandler(UpdateUI);

Uninstall Remove the controller object: VB:

If Not AController Is Nothing Then AController.Dispose() AController = Nothing End If C#: if (aController != null) { aController.Dispose(); aController = null; } Method Usage Continued

3.4. Release upgrades and compatibility © Copyri ght 200 7 - 2009 ABB . All ri ghts res erved.

3.4. Release upgrades and compatibility

Why did RAB 5.08 enforce an upgrade to Visual Studio 2005?

Will a RAB application still work if the customer upgrades the robot system with the latest RobotWare release?

What happens if you develop a RAB application using the 5.11 release and the customer system uses RobotWare 5.10?

Such questions are dealt with in this section. Platform upgrades

The Microsoft platform that the FlexPendant uses still goes through major improvements, which ABB needs to take advantage of. This may concern performance or other issues. In RAB 5.08 for example, Visual Studio 2003 was no longer supported. It may seem that this was uncalled-for, but there are always reasons why such changes occur.

The Visual Design support for the FlexPendant SDK, had long been on the wish list. When Microsoft provided the support necessary to meet this need, with CF 2.0, an upgrade of the FlexPendant software platform was made. The development of the design support for FlexPendant controls for RAB 5.08 made a transition to Visual Studio 2005 necessary. NOTE!

RAB 5.10 supports Visual Studio 2005. RAB 5.11 supports VS 2005 and VS 2008.

Matching RAB and RobotWare release

You should be aware that the RAB SDKs are developed and tested for a specific RobotWare release. The general rule is therefore that you develop an application for a certain release. Compatibility between revisions is however guaranteed (e.g. RW 5.11.01 will be compatible with RAB 5.11).

RobotWare upgrades

At some time during the lifetime of your application, a robot system that your application targets may be upgraded with a later RobotWare version.

As for a FP SDK application this means that the runtime will change, i.e. the FP SDK assemblies located in RobotWare will be different from the ones that were used when the application was developed. Generally, the only way to be sure that the existing application will work with a newer RobotWare version is to compile the source code with the FP SDK version that matches the intended RobotWare version. Normally compilation succeeds without any code changes, as FP SDK 5.09 - 5.11 are fully compatible.

The PC SDK it is normally compatible with a newer RobotWare release. The PC that hosts the PC SDK application at the customer, however, still needs an upgrade of the Robot Communication Runtime, so that it matches the new robotware release. See ABB Industrial Robot Communication Runtime.msi on page 310If you decide to upgrade the PC SDK application, you must also remember to upgrade the runtime environment of the customer’s PC. See Deployment of a PC SDK application on page 309 for details.