How to set Site for Control?

[marcin.rzeznicki]

Hello,
I noticed very strange behavior while setting Site property of Control,
and I don't know how to solve that problem. here goes the stroy: I have
written my custom control - assume its type is C - and some class which
implements IComponent and IContainer - that container is going to
contain controls of type C. I have also implementted ISite interface to
serve as a link between C and container of mine. So far so good, yet
whenever I try to set Site property of instance of C (for example, when
adding to container), there comes shiny InvalidCastException out of
System.Windows.Forms.dll. Why is that? I do not know - Component should
not assume anything special about container to which it belongs and
definitely should behave in graceful manner when put in "wrong
environment", as component is by definition REUSABLE and reusability
means also cooperation with different surroundings. Yet it seems to me
that Control shuns that renowned idea... So goes the question - already
specified in the subject - how should I set Site for my control?

 

[Stoitcho Goutsev \(100\)]

Marcin,

I think you misunderstood the structure VS designers and hosts. Containers
are not components or controls that contain others. Container is rather
pure design time concept. The contianer is the designer host. It containes
collection of all controls in the design surface. While the control
structure is hierarchical containers keep all the components in a flat (1
level) structure. Sides are objects that provide the link between the
container and its components. They are usually small separate objects that
implement ISite interface only. For each component on the design surface
there is a separate link object that implements the ISite interface.

However, because IContainer is a basically interface for objects containng
components this interface can be used for different purposes not only in
design time. And Windows Forms does. Forms and user control has a member
called components that is used to keep track of all non-visual components
that has been added to the at design time. This collection is then used to
dispose components upon closing the form or user control. But keep in mind
that not all controls and components goes there.
If you want to use ISite and IContainer in a similar manner I'd suggest to
use the implementation that comes in the framework -
System.ComponentModel.Container. It takes care of creating site objects as
well as removing the components from their sites when the container changes,
etc.


For more information on .NET designers I'd suggest read through the
following article:
http://www.developerfusion.co.uk/show/4351

If you want to jump directly on DesigerContainers and Hosts you can use this
link, but I'd suggest reading the whole article.
http://www.developerfusion.co.uk/show/4351/3/

 

[marcin.rzeznicki]

Stoitcho Goutsev (100) napisal(a):

Marcin,

Hello Stoitcho

I think you misunderstood the structure VS designers and hosts. Containers
are not components or controls that contain others. Container is rather
pure design time concept. The contianer is the designer host. It containes
collection of all controls in the design surface. While the control
structure is hierarchical containers keep all the components in a flat (1
level) structure. Sides are objects that provide the link between the
container and its components. They are usually small separate objects that
implement ISite interface only. For each component on the design surface
there is a separate link object that implements the ISite interface.

Well, I have implemented my site (extending ISite interface), but I
failed at perceiving the fact that Container is, as you wrote, "pure
design time" concept, that is - it is only used for design-time
purposes. I thought that it is rather general concept of containers
which provide services and management for components, and components
which obtain certain services from its container, at the runtime (no
matter what is the type of container). Well, that is actually the way,
but Controls are so specific that they can be sited only in VS designer
containers and containers themselves are designer containers. I thought
also that design-time support is rather a fine add-on to ease component
configuration than their primary usage model.

However, because IContainer is a basically interface for objects containng
components this interface can be used for different purposes not only in
design time. And Windows Forms does. Forms and user control has a member
called components that is used to keep track of all non-visual components
that has been added to the at design time. This collection is then used to
dispose components upon closing the form or user control. But keep in mind
that not all controls and components goes there.

I created my own custom control (so I should not have any contracts
inherited from more specific controls) and it seems to use only
specific ISite implementation - so it can be used only for specific
hosting. That is my pain.
What I intented to do was creating of some container which serves as a
pipeline - all components hosted in it would participate in some
synchronous processing. Some of components would have been controls
which take care of presenting some stages of processing to user. All
components would have been linked to its container by my site which
would have given them necessary services. And there the problem
occured, you cannot have your own site coping with Control.

If you want to use ISite and IContainer in a similar manner I'd suggest to
use the implementation that comes in the framework -
System.ComponentModel.Container. It takes care of creating site objects as
well as removing the components from their sites when the container changes,
etc.

I have taken the task to implement that myself, it was quite easy
because in my model components in container are immutable, they cannot
change their container in any way. But the problem lied somewhere else,
and know I seem to know where (thanks to you as well)

For more information on .NET designers I'd suggest read through the
following article:
http://www.developerfusion.co.uk/show/4351

If you want to jump directly on DesigerContainers and Hosts you can use this
link, but I'd suggest reading the whole article.
http://www.developerfusion.co.uk/show/4351/3/

Thank you, I shall.

Now I try to implement the model in which component (implementation of
IComponent but not Control child) interacts with Control descendant
registered to him, that would give me correct behaviour I suppose, as
well as quite better programming model.

Thank you.