Support Statement: Form uses stub controls and Designer Crashes
- Mark Juras
Q: I noticed the Forms Designer Crashes and the form migrates Threed.SSFrame to a stub control. Why?
A: Good question.
As you found, the reason your forms do not open in the designer is because the forms depend on the stub controls and until the project builds, those controls are not available and cannot be instantiated in the designer. The reason for these stubs as opposed to a fixed migration to WinForms reflects our belief that migration teams, not tool vendors, should ultimately decide what is in their translated code, and that once those decisions are made, the tools and methods must provide the flexibility and scalability needed to apply those decisions to very large systems automatically.
At this point, in the evaluation of gmStudio, you are looking at default translations. This evaluation aligns with using the tool according to our incremental migration methodology.
The generated code results are referred to as Standard Stand-Alone Translations as described here:
https://greatmigrations.atlassian.net/wiki/display/GMG/Incremental+Upgrade+Cookbook
For Standard Stand-Alone Translations, gmStudio migrates all external COM APIs/Controls to stub files in each project based on how the API/Control is used in the VBP. That is why references to the Threed.SSFrame control in the VB6 were migrated to references to a Threed.SSFrame stub control in the generated code. Note that most, but not all, intrinsic VB6 APIs/Controls are migrated to .NET directly, but some of them (e.g. DirListBox, FileListBox, OLE, Data, etc.) are also migrated to stub APIs/Controls. This behavior avoids assuming a single migration path for everybody. It can be applied generally, to all COM APIs/Controls, not just the ones that already have a potential replacement from Microsoft, Telerik, you or someone else. It even works for APIs/Controls that do not have a replacement in .NET such as your in-house APIs/Controls.
We believe the purpose of these initial, default translations should be for assessment and planning the “right way” your way for doing the upgrade, not for trying to rush into making the .NET code run. These initial translations are also easier to make build, because they do not depend on interop, or complex migration rules. The generated stubs are generated based on the needs of the legacy code. Furthermore, the initial translation are more direct, so they are easier to verify by comparison with the original codes.
In later stages of your migration project, the rules directing the translation may be customized to migrate your VB6 code to C# code that uses whatever .NET APIs/Controls you want, or you can “simply” implement the body of the stub files to provide runtime support for the new application. What matters is the upgrade team, not GM, decides the end point you will get from the tool. The upgrade team must decide what they want and gmStudio can help them get there.
Of course, some migrations (or stub implementations) are easier than others, just as some .NET application designs are “better” than others. There is a learning curve for doing things by tool, and there are different costs for doing things by tool or by hand, or a little of each. The actual costs and benefits for implementing a custom migration depend on many factors that each team has to estimate and manage for themselves.
Our standard samples show how to configure the tool to replace COM APIs/Controls with .NET APIs/Controls.
https://greatmigrations.atlassian.net/wiki/display/GMG/Samples
Some of the techniques used in the samples are described here:
https://greatmigrations.atlassian.net/wiki/display/GMG/Custom+COM+Replacement
If want gmStudio to migrate Threed.SSFrame to WinForms.GroupBox you need to tell it to do so. Some sample rules for this particular migration are here:
https://greatmigrations.atlassian.net/wiki/display/GMG/gmStudio+Extensions See THREED32.ocx.WinForms.Refactor.xml