CAB-friend Form subclass?

Topics: CAB & Smart Client Software Factory
Jul 1, 2005 at 4:43 AM
originally posted by: ejschoen

We've been wondering here if there would be any value to having a subclass of Form that creates is "components" container as a CompositeServiceContainer, rather than as a plain old Container. It might be an interesting way to compose services in an MDI-like application, in which some services are defined at the "shell" level and some are defined or redefined at the MDI child level.

An example we have in mind is creating a framework in which a top level shell window exposes a toolbar service, but in addition, MDI child windows expose their own toolbar services, such that the child windows display toolbars to hold child-specific commands. At the same time, components running in the context of the child window still need services defined at the root level container. If the components member were a CompositeServiceContainer, it would be able to inherit services from the root.

That said, I've been working on a simple subclass of Form that whose serialization would create a CompositeServiceContainer. However, I'm lost in a world of CodeDomSerializers, IDesignerSerializationProviders, and DefaultSerializationProviderAttributes. Is there some simple way to prevent the internal ContainerCodeDomSerializer.Serialize method from emitting the

this.components = new Container();


The best I have been able to manage is to insert a

this.components = new CompositeServiceContainer();

statement that ends up immediately after the default one, causing the deserializer to be mightily confused, because two different objects are assigned to "components."

Jul 1, 2005 at 7:33 AM
originally posted by: PProvost

We are exploring lots of interesting ways to improve the developer experience along these lines. Stay tuned for the code drops later in the summer.
Jul 1, 2005 at 4:34 PM
originally posted by: EdJez

I'm very interested however in learning more about the requirement that you have. The CAB preview does allow you to have these hierarchical contexts of sorts, via workitems, but the relationship with views is expressed the other way around (the child view is contained in a child container,rather than owning it). What does the code that you would like to write look like (designer and serialization woes aside?)