Adding an 'internal' control to the toolbox.

C

Chien Lau

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...
 
M

Mark Broadbent

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.
 
C

Chien Lau

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top