Abstract User Control

  • Thread starter Thread starter Jeff Gaines
  • Start date Start date
J

Jeff Gaines

I am writing a couple of text editors - one for RTF, the other for plain
text.
It seemed a good idea to make the base class (inherited from User Control)
Abstract and then deriving the 2 editors from it each with slightly
different properties. That way I can't create an instance of the base
class, I have to choose from either a text editor or an RTF editor.

Does that design strategy make sense?

I have run into a couple of issues.
VS throws up an error in design mode saying it needs to create an instance
of the base class but can't because it is abstract. Should I just ignore
that? I'm not clear as to why it should need to create an instance of the
base class.
There is a property in the base class allowing the Status Strip to be
shown/hidden. It doesn't have a backing field, it just toggles the Status
Strip between visible or not. In my test app I have a tab control with an
instance of the RTF editor on one tab and an instance of the text editor
on another. When I turn on the Status Strip in one control it turns it off
in the other! I am struggling to get my head round that, surely changing a
property in a derived class shouldn't cause the change to propagate up to
the base and then back down to all derived classes?

Would appreciate any thoughts.
 
Jeff said:
I am writing a couple of text editors - one for RTF, the other for plain
text.
It seemed a good idea to make the base class (inherited from User
Control) Abstract and then deriving the 2 editors from it each with
slightly different properties. That way I can't create an instance of
the base class, I have to choose from either a text editor or an RTF
editor.

Does that design strategy make sense?
Click to expand...

It seems to work fine for TextBox and RichTextBox. I would think it
would work fine for you too if your controls were similar. But…
I have run into a couple of issues.
VS throws up an error in design mode saying it needs to create an
instance of the base class but can't because it is abstract. Should I
just ignore that? I'm not clear as to why it should need to create an
instance of the base class.
Click to expand...

If you don't need to do any designing of the class, it's not a problem.
But, the Designer needs an instance of the objects to work with if
it's going to let you actually do designing with them. Thus, it has to
be an object it can instantiate.

As long as you don't ever need to put an instance of the abstract class
into a designed control, it probably isn't a big deal.

You haven't explained why you're inheriting UserControl. I have seen
that done inappropriately far too often (i.e. when the base class really
should have been Control), and your post doesn't mention any specific
functionality you're getting from UserControl that would justify its
use. But if you don't really need to inherit UserControl, that would go
a long way toward dealing with the error, because then the Designer
would never even think there might be any reason to instantiate the
abstract control itself (i.e. because there's no design work to do in
the abstract control).
There is a property in the base class allowing the Status Strip to be
shown/hidden. It doesn't have a backing field, it just toggles the
Status Strip between visible or not. In my test app I have a tab control
with an instance of the RTF editor on one tab and an instance of the
text editor on another. When I turn on the Status Strip in one control
it turns it off in the other! I am struggling to get my head round that,
surely changing a property in a derived class shouldn't cause the change
to propagate up to the base and then back down to all derived classes?
Click to expand...

Surely not. So obviously the two are linked somehow that you haven't
identified. But, without a concise-but-complete code example, it's not
possible to point to any specific problem.

