Reason #11: Magic xpa Provides Better .NET Handling than C#.NET, So Why Convert?

20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting

Why bother with Magic eDeveloper, uniPaaS or Magic xpa conversion to .NET when Magic xpa provides better .NET handling than C#.NET? Let’s review how Magic xpa does a better job than C#.NET does with the underlying .NET framework itself:

.NET Integration

With Magic xpa you can embed and integrate any .NET control or assembly without writing line-by-line code to do so. You can control the look and feel of an application by directly placing new .NET controls as part of your user interface. You can also add-to the functionality of your app by integrating any form of .NET assembly. All you need to use the .NET functionality, is to have have .NET framework V2.0 SP1 (or above) installed on your machine.

Defining .NET Variables.

After loading a .NET assembly in Magic xpa, you will be able to more easily work with any of its objects and methods than a C# programmer can. With Magic xpa, .NET assemblies are loaded into the Composite Resource Repository (CRR). You can then define a .NET variable for use in Magic xpa and then add the variable to a form in your RIA or client-server application and set its properties.

Controlling .NET Properties.

When working with .NET objects they have properties such as free-form text, numerics, or objects. Magic greatly simplifies the property types that you need to worry about with .NET. With C#, for example, you might need to write 15 different pieces of code to deal with each of the various .NET types for numerics. Magic allows you to use any of these types and you don’t have to deal with the differences in them. The properties of a .NET object can view and use the properties development scenarios where you need these values, such as calculations, for a display in a Verify operation and so on. You can see the relationship between .NET types and Magic xpa types in the table below.

Corresponding Types

Magic xpa Type	.NET Type
Numeric	SByte, Byte , Int16, Uint16, Int32, UInt32, Int64, UInt64, IntPtr, UIntPtr, Char, Decimal, Single, Double, Float
Alpha	Unicode Char, Char[], String, StringBuilder
Date	DateTime
Time	DateTime, TimeSpan
Logical	Boolean
Blob	Byte, Byte[], Char, Char[], String, StringBuilder
Vector	ICollection (only from .NET to Magic xpa), IList and objects that implement Indexers through the usage of 'this' keyword. Only indexers that have integer indexes Magic xpa only converts simple vectors and not multi vectors

Using the DNSet() Function.

Now, instead of having to use C# to leverage the .NET framework, you can manage it using Magic xpa functions and expressions. The Magic xpa DNSet() function is so named because it allows you to set the properties of a .NET (.NET=DN) object. In addition, you can directly access .NET in the expression editor with the expression prefix DotNet.

Use .NET Aliases.

.NET naming conventions are long and obnoxious as many of the assemblies have a very long path. Magic xpa allows you to define aliases in .NET so you can access things more easily. With C#, you’re stuck dealing with the full text version. Magic xpa also includes a type-ahead / auto-complete capability but aliases often work better because too many .NET names have the same beginning. Unfortunately, in C# the use of .NET global namespaces can be even more problematic as they can become hidden. For example, in C# code, a namespace like Console resolves to TestApp.Console instead of to the Console type in the System namespace. Using System.Console still results in an error because the System namespace is hidden by the class TestApp.System. Ugh.

Using .NET Methods.

Most of the .NET objects perform a variety of actions such as trigger events and run methods. When using .NET within Magic xpa, Magic xpa can respond to the .NET events and can activate .NET methods.

Just like with Magic xpa objects, a .NET object can trigger events during runtime. When using a .NET object within Magic xpa, it is possible to handle the .NET event in a very similar way to handling a Magic xpa event. This means you can handle the various methods in the .NET object.

Using .NET methods in C# can get you in a world of hurt. When using normal C# events, registering an event handler creates a strong reference from the event source to the listening object. If the source object has a longer lifetime than the listener, and the listener doesn't need the events anymore when there are no other references to it, using normal .NET events causes a memory leak: the source object holds listener objects in memory that should be garbage collected. Then there is the question of whether registering and deregistering events is thread-safe. Unfortunately in C#, raising the event in a thread-safe manner is left to the programmer writing the code that raises the event, and this often gets done incorrectly. In fact, according to Microsoft C# experts, the raising code that's probably used the most is not thread-safe. Memory leaks abound in C# and that makes maintaining a converted application a total nightmare for both experienced and inexperienced C# programmers!

Trapping .NET Events.

As a Magic xpa developer, you are already familiar with event driven programming. With many .NET objects, you will find that they expose events that are triggered during runtime. Some common events are available in most .NET controls, such as OnMouseClick, and some others are unique to a specific control. In Magic xpa you can trap for .NET events and handle them in order to interact in specific ways with that .NET object. And of course, events can be propagated so that they can be handled by parent tasks as well. As stated previously, mishandled threads in C# can result in memory leaks. Inexperienced C# programmers will make all sorts of mistakes trying to overcome these limitations. For example, they may try removing the offending code around the .NET event call. But this does not decrease the number of race conditions in the code, and it does increase the number of crashes. Worse, doing so makes the race condition harder to detect by shrinking the window in which the race can occur without eliminating it. Ugh, I’m glad some people like C# because for obvious reasons Magic xpa developers will hate it!

Working with Constructors.

When a .NET variable is not placed on a form, it has not yet been instantiated, which means you should do so in Magic xpa using a “constructor”. A constructor instantiates and initializes an object. Constructors are methods in which the name of the method is the same as the class itself. For example, the StringBuilder object therefore has a constructor named StringBuilder(). The Magic University course “.NET Programming with Magic xpa” will provide the guidance you need to follow in order to place a constructor properly within an application. Unfortunately, in C#.NET you have to declare all variables including those placed on forms so…more work, more code, more headaches.

Defining a .NET Array.

A .NET array is similar to a Magic xpa vector. Therefore you will understand intuitively that an array is a variable that can hold multiple values of the same type. In contrast with Magic xpa vectors however, when working with .NET you need to predefine the number of cells, or elements that make up the array.

In Magic xpa, defining a .NET array is very similar to defining any other .NET object. To define an array in Magic xpa you simply add square brackets [] to the .NET Object Type. The size of the array, however, is declared by the object constructor.

Trapping Exceptions.

Error handling is essential to all forms of programming and using .NET programming in a Magic xpa application is no exception to that (pun intended). Magic xpa provides two internal functions for dealing with .NET exceptions: DNExceptionOccurred() and DNException(). By mastering the use of these functions, you will be able to trap errors and handle them appropriately.

Unfortunately, with C# beginners, exception handling becomes a nightmare. First of all, too many try to handle errors by catching non-specific exceptions, such as System.Exception, System.SystemException, and so on, in framework code. It’s meaningless. Furthermore C# programmers can make lots of mistakes by catching an exception and incorrectly specifying it when re-throwing the exception. This causes the stack trace to point to the re-throw as the error location, instead of pointing to the actual method location. The call stack of a C#.NET application is so complex that it is easy to overuse catch too early in the call stack before the error propagates up to a more meaningful position.

Using .NET Code.

In addition to working with standard .NET objects, methods and properties, there may be times when a Magic xpa developer wants to execute custom .NET code. Magic xpa allows you to write .NET Code from within your application by using the Invoke .NET operation. Magic xpa passes the .NET code to the CLR provided as part of the .NET framework. The compiler returns the compiled code back to Magic xpa and the Magic xpa studio saves the task source code. During deployment, the compiled code is passed back to the client and executed.

Enhanced .NET Capabilities

Magic xpa has many other enhanced .NET capabilities:

•      Variable Binding: Enables the binding of a Magic xpa variable to a .NET control.

•      Dataview Binding: Directly connects complex data-bound controls such as grid controls to the dataview definition of a Magic xpa program.

•      .NET in Table: Enables placing of .NET controls as automatically repeated controls inside a Magic xpa table control.

•      Colors and Fonts Assignment: Enables direct assignment of the Magic xpa colors and fonts setting to a .NET control.

•      Container Controls: Enable placing of Magic xpa controls inside third-party .NET container controls.

For additional information on how an upgrade is superior to Magic to .NET conversion please convert here.