Originally Released in December 2006, Hydra 3.0 marks a new direction of our well-received plugin framework. While previous versions of Hydra were targeted solely at Win32 Delphi developers and enabled them to build plugin-based systems for that platform, Hydra 3 widens the scope of the product by providing support for a new goal and target audience: Delphi/Win32 developers that seek to leverage the .NET framework in their application development.

A Brief History of .NET in the World of Delphi

Ever since it was originally announced, the Delphi community has had a love/hate relationship with .NET. Being spoiled by the richness in RAD development they had been enjoying for years, the community was quick to dismiss .NET as something that might bring benefits to MFC or Visual Basic developers, but would bring little benefit over Delphi and its powerful VCL class library and RAD form designers. Many also saw .NET as the latest development fad that would excite people for a while but quickly die out, for lack of serious adoption.

Three significant releases later, it has now become obvious that these assumptions were wrong. The .NET 2.0 core framework has introduced significant development advances in the .NET languages, such as Generics for example, that make .NET development attractive and, with the new services branded under 3.0, Microsoft has introduced a significant new paradigm for user interface design that is likely to revolutionize how tomorrow s desktop applications will look and feel. The third party market for .NET has developed strongly, with a vast range of professional components being available in all imaginable areas –  while at the same time the Delphi component market seems to be winding down, as many third party vendors scaling down their support in favor for .NET, or are leaving the market altogether.

Switching from Delphi/Win32 for .NET?

As developers eye the new features and technologies becoming available on the .NET side, it becomes an attractive option to leave Delphi behind and fully leverage the new platform for future development.

Unfortunately, this is not an easy decision for many developers, for a multitude of reasons. To start with, most developers are not in a vacuum and able to start fresh on a new project, but have existing code bases written in Delphi   either in the form of existing projects that need to be extended and maintained, or at least have large class or function libraries or base frameworks that are time-proven and well-tested. These days, while customers expect ever more features and better quality in less and less time, it is usually not economically feasible to just abandon the entire investment in existing Delphi code (often many thousands or even millions of lines of code), just to get the product to a new platform.

Just like Microsoft is not dropping everything and rewriting Office in .NET (as many .NET-skeptics often demand as a sign of Microsoft s trust in their own technology), most commercial Delphi developers can t afford to throw away their investment, just to start clean.

Embracing .NET with Delphi/Win32

This is the situation that triggered the initial idea for Hydra 3, little over a year ago: what if there was a way for Delphi developers to preserve their existing investment in solid, working Win32 code written in Delphi, but at the same time enable them to extend that codebase, using new .NET-based technologies? What if developers could use .NET, Generics, Windows Presentation Foundation, LINQ and all the other benefits of the .NET framework when writing new code for their applications, while keeping the existing parts of their application code basically untouched   without porting and retesting?

This is the vision that we had with Hydra 3.0, and that we're delivering on with its first release. After a few relatively simple (depending, of course, on project size and complexity) steps for adjusting an application s architecture to be open to extensibility (a process that we are covering in-depth from both the architectural and the technical side in our upcoming HY08 article), your Delphi/Win32 project can be seamlessly extended with new code written in either Delphi or .NET.

Among others, the following scenarios are imaginable:

• Keep your existing application base around indefinitely, but start writing some, most or even all new modules in .NET, to leverage new technologies.
• Migrate your application to .NET step by step, eventually resulting in a fully managed application (but at your own pace, and maintaining full functionality throughout the porting process).
• Keep using Delphi to write your application, but allow others (end users, out-sourced developers, etc.) to write plugins using .NET.
• Try out  .NET by adding minor new functionality to your application, allowing you to evaluate the platform without big risk or investment.

Because Hydra allows seamless mixing and matching of managed and unmanaged code, in any imaginable combination of the above, this gives you the flexibility to plan the move to .NET according to your own needs.

Hydra 3 supports all Delphi/Win32 versions starting with Delphi 6, as well as .NET 1.1 (in Borland Developer Studio), 2.0 and 3.0 (in Microsoft Visual Studio 2005). Developers do not need BDS to leverage .NET in their Delphi applications; this is supported for Delphi 6 and 7, as well.

But let us get a little more technical, and see how this works in practice.

Plugins

The foundation of Hydra s extensibility is based on the concept of  plugins . Most basically put, a plugin is simply an object that provides a certain functionality that your main application (the  host ) needs.

Plugins can be written using any of the supported development tools (Delphi/Win32 or any supported .NET language), and one or more plugin is usually compiled into a DLL, a so called  plugin module . A host application can load any plugin module, regardless of what platform it was developed with, allowing you to mix Delphi and .NET functionality in the same application.

In theory this can be any kind of functionality, but the most commonly used types are either  visual plugins  or  non-visual plugins , for both of which project templates are provided in the supported IDEs:

A visual plugin is a plugin that provides a user interface to be shown within the host application. When developing a visual plugin, a standard design surface (the VCL form designer for Delphi, or the WinForms and WPF/XAML designers for .NET) can be used to design the GUI in the familiar way.

The host can then embed the plugin into its own UI in any arbitrary way. How this will look will largely depend on the application   plugins can be shown on tab-sheets or in separate windows, or they can integrate seamlessly anywhere within a larger form. For example, the  Delphi WPF  sample we ship with Hydra 3 presents a standard VCL form, but a portion at the bottom of the form is used to show a .NET 3.0 Windows Presentation Framework based plugin that displays an graph leveraging the next generation display and animation technologies provided by WPF.

