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.

Reason #10: Rapid Return on Investment (RROI) with Magic vs. Converting to C# 3GL

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

Building new software systems for businesses is a critical process and one that must complete in the least possible amount of time. Return on Investment is on the mind of every entrepreneur who has to sign off on a development budget to get new business systems in place that will deliver unique competitive advantage. So in today’s business climate, the emphasis is on rapid return on investment (RROI). The break-even point needs to be achieved at the earliest possible moment. Every cost has to be analyzed against the expected returns to arrive at estimated break even dates. So here’s reason # 10: Rapid ROI. The RROI you achieve with Magic is not possible if you convert Magic eDeveloper, uniPaaS or Magic xpa to C#.NET.  We’ve been talking about it for a long time at Magic. You can achieve ROI in your application development process faster and with greater assurance when using Magic than you can with C#, ASP or Java.  

Application development tends to occur in phases. For our purposes, let’s consider these four phases: Design, Build, Test and Deploy. When the pressure is on to create new business applications on demanding schedules, you need to have all four of these phases occurring almost simultaneously, but traditional computer programming tools do not allow this. All four of these phases require an investment of time, but if you can execute some of the phases in parallel, then you can get to the final destination faster. So with Magic testing isn’t something that happens at the end of a software process, it is an iterative process that occurs throughout the project. For this reason, it may be more useful to think of Design, Build, Test, Maintain not as phases, but rather as layers of the Magic development task. The design layer tends to be front-loaded in the project, but some design occurs while maintaining the program. The test layer tends to be back-loaded towards the end of a project, but using sound iterative design principles, testing definitely occurs throughout the life of the project. Time is money is perhaps a cliché but critical when discussing the ROI of business software development projects for new business systems. (Maintenance is another interesting topic that I will also address separately).

Application Development ROI calculations must put the emphasis on the investment that goes into dollars paid to the developers on the project; i.e. how many developers will it take and for how long? The sooner the project comes to a successful end, the faster the ROI for the project, and the sooner the new business can deploy their new systems and reap the benefits.

The time saved - hence the ROI - using Magic is significant: typically from 4 to 6 times faster than that of other development technologies.

The table at left is based on extensive market research and compares each of the four phases (layers) of the application development lifecycle for 3GLs (Third Generation Languages), 4GLs (Fourth Generation Languages) and Magic. If x, y, z, and w represent the time spent on an average 3GL application for each of the application development phases, research shows that generally 4GLs cut the time in half. With Magic even better time- savings are achieved. The productivity gains shown below are conservative calculations by Magic Software based on interviews with Magic programmers.

In order to achieve rapid ROI, each phase of the lifecycle must not only be completed quickly, but must also have the highest reliability to ensure the fastest payback for the investment being made. 

Magic’s progressive development paradigm allows prototype applications to be quickly and easily created. In fact, the Magic paradigm has often been used to convince venture capitalists and other investors that achievement of a new start-up business’ goals for new business systems is in fact achievable. Without Magic, some businesses might not even “get off the ground.” In addition, the ability to support applications over time despite changing business models, platforms, and standards is inherent in the Magic xpa Application Platform and earlier versions of Magic’s development and deployment technology.

Rapid ROI remains a key critical measure for every business from startups to established industry titans and is often the difference between success and failure. For additional information on how an upgrade to Magic xpa is superior to Magic to .NET conversion please convert here. 

Reason #9: C#.NET Manages Tab Order Poorly

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

Reason #9: C#.NET Manages Tab Order Poorly

C#’s idea of tab order is to set the tab order in the order that the controls were created. As we all know, from experience designing forms. Controls often get moved around and arranged. The desired tab order is not oldest to newest, its left to right, top to bottom in order of z-depth. Right?

So if you were to convert your application from Magic to C#.NET instead of from Magic to Magic xpa on .NET, you are going to have to deal with this illogical tab order going forward. This is just an example of the thousands of idiosyncratic weaknesses of procedural coding in C#.NET versus .NET platform-based development in Magic.

Here’s how it works in Visual Studio C#.NET:

In Visual Studio C#.NET, the tab order is the order in which a user moves focus from one control to another by pressing the TAB key. Each form has its own tab order. By default, the tab order is the same as the order in which you created the controls. Tab-order numbering begins with zero. Keep in mind that this is a gross oversimplification. What we can describe about C#.NET behavior in one paragraph takes more than 20,000 lines of code in C#. In fact, just control.cs alone is that size. Good luck Magic programmers if you have to debug that C# source code. And yes, there are bugs in it!

