FlaUI Native Plugin

This plugin provides a newer alternative driver/application type for automation of native windows applications. The driver provided by this plugin is the same driver that is available as the default native driver built into Manatee v2.0+. For this reason, the FlauiNative plugin would generally only be of use in deployments of Manatee v1.28-1.29.

Example use cases

• When the automation you need to do is not possible in the original built-in native driver of Manatee up to v1.29.
• When you create new automation under Manatee v1.29 and you want to avoid using a plugin after upgrading Manatee to v2.0

This native driver is not fully compatible with fields and flows that were created with its predecessor. When switching existing fields and flows from the old to the new driver, thorough testing and some adaptation should be expected and planned for.

Loading the plugin

After Manatee has started up, it will need the plugin if applications are configured for it which require the new driver.

v1.29+

In v1.29+ there are two ways of automatically loading a plugin:

1. The Manatee setting PreloadedPlugins can be set to include the plugins to be loaded at startup. A possible value could be FlaUINativePlugin v0.0.9. There is sometimes some difficulty in managing manatee settings across a large organization if not all Manatees should run with the same settings. It may not be desirable for thousands of Manatees to load the plugin if only a handful of them need it.
2. A flow triggered to run after Manatee startup can load the plugin programmatically. For Manatee v1.29+ that might look as follows:

try {
  Plugin.start('FlaUINativePlugin', 'v0.0.9');
  Notification.show('started', 'Plugin started', 'FlaUINativePlugin v0.0.9', { timeout: 3 });
} catch(e) {
  Notification.show('fail', 'Plugin failed to start', e && (e.message || e));
}

v1.28

For Manatee v1.28 the only option is a flow loading the plugin - and a bit more code is required:

var version = '0.0.9';
try {
  Plugin.start('FlaUINativePlugin', 'v' + version, {
    '[eu.sirenia]CurrentWorkingDirectory': ('%appdata%\\Sirenia\\Manatee\\plugins\\FlaUINativePlugin\\' + version).toString(),
    MaxCacheHeatCount: Settings.Manatee.MaxCacheHeatCount,
    FieldCacheHeaterDelayInSeconds: Settings.Manatee.FieldCacheHeaterDelayInSeconds,
    MaxConcurrentTasksForWindowResolvers: Settings.Manatee.MaxConcurrentTasksForWindowResolvers || 20,
    WindowTextDeadlineInMs: Settings.Manatee.WindowTextDeadlineInMs,
    DefaultFieldCacheExpiryInSeconds: Settings.Manatee.DefaultFieldCacheExpiryInSeconds,
    DisableProcessCache: Settings.Manatee.DisableProcessCache,
    NativeAutomationTransactionTimeoutTimeoutInSeconds: Settings.Manatee.NativeAutomationTransactionTimeoutTimeoutInSeconds || 60
  });
  Notification.show('started', 'Plugin started', 'FlaUINativePlugin v' + version, { timeout: 3 });
} catch(e) {
  Notification.show('fail', 'Plugin failed to start', e && (e.message || e));
}

It is a good idea to keep the plugin loading flow in a headless app, which is then associated with the machines in need of the plugin along with the flow itself.

Selecting the driver in Cuesta

The driver provided by the FlaUI plugin can be selected like any other driver in the Cuesta app configuration page. It is shown with the name FlaUI Native.

Keep in mind that such an app configuration is only going to work on Manatees that have the plugin running.

Registering the driver

If Cuesta doesn’t offer the FlaUI plugin driver as an option it may be because the driver hasn’t yet been registered. This is done by starting the plugin in Manatee (eg from a flow), then finding the plugin in the right click Manatee menu:

This only needs to be done once for Cuesta to know about the new available driver. At this point, it will be possible on the application settings page in Cuesta to choose the app type provided by the plugin.

Known differences with older driver

The two native driver implementations mostly work the same but there are some known differences that may cause issues if automation created on one driver is switched over to the other. A few concrete differences are described below, but there may be more since the implementation of eg the various clicks, input, select and so on are achieved by different means than before.

Path interpretation

Path traversal when resolving fields has been changed in subtle ways. The aim is to align the path semantics in the native driver with that of the other drivers (eg java and browser drivers). This concerns the interpretation of the / level divider in a path. With the old native driver, the path Foo/Bar would search the entire sub tree under Foo for at match to Bar. The new driver will only search among the immediate children of Foo for a match to Bar. To look for Bar in the full sub tree under Foo, use Foo/**/Bar.

Inspect content

The specific properties in the objects returned by calls to the .inspect() method change somewhat between the drivers due to differences in the data provided by the underlying windows automation layers.

Releases

v0.0.9

Initial (public) release.