Is this a nested class? Some strange things like this happen when you nest
classes, structs or enums. If so, try moving it outside of any class, but
within a namespace.

--
Mick Doherty
http://dotnetrix.co.uk/nothing.html


"D.Z. Simpson" <d_z_simpson (AT) yahoo (DOT) com> wrote

Using the following ExpandableObjectConverter-derived class leads to a most
strange issue. The ConvertTo method receives an 'Object value' argument that
is supposed to be of my own Style class. That Style class is used as the
type of several properties in my custom control.

Now that works fine while there is only my control on a form. But after
another control of any kind is added, some strange things begin to happen -
from time to time the 'Object value' arguments passed to the convertor
cannot be casted any longer to the Style class - neither using
'(Style)value' nor 'value as Style' constructs. The funny thing is that the
watch in VS debugger really shows the value object as a Style instance with
all its members having appropriate values.

Can anyone please explain why ConvertTo is called with a value that cannot
be casted to my Style class, and still the debugger shows that value as a
perfect Style instance in the watch window? Thanks in advance, any logical
explanation will hopefully save me from utter madness.

internal class StyleConverter : ExpandableObjectConverter
{
public override bool CanConvertTo(
ITypeDescriptorContext context, Type destinationType)
{
if (destinationType == typeof(InstanceDescriptor))
return true;

return base.CanConvertTo(context, destinationType);
}

public override object ConvertTo(
ITypeDescriptorContext context, System.Globalization.CultureInfo culture,
object value, Type destinationType)
{
Style style = value as Style;
if (destinationType == typeof(InstanceDescriptor) && style != null)
{
ConstructorInfo info = typeof(Style).GetConstructor(
new Type[] { typeof(string) });

if (info != null)
return new InstanceDescriptor(info, new object[] { style.Store() });
}

return base.ConvertTo(context, culture, value, destinationType);
}
}

To be more precise, when there is a second control on the form the code
generation always passes that strange value to ConvertTo.

Style is a top level class, does not inherit anything and only implements
Cloneable. It has some fonts and colors as members.

"Mick Doherty"
<EXCHANGE#WITH (AT) AND (DOT) REMOVE.SQUAREBRACKETS.[mdaudi100#ntlworld.com]> wrote in
message news:uVx72Q4XFHA.2076 (AT) TK2MSFTNGP15 (DOT) phx.gbl...

In this situation you probably have two copies of your dll loaded. Both have
a Style class, but they are not considered the same class by the designer
(one loaded via LoadFrom, one via Load). Are you using reflection at
design-time on this dll? If so, eliminate that, as it will cause problems.

If not, try strong naming your dll and installing in the GAC. This will help
prevent it from being loaded twice. Also search for old copies of your dll
being referenced, possibly from a bin folder.

Regards,
Frank Hileman

check out VG.net: http://www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor

"D.Z. Simpson" <d_z_simpson (AT) yahoo (DOT) com> wrote

Thank you very much. Indeed it seems VS loads a second copy of the dll
that's referenced from the toolbox when I add additional controls to the
form. Otherwise it uses just one copy from the reference path of the project
and code generation works fine.

Now I have strong-named the assembly and everything works great, even
without installing to the GAC.

Thanks again.

"Frank Hileman" <frankhil (AT) no (DOT) spamming.prodigesoftware.com> wrote