Designer: mysterious behavior with form constructers and static methods

[Sebastian Bargmann]

Hi,

[C# / VS2003]

I've run into a weird problem with the form designer. I have three classes:
a messagebox class and two forms (Base and Derived which is derived from
Base):

(note: only relevant code below)

<code>

public class MyMsg
{
[DllImport("user32.dll", EntryPoint="MessageBoxW",
CharSet=CharSet.Unicode, ExactSpelling=true,
CallingConvention=CallingConvention.StdCall)]
private static extern IntPtr MessageBox(UInt32 hWnd, string AText,
string ACaption, UInt32 AType);

public static void Show(string AText)
{
MessageBox(0, AText, "Caption", 0);
}
}

public class BaseForm : System.Windows.Forms.Form
{
public BaseForm()
{
InitializeComponent();

MyMsg.Show("Test");
}
}

public class DerivedForm : BaseForm
{
public DerivedForm()
{
InitializeComponent();
}
}

</code>

When I show DerivedForm in the designer my messagebox is shown. When I show
BaseForm in the designer, the messagebox is NOT shown. What gives?! Is this
a bug?

Are there any specifications of what and what isn't created/shown/whatever
designtime vs. runtime?

I know the above code doesn't really make sense, but its a simplification of
some similar code used for singleton patterns...


Regards,
Sebastian

 

[Frank Hileman]

Hello Sebastian,

When you edit a form or any other root component in the designer, the class
of the form is not instantiated. Instead, its base class is instantiated.
Something is needed to serve as the root component, but to obtain the latest
code from the InitailizeComponents method, which may not be compiled (the
form may not even be compilable), instead of instantiating the class you are
working on, the base class is instantiated, and the IntializeComponents
method is interpreted using a CodeDom interpreter built into VS. So only the
code in there will be interpreted, and of course the interpreter is somewhat
limited. This is why the message box appears when working on the derived
class: the base class code is actually run and not interpreted.

Regards,
Frank Hileman
Prodige Software Corporation

check out VG.net: www.prodigesoftware.com/screen5.png
An animated vector graphics system integrated in VS.net
beta requests: vgdotnetbeta at prodigesoftware.com

 

[Sebastian Bargmann]

Hi Frank - thanks for your answer,

So this behaviour is actually by design. I see...

One way to prevent the dialog (MyMsg.Show()) to be shown in the designer, is
to move it to the base-form's OnLoad method and then check the DesignMode
property (since DesignMode isn't valid in the ctor).

Are there other alternatives?


Regards,
Sebastian Bargmann

 

[Frank Hileman]

Sebastian, without knowing more about your specific code I don't think I can
give an intelligent answer. - Frank

 

[Sebastian Bargmann]

Hi Frank,

There really isn't any more to it than you have already seen. My real
problem is probably that I need to (well, I'd like to) know how code
behaves when run in the designer vs. "normal" run.

E.g. Are there any methods or properties on UserControl (or its parents)
that behaves differently when running in the designer (DesignMode is on such
property).

I have worked a lot with Delphi and VC++ and I'm used to be able to check
the source of VCL/MFC if there's something I don't understand. Apparanty I'm
not so lucky with dotNET...

Best regards,
Sebastian

 

[Frank Hileman]

Sebastian,

The behavior is as different as they make it. You can look at decompiled
code for MS stuff in Reflector (from Lutz Roeder, do a search). So the
difference can happen in several ways. One is the difference we already
spoke of. Another is checking for DesignMode, and executing different code.
This only works with components at the top level. For example, it would not
happen for the components in a UserControl, when the UserControl is
instantiated as a component in a Form. But it could happen for TabPages, for
example, in a TabControl.

Another complexity is property shadowing, replacing the real property with a
fake one in the designer. Or the designer can produce completely fake
properties. Then there are fake properties from ICustomTypeDescriptor. There
are ComponentChanged events. There many ways design-time code can behave
differently. If you search for articles by Shawn Burke and Brian Pepin in
msdn or the windows forms site you can read about all this.

In general, you should not make a lot of assumptions about differences
between design-time and run-time behavior. It is completely up to the
component author.

So without some specific scenario and problem in mind I cannot tell you the
best way to approach your problem.

Regards,
Frank Hileman

 

[Sebastian Bargmann]

Hi Frank,

Thanks for the hints and pointers - I'll read up on them.


Regards,
Sebastian