One small way Visual Studio could prevent me from doing something
- From: michael sorens <m_j_sorens@xxxxxxxxxxxxxxxx>
- Date: Wed, 25 Jun 2008 09:36:00 -0700
My code recently had a near-death experience so I thought I would share with
the community how it (OK, how I...) saw the light :-)
It began simply enough: I created a WinForm application, dragged a control
onto the designer, executed the project... and VS reported a null reference
exception indicating the control did not exist. Huh?
I went back to the designer for this form--or tried to. When I attempted to
open the form in the designer it reported: "The variable 'myRichTextBox1' is
either undeclared or was never assigned."
Hmm, I thought... did I find a Visual Studio bug? I gave this a likelihood
of 1%; the other 99% likelihood I attributed to the scenario where I did
something wrong but VS did not report it as intelligently as it might have.
Which means it could be challenging to track down.
My VS solution contains several projects, one of which is a custom user
control library. This library contains 9 controls, some of which derive from
UserControl and some of which derive from other controls (e.g. RichTextBox).
The first clue:
A Different WinForm Project in the Same Solution:
=> the designer toolbox shows all 9 controls.
A WinForm Project in a Different Solution:
=> only 8 of the controls show up in the toolbox.
The discrepancy happens to be the very control that caused the problem above!
Concentrating on running a different WinForm project in the same solution:
If I drag the errant control from the toolbox onto the designer it shows up
fine in the designer. Inside the Form1.Designer.cs file it declared the
instance variable, it assigned all the properties to it, but it did *not*
instantiate the control--neat! Therefore, if I close the designer, compile
the project, and re-open Form1 in the designer, VS complains "The variable
'myRichTextBox1' is either undeclared or was never assigned." which it
rightly should at this point. Running the project, of course, yields a null
reference exception as one would also expect.
Well, if it was not instantiated what would happen if I did it manually? So
I manually added this to the Form1.Designer.cs file:
this.myRichTextBox1 = new CleanCodeControls.Forms.MyRichTextBox();
Compilation yielded this error:
'CleanCodeControls.Forms.MyRichTextBox.MyRichTextBox()' is inaccessible due
to its protection level
Going back to the control source and looking at the constructor, I found
that though the class was public, the constructor was protected, hence the
problem! Changing the constructor to public resolved the situation.
What would have saved me a lot of effort was if--at the moment I dragged the
control onto my form--Visual Studio said, "Wait a minute! I cannot
instantiate this control due to its protection level."
.
- Follow-Ups:
- RE: One small way Visual Studio could prevent me from doing something
- From: Linda Liu[MSFT]
- RE: One small way Visual Studio could prevent me from doing something
- Prev by Date: Re: VS 2005 - Only 'Build' and 'Publish' appear in Build Menu
- Next by Date: RE: One small way Visual Studio could prevent me from doing something
- Previous by thread: Re: VS 2005 - Only 'Build' and 'Publish' appear in Build Menu
- Next by thread: RE: One small way Visual Studio could prevent me from doing something
- Index(es):
Relevant Pages
|
