Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

VB6 Forms Upgrade Strategy

WinForms was not designed to be consistent with VB6 forms.  WinForms also reportedly has some glitches. The MigrationSupport.UI  framework attempts to address some of these inconsistencies, but it is a work in progress.  It does not yet, nor is it ever expected to, correctly emulate VB6 Form behavior under all possible conditions.  Upgrade project teams should expect to redesign their forms event handling, lifetimes, and state management to fit a new application architecture design that is compatible with .NET.  gmStudio can assist with the implementation of that new design from VB6 code if the upgrade team is able to clearly define the desired results and implement appropriate migration rules.

The WPF framework is much more flexible and powerful than WinForms.  Great Migrations' plan for solving the VB6 forms upgrade challenges is to promote the use of WPF as the target UI architecture.  WPF is also still improving and growing in popularity.  The business case for WPF as a target UI framework is stronger than for WinForms. Also WPF clearly requires a paradigm shift, so there is less chance of migration teams mistakenly expecting a relatively cheap, simple, automated upgrade right out of the box.

Regardless of which .NET Forms framework is used, and whether or not MIgrationSupport.UI is used, all upgrade teams should plan and allocate budget for significant research, analysis, coding, and testing to understand how their legacy code worked in VB6 Forms conventions and to ensure things work properly in the upgraded  .NET applications.

SubSystem=loc and MigrationSupportUI=on

Presently, MigrationSupport.UI.Form is automatically engaged with subsystem=loc.  This is being removed for the next release.  When using SubSystem=loc, MigrationSupportUI can, and typically should be suppressed by adding <Select MigrationSupportUI="off"/> to the compile command block in your translation scripts.  The gmStudio samples distributed with the 22-April-2016 release illustrate this technique.   If you are using SubSystem=loc and MigrationSupportUI=off,  you will also have to modify the Subsystem=loc surface forms for Form and MDI in the metalang files. 

See also this article on our web site: Runtime Library Requirements and Support

From: Andrés Meerhoff [ame@greycon.com]
Sent: Monday, May 02, 2016 5:28 PM
To: Mark Juras
Subject: RE: Issue with Form_Load event not firing

Let me check if I understand you correctly..

 

As we are using “loc”, are you saying that we should not use MigrationSupport.UI?

Is it fair to say that you don’t plan to do fixes inside MigrationSupport.UI?  (therefore this particular issue GREYC-126 won’t have a fix)

Yes, I am saying do not use the MigrationSupport.UI right out of the box.  And, if you can manage to not use it all, then do not use it at all.  If you must use it, then you will have to maintain the code.

And short answer is no, we are not presently planning any changes to MigrationSupport.UI.

The longer answer is that fixing MigrationSupport, including MigrationSupport.UI, is not part of standard support.  We normally work on MigrationSupport only in the context of funded projects or strategic samples or POC work.  And even in that context, only if we know the customer prefers to pay for making MigrationSupport work rather than paying for an upgrade design that does not use it.    Having said that, when a customer does fund improvements to MigrationSupport, they may be integrated into a future distribution.  

Right now, no one is funding for MigrationSupport fixes, and frankly, most people prefer code that avoids it.  That is why I removed it from the samples.  MigrationSupport.UI was not tied to loc until last year when Fred implemented the ability to stub loc; there were some things in loc that required it at the time.    But, as I said, I do not want to depend on MigrationSupport.UI -- I think it is way too complicated -- like MigrationSupport.ResumeNext which is another thing that I feel should be optional.  So, we are not planning MigrationSupport fixes, and we will only do them if there is a business reason (i.e. payment) to do so.  It's like our not investing in making interop translations better -- they are not typically desired, and they are difficult to solve in general; we make specific interop improvements for specific customers who want to pay for them.

 

 

 

  • No labels