OpenInsight and .NET (Functions/Subroutines/Programs)

OpenInsight and .NET

By Bryan Shumsky

 

Over 25 years ago, Revelation became the first multivalue implementation on the IBM PC.  Different in design and approach from the other server-centric multivalue databases of the day,Revelation was a client-based database, tightly wedded to the PC.  As the product   and the PC - evolved,Revelation turned into Advanced Revelation, one of the first 4GL database environments, using the PC graphics to bring  windows  to application designers.  Advanced Revelation eventually grew into OpenInsight, a true Microsoft Windows design tool; it straddles the  multivalue and  GUI  worlds like no other product in our market.

 

OpenInsight, as  the  graphical multivalue database, has always had the ability to tie in to the latest features incorporated into Windows.  For prior,and current, releases, this has been accomplished through our OLE/COMintegration available in the Form Designer (our graphical layout tool) and programmatically (via the OleCreateInstance, and associated, commands).  With the release of Revelation Software's OpenInsight 9.0 Development Suite, this integration has been extended into the .NET environment.

 

An entire new range of functionality has been introduced by Microsoft with its .NET framework.  Originally announced in the late 1990s, released for beta in late 2000, and officially released in 2002, the .NET framework is a "virtual environment" in which applications written indifferent languages can run and inter-operate (communicate with each other).  .NET provides the underlying security, memory management, and  communication layers - the"framework" in which these programs exist.  With the release of the completely-rewritten 2.0 version in 2005, Microsoft accelerated its push, redirecting development from COM (Component Object Model) programs and controls to .NET (Note that, in.NET terminology, each "control" or set of functionality is called a"class"; multiple classes can be bundled together into a single"assembly" (typically a dll) (this is different from COM/OLE, where each control resided in its own file)).

 

 

Although still internally relying on COM to communicate with Windows, OpenInsight has been extended to allow .NET integration in three different fashions.  If you are a developer who is familiar with Visual Studio (Microsoft's development environment) you can, with some small effort, create "wrappers" around the .NET controls that you'd like to access from OpenInsight; or, if the Visual Studio programming languages and development environment are more appropriate to your application, you may create your applications entirely in Visual Studio and use OpenInsight as a data repository and application server through the use of the NETOI .NET assembly.  And of course, if you're most comfortable remaining entirely within the multivalue environment,you can use the RevDotNet API from within OpenInsight to create and control .NET classes.

 

Option 1: Wrapping .NET Controls

 

Using Visual Studio (2005 or above),it's possible to write your own .NET "custom controls" and have them accessible to COM applications.  This requires only a few additional steps:

 

- generating the GUID (Globally Unique IDentifier) values (figure 1a) for 3 "COMInterfaces" (figure 1b);

- Checking the "Register for COM Interop" checkbox (figure 2)

 

Figure 1a: Generating GUIDs from the Tools Menu

 

Figure 1b:  Setting the ClassId, InterfaceId, and EventsIdconstants with GUIDs

 

Figure 2: Registering for COM Interop

 

Once you have completed these steps,your custom control is now COM-compliant and can be used by any COM application- including OpenInsight and its Form Designer.

Developing a custom control can be very straight forward. You find a .NET control that you wish to access from within OpenInsight, create a new Custom Control project in VisualStudio, place the desired .NET control on your form, and then define any properties and methods you'd like OpenInsight to access.  The code in your custom control should then invoke the appropriate code in the .NET control.  If you desire, you can create properties and methods that are exact matches to the .NET controls'; however, you are not limited to doing this.  You can create your own properties and methods, including additional functionality in your custom control.  In this fashion, you can tailor your custom control to the needs of your OpenInsight application.

 

Once you have completed, compiled, and deployed your custom control, it will be accessible in the Form Designer; figure 3 shows how you can select the OLE Control from the palette, name the control on the Form, and specify your class name - and you should see your custom control appear on the form.

Figure 3: Inserting your custom control into the FormDesigner

 

Option 2: Developing .NET Applications

This turns the "integration with.NET" question on its head - rather than having OpenInsight control one or more .NET controls, you can code entirely in Visual Studio (or your development environment of choice), and develop a Windows application that uses OpenInsight as its data source.  The NETOI assembly contains classes to communicate with the OpenInsight Engine Server (the Server class); open and communicate with files (the OIFile class); and manage records and selectlists (the OIRecord and OISelectListclasses).  Using NETOI, you can perform all the basic file I/O needed to use OpenInsight.  Figure 4 is an example of some VisualBasic.NET code using these classes. In addition, the Server class allows you to invoke functions and subroutines on the host, as well as execute (and capture the results from) OpenInsight commands.

 

Figure 4: Using the NETOI classes inVisual Basic.NET

 

With this option, it is up to you, the developer, to decide where you want your logic to reside - either in VisualStudio (using OpenInsight to retrieve and update the records in your files), in OpenInsight (with your Windows application invoking the appropriate procedures in OpenInsight),or a combination of the two.

 

Option 3: Using RevDotNet

 

RevDotNet functionality is contained in a series of APIs that OpenInsight programmers can call to create and manipulate.NET classes.  These can be either visible classes (like Tree Controls, ListViewControls, etc.) or functional classes (like encryption classes, etc.).  You must first establish which assemblies you wish to use, and then you may create objects from the classes in those assemblies.  Once you've created an object, you can determine its methods, properties, events, etc., and invoke those methods, set and get those properties, register for those events,etc.  Figure 5 shows some of the Basic+code necessary to control the .NET ListView control.

 

Figure 5: Communicating with .NET through the RevDotNet API in Basic+

 

To assist you in navigating through the capabilities of the .NET framework, the DOTNETEXPLORER tool (figure 6) can be used to examine specific classes within any assembly.  Using the DOTNETEXPLORER, you can see a full list of the properties, fields, methods, events, and interfaces that a particular class contains; for visible controls, you can also manipulate the visible properties to see how changes affect the display.

 

Figure 6: DotNetExplorerInterrogation/Design Tool

 

Using RevDotNet,you use the familiar environment of OpenInsight to manipulate all the actions of the .NET control. Note that many of these actions are fairly complex, and thus do require a significant amount of code   some of which is hidden from you when the .NET control is used, for example, in the Visual Studio environment.  With RevDotNet, you get to see and control all the  behind the scenes  functionality.

 

How To Choose?

 

The choice of which .NET integration method is best depends on you (and your development team), as well as on the specific goals you wish to achieve.  If you wish to leverage an existing application with some new .NET functionality (either visible or functional classes), then adding RevDotNet into your application would be the easiest approach.

 

If the .NET control you wish to access is complicated to work with, containing dozens (or hundreds) of properties that you need to manipulate, along with sub-objects that need to be separately managed, you may find it easier to build your own custom control to serve as the  interface  between OpenInsight and the control.  While you can perform the necessary tasks using RevDotNet, the added functionality of Visual Studio  - especially including the  behind the scenes  ease of use features incorporated into Visual Studio   may make creating your own custom control the most effective approach.

 

If you are developing a new application from scratch, and your development team is more familiar with Visual Studio  and less familiar with the multivalue world   then using the NETOI assembly allows you to take full advantage of the strengths of your team without requiring a large training effort.

 

With OpenInsight s.NET integration strategies, you have the tools to make the choice that works best for you!

 

{{kb0259_8.png}} {{kb0259_9.png}}