By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,361 Members | 1,683 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,361 IT Pros & Developers. It's quick & easy.

Adding an 'internal' control to the toolbox.

P: n/a
I frequently define internal UserControl-derived classes in my WinForms
apps:

internal class MyUserControl:UserControl{
...
}

I'll often need to embed these controls in a Form, whose class is
contained in the same assembly as the control. As far as I know, the only
way to do this using the designer is to add the UserControl-derived object
to the toolbox and then drag it from the toolbox to the target form.

To accomplish this, I use the toolbox's Add/Remove Items functionality.
When adding new UserControl(s) to the toolbox, the user is asked to choose
an assembly containing the UserControl. I browse for and choose the assembly
that I'm currently working on, call it /debug/MyAssembly.dll. The problem is
that the toolbox is only prepared to accept UserControl items that are
declared as "public," not those declared as "internal." For a variety of
reasons, I'd much prefer to have UserControls declared as internal if I'm
not exposing them to the outside world.

The only workaround is to temporarily change the scope of the
UserControl to public, recompile, Add the item to the toolbox, change the
modifier back to internal, and recompile again. I then have access to the
control from my toolbox. This clearly an ugly workaround. Do you know of an
easier way to add internal controls to the toolbox?

Thanks...
Nov 16 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
If you are marking the controls as internal, then surely they can only be
instanciated from within that assembly .dll.

I am also hazarding a guess that the control you have added to the toolbox
will be using a cached copy of the referenced dll so that just because you
have recompiled the original as internal will not effect the toolbox
version.

See this from the C# Programmer's Reference...
The internal keyword is an access modifier for types and type members.
Internal members are accessible only within files in the same assembly. For
more information on assemblies, see Components and Assemblies.
A common use of internal access is in component-based development because it
enables a group of components to cooperate in a private manner without being
exposed to the rest of the application code. For example, a framework for
building graphical user interfaces could provide Control and Form classes
that cooperate using members with internal access. Since these members are
internal, they are not exposed to code that is using the framework.

It is an error to reference a member with internal access outside the
assembly within which it was defined.

Caution An internal virtual method can be overridden in some languages,
such as textual Microsoft intermediate language (MSIL) using Ilasm.exe, even
though it cannot be overridden using C#.
For a comparison of internal with the other access modifiers, see
Accessibility Levels.

Example
This example contains two files, Assembly1.cs and Assembly2.cs. The first
file contains an internal base class, BaseClass. In the second file, an
attempt to access the member of the base class will produce an error.

File Assembly1.cs:

// Assembly1.cs
// compile with: /target:library
internal class BaseClass
{
public static int IntM = 0;
}File Assembly2.cs

// Assembly2.cs
// compile with: /reference:Assembly1.dll
// CS0122 expected
class TestAccess
{
public static void Main()
{
BaseClass myBase = new BaseClass(); // error, BaseClass not visible
outside assembly
}
}See Also

br,

Mark.

"Chien Lau" <Mo**********@grandson.pop> wrote in message
news:ug****************@tk2msftngp13.phx.gbl...
I frequently define internal UserControl-derived classes in my WinForms apps:

internal class MyUserControl:UserControl{
...
}

I'll often need to embed these controls in a Form, whose class is
contained in the same assembly as the control. As far as I know, the only
way to do this using the designer is to add the UserControl-derived object
to the toolbox and then drag it from the toolbox to the target form.

To accomplish this, I use the toolbox's Add/Remove Items functionality. When adding new UserControl(s) to the toolbox, the user is asked to choose
an assembly containing the UserControl. I browse for and choose the assembly that I'm currently working on, call it /debug/MyAssembly.dll. The problem is that the toolbox is only prepared to accept UserControl items that are
declared as "public," not those declared as "internal." For a variety of
reasons, I'd much prefer to have UserControls declared as internal if I'm
not exposing them to the outside world.

The only workaround is to temporarily change the scope of the
UserControl to public, recompile, Add the item to the toolbox, change the
modifier back to internal, and recompile again. I then have access to the
control from my toolbox. This clearly an ugly workaround. Do you know of an easier way to add internal controls to the toolbox?

Thanks...

Nov 16 '05 #2

P: n/a
Hi Mark,
If you are marking the controls as internal, then surely they can only be
instanciated from within that assembly .dll.
....and this is my goal. I only want to access the internal controls from
within the DLL that houses those controls.
I am also hazarding a guess that the control you have added to the toolbox
will be using a cached copy of the referenced dll so that just because you
have recompiled the original as internal will not effect the toolbox
version.


I'm not sure about this. When I recompile the control, that new version
of the control is used when I drag the respective toolbox icon on to a form.
The toolbox seems to be nothing more than a list of assemblies/class names.
The trick is getting an internal control into the toolbox. Remember, I only
want to consume the control from within the same assembly in which the
control is defined. I wouldn't expect the control to be available to OTHER
assemblies.

Nov 16 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.