Support Statement: VB6 Forms Upgrade Strategy

Forms Upgrade Challenges

WinForms breaks compatability with VB6 forms in many ways:

Object model and type system
- VB6 Forms: COM-based; controls are typically late-bound at runtime; variants are common; arrays of controls via control arrays.
- WinForms: Fully managed .NET types; strong typing and generics; no native control arrays (use collections like List<T>, FlowLayoutPanel, or custom containers).
Default instances and form lifetime
- VB6 Forms: Supports default form instances (Form1.Show without explicit instantiation); unloading via Unload Me; implicit global-ish access patterns.
- WinForms: Explicit instantiation (new Form1()); lifecycle via Show(), ShowDialog(), Close(), Dispose(); access is typically via references/DI rather than defaults.
Event wiring and handler patterns
- VB6 Forms: WithEvents and name-based handler conventions (e.g., Command1_Click); heavy reliance on implicit wiring by the designer/runtime.
- WinForms: Delegate-based events; handlers wired via designer-generated code or explicit subscriptions (button.Click += ...); more flexible but more explicit.
Layout and scaling
- VB6 Forms: Coordinates in twips; layout often absolute; scaling handled via ScaleMode and runtime behavior (frequently brittle across DPI/font changes).
- WinForms: Coordinates in pixels (logical units affected by DPI); supports Anchor, Dock, AutoScaleMode, layout panels; generally more resilient when used correctly.
Z-order and containment
- VB6 Forms: Containers exist (Frame, PictureBox) but patterns often assume flat placement; z-order issues handled through design-time ordering.
- WinForms: Clear parent/child containment model; z-order and tab order are explicit; nested containers and panels are common and expected.
Threading and UI responsiveness
- VB6 Forms: Single-threaded apartment model; background work patterns are limited; UI blocking is common.
- WinForms: Still single UI thread, but standard patterns exist (BackgroundWorker historically; Task, async/await); must marshal to UI thread (Invoke/BeginInvoke).
Resources and localization
- VB6 Forms: Resource handling is more ad hoc; localization often manual.
- WinForms: Strong designer support for resources (.resx), localization patterns (Localizable = true), culture-specific assemblies.
Designer and code separation
- VB6 Forms: Form definition is intertwined with code; designer edits the form file and code module in a coupled way.
- WinForms: Partial classes separate designer-generated code (InitializeComponent) from user code; conventions discourage editing designer code directly.
Tab order and focus navigation
- VB6 Forms: TabIndex is widely used and often set en masse in the IDE; TabStop exists; focus navigation is generally straightforward but can be disrupted by container boundaries (Frame/PictureBox) and control arrays.
- WinForms: TabIndex and TabStop still apply, but tab order is scoped per container (each Panel, GroupBox, TabPage, etc. has its own tab sequence); nested containers make tab flow more sensitive to parent/child structure, and the designer’s “Tab Order” tool is commonly used to manage it.
Font Inheritance
- VB6: No dependable cascading font inheritance. Fonts are typically set per control (often duplicated at design time), so achieving consistency usually requires explicitly assigning fonts across controls (including within containers).
- WinForms: Fonts generally inherit from the parent control/form through the containment hierarchy, unless a child control has its Font explicitly set (often by the designer), which effectively overrides and stops inheritance.

Options for solving form upgrade issues

Default Upgrade Solutions

Many of these details are handled automatically by the translator, however subtle differences can impact some UI behavior. Sometimes these matters will be accepted as user-training issues, but if this is not acceptable, it will be necessary to modify how forms work to more closely emulate VB6.

Custom Upgrade with Forms Redesign

Upgrade project teams may redesign their forms event handling, lifetimes, and state management to fit a .NET’s Winforms design on an as needed basis. If the upgrade team is able to define the changes needed to procudes acceptable forms behavior, gmStudio can assist with implementing the new design across many forms using custom rules.

gmRTL Forms Classes and Helper Methods

The gmRTL framework includes various helper methods and Form base class that more closely emulate VB6 forms, and this can be used as a starting point. The gmRTL Forms framework may also be extended to provide value added UI features such as Theming, Personalization, UI Activity/Performance Monitoring, and Security by integration with contemporary UI frameworks.

WPF and other UI Frameworks

The WPF framework is much more flexible and powerful than WinForms. gmStudio has a WPF-subsystem that supports translating to WPF rather than Winforms. The WPF migration is implemented in a gmPL extension using gmAPI. This code is available to upgrade teams who intend to do custom UI migrations. Contact us for details.