Checking Forest & Trees Dependencies Using Internal Libraries

Products

• Cleverpath Reporter

Issue/Introduction

Introduction

With the recent expiration of support for CleverPath Forest & Trees 6.51 (July 25, 2004), application developers should be well advanced with their migration to CleverPath Forest & Trees 7.00. Utilizing features available in later releases could present a problem with backward compatibility should a user still be running with an earlier release. This article describes a solution to a problem when running an FTV which contains internal libraries requiring a later version of the F&T runtime.

Problem

Consider an FTV which uses the XML features provided in version 7.0 of CleverPath Forest & Trees. For modularity the FTV application has all the XML related functions contained in an F&T internal library (stored within the view file). The FTV loads and runs normally on clients with version 7.0 and later of the runtime. 

 

End of Life March 2012

 

Environment

Release:
Component: FTS

Resolution

Forest and Trees provides the "File('GetVersion')" method to check the version of the client at run time. Typically such version checking is performed in the "OpenViewFile" of an FTV.

However, in this case this is too late, as the F&T startup processing sequence always loads internal libraries first. On loading the internal library, F&T automatically attempts to compile the code. On successful compilation, the code is then run. Since the XML related methods fail to compile on version 6.51, the user gets the unfriendly "Formula Error" message box.

Also, it is not possible to do the version checking within the same internal function library, as it will still fail to compile, and never get around to perform the version check.

The solution to this problem is to introduce an additional internal function library which performs the version checking before any of the other internal libraries are loaded. Forest & Trees allows the developer to specify the order in which libraries are loaded by selecting an internal library and using the up and down arrows to change its loading order sequence (topmost internal library is loaded first).

 

By creating this internal library and positioning it first in the internal library loading sequence, it can perform the version check and inform the user of any version dependencies, prior to loading requisite dependent libraries.

The following "AlwaysFirst" internal library demonstrates how to perform a typical version check. In this case if the version criteria is not met, the user is warned with a message box.

 

For those wishing to cut and paste this sample code, the text is pasted below.

 

Running on version 6.51 of the client now generates the following more informative error message.

 

To keep this example simple, we have looked into checking the version of the client, as a pre-requisite dependency check. However, the developer should be aware that applications may also have dependencies on other optional add-ins (in this scenario FTWDOMS.FXA should also be checked on the client). This can be checked with the following snippet of code: