20 Reasons to Migrate Magic eDeveloper, uniPaaS and Magic xpa to .NET by Upgrading Rather than Converting
.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.
