N
news.bmsteamserver1
Hello,
Has anyone ever come across a ControlConverter, like the ComponentConverter
but clearly for Controls (and unlike the ComponentConverter can be used to
correctly adorn
ASP.NET control properties with the TypeConverterAttribute and actually
persist from designtime
through to runtime?)
I just spent ages writing one, to get a Property that holds a Control which
can be set at designtime a
nd at runtime the "same" (used loosely) control is returned from the
property. It works perfectly but its a little clunky from a purist
perspective because i can't access the
backing field for the property directly due to the way it works (see next to
see what i mean).
Consider:
private Control forControl = null;
[TypeConverter(typeof(ControlConverter))]
public Control ForControl
{
get
{
return ControlConverter.GetControl(forControl);
}
set
{
ControlConverter.SetControl(ref forControl, value);
}
}
Those method (GetControl/SetControl) calls are a way for me to easily create
new Properties in my propject without doing much by way of copy,paste, and
change - the
actual code in those methods is small and is not shown here - but clearly
the need for it highlights
that i can't access the forControl field directly in other parts of the
CustomControl to which this design time property belongs (i must go through
the
ForControl property). Ok, so me, i know this and it won't kill me, but like
i
said, it is clunky, and of course the knowledge of the above needs to be
transferred to other
people so they too won;t incorrectly access that backing field. I am quite
chuffed with the results, i.e it works,
but as any good developer knows, there is usually an even better way? ;-)
So my trouble is that after having used reflector to look a little at the
innards
of microsofts ComponentConverter i can't help think something is wrong when
i note it
extends from ReferenceConverter and my Controlconverter doesn't (ok i never
read what ReferenceConverter
does but i know it clearly doesn't facilitate moving that reference from
design to runtime cos otherwise the ComponentConverter would have been used
by me anyway cos Control implements IComponent and therefore i wouldn't have
had to attempt to write my own).
But then again i can't help but think that i did something right when i note
that the ASP.NET team didn't provide a
ComponentConverter that can persist that reference through from design to
runtime?
Am i missing something, is there some magical converter out there that i
missed?
Anyone written one without the dodgy backing field issue i mentioned above?
Cheers
Jason
Has anyone ever come across a ControlConverter, like the ComponentConverter
but clearly for Controls (and unlike the ComponentConverter can be used to
correctly adorn
ASP.NET control properties with the TypeConverterAttribute and actually
persist from designtime
through to runtime?)
I just spent ages writing one, to get a Property that holds a Control which
can be set at designtime a
nd at runtime the "same" (used loosely) control is returned from the
property. It works perfectly but its a little clunky from a purist
perspective because i can't access the
backing field for the property directly due to the way it works (see next to
see what i mean).
Consider:
private Control forControl = null;
[TypeConverter(typeof(ControlConverter))]
public Control ForControl
{
get
{
return ControlConverter.GetControl(forControl);
}
set
{
ControlConverter.SetControl(ref forControl, value);
}
}
Those method (GetControl/SetControl) calls are a way for me to easily create
new Properties in my propject without doing much by way of copy,paste, and
change - the
actual code in those methods is small and is not shown here - but clearly
the need for it highlights
that i can't access the forControl field directly in other parts of the
CustomControl to which this design time property belongs (i must go through
the
ForControl property). Ok, so me, i know this and it won't kill me, but like
i
said, it is clunky, and of course the knowledge of the above needs to be
transferred to other
people so they too won;t incorrectly access that backing field. I am quite
chuffed with the results, i.e it works,
but as any good developer knows, there is usually an even better way? ;-)
So my trouble is that after having used reflector to look a little at the
innards
of microsofts ComponentConverter i can't help think something is wrong when
i note it
extends from ReferenceConverter and my Controlconverter doesn't (ok i never
read what ReferenceConverter
does but i know it clearly doesn't facilitate moving that reference from
design to runtime cos otherwise the ComponentConverter would have been used
by me anyway cos Control implements IComponent and therefore i wouldn't have
had to attempt to write my own).
But then again i can't help but think that i did something right when i note
that the ASP.NET team didn't provide a
ComponentConverter that can persist that reference through from design to
runtime?
Am i missing something, is there some magical converter out there that i
missed?
Anyone written one without the dodgy backing field issue i mentioned above?
Cheers
Jason