Hydra applications are made up of a host application that loads individual plugins, either installed as part of the host application or distributed separately. Host and plugins can (but do not have to) be written using different development platforms and UI technologies.
There are two distinct scenarios why you would want to leverage Hydra plugins in your application:
New in version 4, Hydra now enables you to create visual plugins using Silverlight and embed them in your WinForms, VCL or FireMonkey host applications. This allows you to share code between your Silverlight-based web application or your Windows Phone 7 app, and your desktop app; for example you might create a rich data entry form in Silverlight for your project's web front end and reuse the same form inside your desktop app, created using Delphi's VCL or FireMonkey, or using .NET's WinForms.
»» Silverlight plugins can be created in Visual Studio 2010 using C#, Oxygene for .NET and Visual Basic.NET.
Also new in version 4, we are introducing support for FireMonkey plugins and hosts created in Delphi XE2 or later.
FireMonkey is a new framework from Embarcadero for creating rich vector-based user interfaces and 3D graphics, similar to .NET's Windows Presentation Foundation, using Win32 or Win64 Delphi code.
Out of the box, Delphi does not support mixing the traditional VCL and FireMonkey in the same application, but with Hydra 4, you can now embed visual plugins created with FireMonkey in your VCL application, alongside all our other plugin technologies. What's more, you can also embed FireMonkey plugins in your WinForms based .NET host applications, as well.
For example, you might want to create a visual representation of a 3D model using FireMonkey rich three-dimensional options, and embed it into a more traditional line-of-business application built using the VCL or WinForms.
»» FireMonkey plugins can be created using Delphi XE2 or later and are supported for both Win32 and Win64.
Similar to the new FireMonkey framework, Windows Presentation Foundation (“WPF” for short) is a modern, vector based UI framework for creating rich and stunning user interfaces leveraging modern graphics and 3D effects; first introduced with .NET 3.0, WPF is slowly but steadily replacing WinForms as the standard UI model for .NET developers.
Hydra lets you embed WPF-based plugins into your VCL, WinForms and FireMonkey host applications. For example, you might want to create a visually rich chart view using one of the stunning charting components available for WPF, and embed it into an existing business application created with regular WinForms or VCL.
»» WPF plugins can be created in Visual Studio 2010 using C#, Oxygene for .NET and Visual Basic.NET, as well as any other CLR-compliant language available for the .NET Framework.
The Visual Component Library (“VCL” for short) has been the standard way for developing great user interfaces for Windows with Delphi since its first release in 1995, so it goes without saying that Hydra fully supports the creating of plugins using the VCL, both to be embedded in VCL hosts (possibly alongside other plugin technologies, such as WPF or Silverlight), but also in host applications created using the new FireMonkey or .NET's WinForms.
For example, you might have some existing user interface created in Delphi that you want to reuse in a new WinForms-based application without rewriting the UI and the underlying code in a .NET language; our you might wrap VCL code in a plugin to be used transparently and interchangeably with plugins created using .NET or FireMonkey, within a VCL application.
»» VCL plugins can be created with Delphi 2009 and later, as well as with Delphi 7 for legacy support. Starting with Delphi XE2, plugins can support Win64 in addition to Win32.
Although slowly being superseded by WPF, WinForms is still the default framework for building Windows user interfaces with the standard Windows widgets for .NET developers and provides a rich environment of first and third-party components for building application UI. Hydra lets you encapsulate WinForms UI in plugins and embed it in unmanaged Delphi VCL and FireMonkey host applications, as well as (usually alongside plugins created using the other technologies) in WinForms apps.
For example you might want to extend an existing legacy Delphi application by writing new code with .NET and WinForms and use it alongside your existing codebase – possibly with the long-term goal to port the existing portion of your application over to .NET piecemeal.
»» WinForms plugins can be created in Visual Studio 2010 using C#, Oxygene for .NET and Visual Basic.NET, as well as any other CLR-compliant language available for the .NET Framework.
In addition to all the visual plugin formats described above, Hydra also lets you create non-visual plugins that merely contain business-logic or other functionality that you might want to share between platforms. Non-visual plugins can expose their functionality using custom interfaces; they can be implemented using .NET or Delphi, and both kinds of plugins can be used in either type of host application.
For example you might have existing business code implemented in Delphi that you want to reuse in a new .NET-based application, without porting it to Oxygene or C#. Or you might have found some great open source code written in C# that solves a problem you need to solve, and you want to use that code in your Delphi-based application. Or maybe you want to implement some core business logic code in Oxygene, and then share it between your Adroid, Windows Phone 7 and Delphi applications.
»» Non-Visual managed .NET plugins can be created in Visual Studio 2010 using C#, Oxygene for .NET and Visual Basic.NET, as well as any other CLR-compliant language available for the .NET Framework.
»» Non-Visual unmanaged Delphi plugins can be created with Delphi 2009 and later, as well as with Delphi 7 for legacy support. Starting with Delphi XE2, plugins can support Win64 in addition to Win32.
Starting with Delphi XE2 (and later), Hydra supports the creation of plugins (and hosts) for the 64-bit Windows platform, using both the VCL and FireMonkey.
Within a single process, Windows does not allow the mixing of 32-bit and 64-bit code, so the bitness of host application and plugins has to match - a Delphi Win32 host application can only host plugins compiled for 32-bit, and conversely, a Delphi Win64 application can only host plugins compiled for 64-bit. Since .NET plugins are (by default) CPU-independent, they can usuallhy be hosted in either 32-bit or 64-bit hosts.
By default, .NET hosts can run under 32-bit and 64-bit, determined by the operating system platform and hardware they are being run on; depending on which bitness a .NET host runs under, it can only load Delphi plugins that match its bitness. To ensure unmanaged plugins can be loaded, they can either be provided in two versions, for 32-bit and 64-bit, respectively, or the managed host application can be forced to a specific CPU type using the appropriate flags in the managed host project.