Note that in the description above, you haven't even explained whether
the problem you're seeing occurs at design-time or run-time, nor how you
observe the problem (since you can't see both tabs at once). A complete
problem description would include not only the code required to
reproduce the problem, but a clear, specific, unambiguous description of
exactly how to reproduce and observe the problem.

Pete
 
It seems to work fine for TextBox and RichTextBox. I would think it would
work fine for you too if your controls were similar. But…
Click to expand...

They are identical except one loads RTF files and the other plain text
files. One of the toolstrips that deals with formatting is hidden in the
text editor.
If you don't need to do any designing of the class, it's not a problem.
But, the Designer needs an instance of the objects to work with if it's
going to let you actually do designing with them. Thus, it has to be an
object it can instantiate.

As long as you don't ever need to put an instance of the abstract class
into a designed control, it probably isn't a big deal.

You haven't explained why you're inheriting UserControl. I have seen that
done inappropriately far too often (i.e. when the base class really should
have been Control), and your post doesn't mention any specific
functionality you're getting from UserControl that would justify its use.
But if you don't really need to inherit UserControl, that would go a long
way toward dealing with the error, because then the Designer would never
even think there might be any reason to instantiate the abstract control
itself (i.e. because there's no design work to do in the abstract control).
Click to expand...

OK - I need a design surface to hold toolstrips, a status strip, another
control based on a Rich Text Box. With that sort of variety I think a User
Control is probably the way to go. Perhaps I have to accept that a control
that can be designed shouldn't be abstract? Interestingly the base class
itself shows up fine in the designer, it would be hard to design otherwise
:-)
Surely not. So obviously the two are linked somehow that you haven't
identified. But, without a concise-but-complete code example, it's not
possible to point to any specific problem.

Note that in the description above, you haven't even explained whether the
problem you're seeing occurs at design-time or run-time, nor how you
observe the problem (since you can't see both tabs at once). A complete
problem description would include not only the code required to reproduce
the problem, but a clear, specific, unambiguous description of exactly how
to reproduce and observe the problem.
Click to expand...

I need to investigate this, it's quite fascinating. I change the property
in the designer, rebuild the project and it only 'sticks' on either the
RTF Editor OR the Text Editor, not both. I have added a menu option to
show/hide the status strip and it seems to work at runtime. I'll have
another look tomorrow when I'm fresher, my brain is fading a bit now.
 
Jeff said:
[...]
OK - I need a design surface to hold toolstrips, a status strip, another
control based on a Rich Text Box. With that sort of variety I think a
User Control is probably the way to go.
Click to expand...

I agree. It sounds like you really do have a composite control, which
is exactly the use case UserControl is intended for.
Perhaps I have to accept that a
control that can be designed shouldn't be abstract? Interestingly the
base class itself shows up fine in the designer, it would be hard to
design otherwise :-)
Click to expand...

Right…for designing purposes, the Designer needs to create the base
version, and then it layers its own stuff on top. It's not actually
manipulating an instance of the type being designed, so it's okay for
that type to not be instantiable.

It seems to me that as long as you don't find yourself in a situation
where you _do_ need to design using the abstract type – for example, you
want to be able to further do design work on the derived types – that it
being abstract shouldn't be a problem.

If I understand you correctly, the only difference between the plain
text and RTF versions is in fact the handling of the formatting, then
presumably that means you don't need to design those type individually,
and so having an abstract base class isn't a problem.

Pete
 
I recently ran into an issue where a designer exploded (thanks VS) and i had a need to debug the designer in order to find where the exception was arising. Here is a great article that explains how to debug visual studio at design time. It's actually rather simple. Perhaps this can help.

http://www.codeproject.com/KB/cs/wsod.aspx



Peter Duniho wrote:

Jeff Gaines wrote:I agree.
04-Feb-10

Jeff Gaines wrote:

I agree. It sounds like you really do have a composite control, which
is exactly the use case UserControl is intended for.


Right?for designing purposes, the Designer needs to create the base
version, and then it layers its own stuff on top. it is not actually
manipulating an instance of the type being designed, so it is okay for
that type to not be instantiable.

It seems to me that as long as you do not find yourself in a situation
where you _do_ need to design using the abstract type ? for example, you
want to be able to further do design work on the derived types ? that it
being abstract should not be a problem.

If I understand you correctly, the only difference between the plain
text and RTF versions is in fact the handling of the formatting, then
presumably that means you do not need to design those type individually,
and so having an abstract base class is not a problem.

Pete

Previous Posts In This Thread:


Submitted via EggHeadCafe - Software Developer Portal of Choice
Using the MS Text Driver to read Delimited Files
http://www.eggheadcafe.com/tutorial...c2-3895d1a2df28/using-the-ms-text-driver.aspx
 
Back
Top