subsystem=loc. This is being removed for the next release. When 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=locsurface 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 [firstname.lastname@example.org]
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.