Why are we including this section? This is for developers who are interested in what they are getting into if they choose to integrate with Inventu Flynet Viewer. Our simple message is that the generated code in a Flynet application is derived from real, production systems in use world-wide. It is constantly improved whether by fixing a lurker bug never revealed except after months of operation or by adding a new way to navigate screens that is easier to extend through object-oriented inheritance.
The code (and design) in the base framework is common to all features, such as WCF Web Services, managed with Inventu Designer Studio. It is driven by carefully-designed code generation logic and a large set of organized templates developed using the CodeSmith Code Generation product and designed to deliver high functionality proven in existing production applications.
Microsoft Visual Studio Targeted
The generated code is organized in a set of Visual Studio Solution and Project files organized by function and seperation of concerns. When a Flynet integration solution is generated, along with a Windows set of batch files for automated builds, the solution is also immediately ready to edit in Visual Studio.
Visual Studio and .NET Versions are supported as they are released. We started with VS2003 and are currently at VS2013 (VS2015 works fine). For .NET Framework support we actually started with Framework 1.1 and now provide Framework 4.5 as a targeting option. Of course, if you have a more recent release of Visual Studio, you can just load one of our solutions and upgrade it with no problem.
Use of Object-Oriented Inheritance
The generated c# code is organized in inheritable classes with user class "stubs" generated that provide an easy place to override generated code so that the overrides perform an enhancement without worrying about subsequent code generation. This is actually multiple in depth so that customization of, for example, navigation from a specific screen can be performed across the entire application or for a single, specific web service or screen user interface.
Navigation between screens is a challenging area for screen integration. The Flynet runtime framework employs an easily extended design that is both robust and flexible. As generated, analysis of an application's navigation nodes is performed so that when navigation from a specific screen is considered, the next step is part of a "least number of steps" approach.
Screen Reading and Writing
To insulate developers from the problems and issues surrounding where fields are located on screens, all screen reads and writes are handled by an architected, separated DLL managed by its own optional Visual Studio project. This is called the IOHelper class and has extensive tables and arrays designed to provide very high performance reading and writing while enabling simplified change management.
Because all screen reads and writes are contained in a separate .NET assembly, if a field moves on a screen, Flynet Studio can be used to update the field location and the IOHelper class regenerated directly from Flynet Studio.
Special Support for VT and other Character Protocols
The Framework and the properties it extends in Flynet Studio support robust keying strategies for character mode hosts.
Keying into a character-mode host, such as a UNIX, VMS or Pick application has challenges that must be recognized for a productive data entry environment. This includes such attributes as "Auto-Skip" which means if the field is filled with data, no TAB is necessary, as the host application tabs automatically. The Flynet Runtime Framework enables global settings on an application basis which can be overridden by screen and even field that affect how data entry works. Without this kind of attention to detail, keying into a character mode host can be extremely challenging. Let Flynet remove the challenge!
Screen Change Audit Feature
As an optional feature, the IOHelper class can be generated with support for detecting when a defined field has moved on a screen. This is optimized so that it has minimal impact on performance while providing a special, graphical report should a change be detected.
If a change is detected, the graphical report, which is a custom HTML page, is emailed to selected email addresses to alert system administrators and the development team that a change slipped through the change management process and the IOHelper class needs re-generation after editing the project in Flynet Studio.