Here’s how it works in Magic xpa:

When working in Automatic Tabbing Order, Magic xpa creates tabbing identifiers for every control on the form of an Online or Rich Client task, maintaining a consecutive sequence from 1 to the last supported control, regardless of whether the control allows the user to park or not. For a Browser task, the Automatic Tab Order command is always automatic.

When you place a new control or move an existing control on a form, Magic xpa sets or changes the tab order by the control’s top, left location, and Z-Order. When the form is set aligned right to left, Magic xpa sets or changes the tab order by the top, right location, and Z-Order.

For example:

When you place the first control at 2,2, the tab identifier is set as 1. When you place the second control at 3,2, the tab identifier is set as 2. When you place the third control at 2,4, the tab identifier is set to 2 and the tab identifier for the second control is reset to 3. Removing a control shifts all consecutive Tab Order properties one value back.

When working in Manual Tabbing Order mode is not active, Magic xpa lets you enter a four-digit identifier or set an expression that returns a numeric value in the Tab Order property that lets Magic xpa determine the tabbing order for the control in relation to other controls on the form.

So out-of-the-box, Magic’s automatic tabbing order makes much more sense and you gain very straightforward programmatic control of tabbing order as well including being able to set the tab order with an expression! How cool is that? If you wanted to do that in C#.NET, you would have to write the underlying code that would do that and it would need to interact with that 20,000 line code base we mentioned. In Magic, the application platform provides that capability for the developer built-in.

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

Are you falling behind the times?

Trying to read documentation and get updated on your own can be tough. That's why we make it easy to learn how to migrate your applications from either eDeveloper 9.4  or uniPaaS 1.x to Magic xpa. I invite you all to Come to sunny Southern California the week of August 27 for Magic University training. The course schedule breaks down like this:

August 27-29  Migration from eDeveloper V9.4 to Magic xpa Enterprise Client

August 30        Migration from uniPaaS V1.x to Magic xpa V2.x

August 31            RIA Programming for Magic xpa Developers

Basically, the first four days are one course if you are migrating from 9.4 (or earlier). If you are already on uniPaaS V1.x, then you could just come for the last day, Thursday, although I think most will benefit from the entire four days. In the first three days of the course, August 27-29, you will learn about: The Magic xpa project paradigm; Magic xpa studio enhancements and features; data repository; task editors; expression editors; event-based logic; user-defined functions;GUI enhancements; subform controls; application migration; xml handling; use of external version control systems; and rich client applications.

On August 30, the focus will be on migrating to Magic xpa 2.x, additional GUI enhancements; GUI Frames; MDI; and the new open source end user functionality.

August 31 is the optional RIA day. This course will detail the RIA concept and architecture; explain the differences between client-server and RIA applications, detail the development, optimization, deployment and monitoring of RIA apps; provide guidelines for converting existing apps to RIA apps.

The optional RIA class day is $699. The main course from the 27-30 is free if you have a current M&S contract on an Enterprise Studio. The cost is $2,000 if you don’t. Please call your representative to make arrangements for the course. (949) 250-1718. 

A Collaborative Approach to Migrating Your Magic Applications

One of the most overlooked benefits of the Magic xpa Application Platform is the availability of professional services from Magic itself. When a customer has an older application – say one that was originally developed in eDeveloper or even an earlier version of Magic, these professional services can be especially useful.

Magic provides services that leverage automated tools for the smooth migration of Magic applications from version-to-version, database-to-database, and deployment-mode-to-deployment-mode. As experienced Magic xpa developers know, the Magic xpa Application Platform supports a wide range of deployment channels.

Magic helps you enhance and redeploy your Magic applications by efficiently managing the entire migration process from any version of your applications, platform infrastructure, or databases.

Our professional consultants can provide you with a migration needs assessment;  apply automated tools for SQL, RIA, web, and mobile migration; manage deliverables for a smooth and gradual migration path; and offer custom-designed migration projects suited to your application development preferences.

The flexible approach and extensive set of skills applied provide you with the application modernization you need at an affordable price. We leverage a well-established knowledge base of existing migration projects to streamline your project. We apply expertise and proven methodologies from these other projects in a way that is tailored to your application and needs. By leveraging the Magic professional services team, you are able to focus on new features and improvements related to your core application and deliver a complete new version of your applications in a fraction of the time.