Multi-Language Add-In for Visual Studio

This change works great, thanks!

Incidentally, I've wondered about the difference between VB and C# regarding the modifiers too. I think this was based on the fact that Microsoft originally wanted VB.NET to behave more like VB 6.0, where it was common to refer to controls on other forms — everything was "public". C# follows the standard encapsulation rules of OOP.

But this fails if your base form is a 3rd party form like DevExPress RibbonForm or XtraForm because these forms do not have a ml_updatecontrol sub...

Regards

> I have made a new change to the handling of inherited forms, in
> *version 4.01.0003 for VS 2003 and
> *version 4.54.0014 for VS 2005/2008
> The function ml_UpdateControls (used for runtime language switching) in an inherited form now includes a call to ml_UpdateControls in the base class.
>
> For example in C#
>

> protected virtual void ml_UpdateControls()
> {
>   this.Text = ml.ml_string ( 4, "Base Form" ) ;
>   BaseButton.Text = ml.ml_string ( 2, "Base" ) ;
> }
>

>

> protected override void ml_UpdateControls()
> {
>   base.ml_UpdateControls() ;
>   this.Text = ml.ml_string ( 1, "Derived Form" ) ;
>   DerivedButton.Text = ml.ml_string ( 3, "Derived" ) ;
> }
>

>
> or in VB.NET
>

> Protected Overridable Sub ml_UpdateControls()
>   Me.Text = ml_string ( 4, "Base Form" )
>   BaseButton.Text = ml_string ( 2, "Base Button" )
> End Sub
>

>

> Protected Overrides Sub ml_UpdateControls()
>   MyBase.ml_UpdateControls()
>   Me.Text = ml_string ( 1, "Specific Form" )
>   SpecificButton.Text = ml_string ( 3, "Specific Button" )
> End Sub
>

>
> Note that to handle this, ml_UpdateControls() is now defined as virtual (C#) or Overridable (VB.NET).
>
> In the current version, the call to ml_UpdateControls() base form is always generated, but I might make this an option in a future version.
>
> The behaviour of the controls scan is actually inconsistent for inherited forms. If you scan the controls via the designer windows, then the controls in a base form are also detected in an inherited form, and are therefore shown in the controls tab. If you scan via the source code (i.e. via InitializeComponent()), then inherited controls do not show up in scan results.
>
> On the whole, I would prefer not to show the controls from a base form in the inherited forms. This seems to contradict the whole idea of inheritance. However, I havn't yet come up with a simple way to detect which controls are inherited and which are not.
>
> If you scan controls via the designer windows, my recommendation is to translate the controls on a base form in the base form itself, and not in an inherited form. In the inherited form, you should not select these controls for translation.
>
> If you do select inherited controls for translation, there is a chance that the code generated in ml_UpdateControls will not compile properly, in particular in C#. This depends on the Modifiers property in each control on the base form. If this property is set to private, then you cannot access it in the inherited form. You can fix this by changing the Modifiers property, for example to protected. Curiously, the default in VB.NET is Friend, which allows access in an inherited class, but private in C#.
>
> Phil
>

Any news about this issue?

Regards