Almost from its beginning, GTViewer has been extendible with External Applications. These External Applications can be for tracing, data collection, importing data, data monitors, etc. GTViewer has been supporting External Applications though a technique called Dependency Injection. An External Application is written as a COM object with an interface to GTViewer; then entries in the .GTM File define the COM objects that can be used with the dataset. GTViewer dynamically adds the External Applications to its menus when the dataset is opened and will launch the External Applications when they are selected. The External Applications are run inside of GTViewer and appear seamlessly integrated.
In the past, almost all GTViewer External Applications were written in Visual Basic 6 (VB6). There were a few written in Visual C++ and even some written in Excel (VBA), but the majority were in VB6. Not only is VB6 getting a little long in the tooth (released in 1998), but Visual Basic .NET and the .NET Framework have finally gained acceptance as a development platform and the .NET savvy development crowd is rapidly growing.
Strangely enough, GTViewer has been able to support .NET External Applications all along, and GTI had even provided a template .NET application several years ago. However, until Microsoft ended its support for VB6 in March 2008, the idea of using .NET for the development of External Applications had gained little traction.
There are many advantages to using Visual Studio .NET when developing GTViewer External Applications. With Visual Studio .NET 2005 or 2008, the development environment alone is enticing enough to move from VB6 to Visual Studio .NET. The .NET Framework also provides many benefits from a developer’s point of view such as the Command Language Runtime, Advanced Memory Management, and a rich set of base classes to work with. GTViewer External Applications written with VB6 were also difficult to debug. The GTViewerAppDebugger control had to be used, and it had its own set of limitations. With Visual Studio .NET, the GTViewerAppDebugger is no longer needed and debugging an External Application has never been simpler.
The disadvantages of using Visual Studio .NET when developing GTViewer External Application are also worth mentioning. First, VB6 and VB.NET are similar, but definitely not the same. Some degree of learning is required when moving from one to the other. On the other hand, Visual Studio .NET is not limited to VB.NET and if a developer is more comfortable with C++ or Java, then C# is an alternative to VB.NET. However, the “.NET” part of these languages is still something that will need to be learned even if it is pretty easy to do. The second disadvantage is that the .NET Framework will now be a requirement for the external applications to run. While most machines will have some version of the .NET Framework installed already, the latest versions are usually not. You can, however, target the version of the .NET Framework you want your applications to use and can possibly eliminate this problem by using an older version of the .NET Framework that you know is already installed. In the worst case, you will simply have to deploy an appropriate version of the .NET Framework with your External Applications.
I have prepared a fairly detailed document (download here) describing exactly how to extend GTViewer with an External Application using Visual Studio .NET 2005 or 2008. This document goes through the standard items that will be required in all GTViewer External Applications written with .NET and also presents a full example. The example is the Highlight by Phase application which highlights all electric features in the view to a color corresponding to their phase. The example works with GTI standard Electric/Gas demo dataset, but it can be easily modified to work with most electric data.
No comments:
Post a Comment