Mercury Basics

Mercury will feel familiar and comfortable right away for developers familiar with Microsoft Visual Basic.NET, as well for existing Elements users who want to add the Mercury language to their portfolio.

For Veteran Visual Basic.NET Developers

For veteran Visual basic.NET developers, Mercury is the language you already know and love, and everything will work in exactly the same ways you expect – especially within the .NET platform. While Mercury has some Language Extensions, these are mostly all additive, and you can choose to learn and adopt them over time.

A slight learning curve will – not unexpectedly – be involved when taking Mercury to the other Platforms. Here, the language is still the same VB you know, but you will be dealing with new sets of Operating System APis and potentially different paradigms for UI development and other aspects of your projects, then what you are used to on .NET.

The optional Elements RTL library provides platform-independent abstractions for many common types and tasks that you might need in your day-to-day development (and might take for granted on .NET). What's more, it is largely models after simliar types from the .NET Base Library, so it will be instantly familiar to you.

Adopting it, over platform specific types (such as what the .NET Base Library provides), is a good idea if yu plan to take your code cross-platform, or even just want to work on a single platform but craving that extra bit of ".NET-like"-ness.

Elements RTL is available in all Mercury projects simply my Importing the RemObjects.Elements.RTL namespace.

For Users Familiar with Other Elements Languages

Users familiar with one or more Elements language also find that Mercury will work pretty much as they would expect. The same concepts such as References, Namespaces and Classes apply.

Simply adding a new .vb code file tom your project is all youn need to start using Mercury.


One thing worth noting is that Mercury code files do not need an explicit namespace declaration. Unlike C#, where types defined without a namespace are, indeed, namespaceless, Mercury works similar to Swift and uses the RootNamespace setting for these types. Unlike Swift, Mercury code files can optionally declare a namespace for the types they define and – unlike C# – when they do, this namespace is prefixed by the RootNamespace. You can prefix the namespace with Global. to avoid that.

As in all Elements languages, you can use a dotted name for types as you declare them, to override this and provide the full namespace for the class.


Mercury also has the concept of Modules. Modules are like static classes, but all their members are available as globals (i.e. accessible without the class name), if the Module is in scope. Modules defined in .vb code files will become available to all Elements languages, and you can use the newly introduced Module Aspect to implement Modules using the other languages, if you so desire.