Note:  as the plugin can be embedded seamlessly into the UI, it is up to your host s decision whether the end user will be able to tell where the host ends and the plugin begins.

Non-visual plugins, as the name suggest, do not normally provide a user interface of their own (although it is entirely possible for a non-visual plugin to open dialog boxes or windows of its own), but instead will be used to perform other tasks or services needed by the host application (such as, for example, performing certain calculations).

Talking to Your Plugins via Interfaces

While Hydra s base library provides implementations for the most general tasks involved with working with plugins (example.g. embedding a visual plugin into your form), most non-trivial applications will need some application-specific communication between hosts and plugins. Going back to the  Delphi WPF  sample illustrated above, the host needs to inform the plugin of changes to its controls, so the graph can adjust accordingly. Plugins might also need to communicate back to the host, for example in response to user actions within the plugins UI.

This communication is handled with the use of custom interfaces that can be implemented on the plugin, the host or both, allowing the two to call each other. Plugins can implement interfaces to expose the functionality they are providing, just as the host can implement interfaces to make itself accessible to any plugin that is active.

To enable this communication across the boundaries of Delphi and .NET, the Hydra 3 IDE integration provides sophisticated support for converting interface declarations between the two development platforms. You can write your custom interface(s) using .NET code, and then import the DLL into Delphi to generate a Delphi unit with the appropriate interface declarations, or you can write your interface in Delphi, and then import the unit to generate code that compiles under .NET for any of the supported .NET languages).

With some restrictions as to the types that can safely be passed between platforms (which are discussed in more detail in the aforementioned HY08), you are free to define any and all interfaces you need.

You also have full flexibility as to which of your plugins implement what interfaces. For example, you might define a range of interfaces, and have every plugin implement a selective subset. Your host can then use the availability of certain interfaces to determine what functionality is or is not provided by a given plugin, or to decide which plugin to use in which context.

Actions

Another powerful feature that has been in Hydra since version 2 and that is seamlessly supported for .NET plugins in Hydra 3.0 are actions and menu merging.

Hydra allows plugins (both visual and non-visual) to define a list of actions (comparable to Delphi s Action Lists) as well as a partial menu and toolbar structure that places these actions. Host applications can choose to provide menu merging, allowing the actions defined in plugins to automatically show up in the host s menu and toolbar system, as the plugin is loaded.

Support is provided for the three most popular menu and toolbar systems in use for Delphi, the standard VCL menus, Toolbar 2000 and Developer Express  ExpressBars component suite. Support for custom or other toolbar systems can be easily added, if necessary.

As mentioned above, Hydra 3 supports seamlessly merging actions in menus and toolbars defined in both managed (.NET) an unmanaged (Delphi) plugins into the Delphi host.

Menu and toolbar merging is illustrated by the  Actions  sample that ships with Hydra, which has been expanded to include a new C# based plugin module to illustrate the concept.

Managing your Modules

For host applications, the Module Manager component is provided to perform the task managing plugin modules. Available on both the Delphi and the .NET side, you can use the module manager component to load the plugin modules you need. This is based on application-specific logic, which can be as simple or as complex as you wish, for example:

• simply loading a module with a specific name
• loading all modules from a specific folder
• using a configuration system to determine which modules to load

Once modules are loaded, you can use the Module Manager to query for available plugins, check what interfaces are implemented or which .NET attributes were attached to a given plugin, as well as create instances of the plugins you need.

Once again, differences between managed and unmanaged plugins are completely abstracted away and taken care of by the underlying library; your host can simply work with all plugins without ever knowing whether the plugin is implemented in Delphi or .NET (although it can of course find that out, if it needs to).

What s Next? / Managed Hosts

Hydra 3.0.1 is only the first of many planned releases for the Hydra 3 product, and we will keep expanding the library and provide more capabilities. For the first release, our main focus was on enabling the extension of existing Delphi/Win32 applications with .NET code, and we have met our target of providing the full development experience for this.

While the 3.0.1 release does provide support for writing managed (.NET) host applications that can use managed and unmanaged plugins, the current version does not quite provide all the advanced features (such as, for example, actions and menu merging) for this scenario, something that will be addressed in upcoming releases over the next months.

Our goal is that eventually managed and unmanaged hosts are just as seamlessly replaceable as the plugins are now.

The  mixed mode  sample that s shipping with Hydra 3.0.1 illustrates the current capabilities of mixing hosts and plugins at will; the sample provides host and plugin implementations for just about all supported platforms (Delphi/Win32, C#, Oxygene, Delphi for .NET), and almost* any combination of hosts and plugins can be loaded

*with some limitations; for example a .NET 1.1-based host compiled in Borland C#Builder or Delphi for .NET cannot load a .NET 2.0 based module such as the C# or Oxygene WPF plugin, for obvious reasons

Summary

We hope this article has given you a good summary of what Hydra 3.0 is, what goals we are trying to achieve with the product and how the various technical aspects come together to form a full Hydra application.

Please make sure to also review article for learning more on how to open an existing monolithic application up to Hydra, or how to architecture a new project with Hydra in mind from the start. Also stay tuned for more articles on Hydra coming up, covering some of the more technical areas in more detail.