Hristo, thank you for your response.
The reason I would like to inherit the RadWindow is so that I can encapsulate the 'Form' functionality within each of my data capture components. Certain data capture windows have expected behavior and I would like the component to control this behavior from within the component itself rather than have the calling/instantiating class handle the behavior (which is called in more than one class).
The work around to this would be to have some type of service/factory class for each type of data component that I have and return the RadWindow instance back with all of the behavior set. However this now means that I must keep the functionality and behavior for my data component in two separate classes (the data user control for functionality and the RadWindow service/factory class for the specific window behavior).
The reason I recreated the issue in the Example solution was to show a basic and quick example of the issue with inheriting the RadWindow. Being able to inherit the RadWindow (much like an inherited form in WinForms) doesn't seem unreasonable for the sole purpose of encapsulating functionality and behavior within a component.
The main functionality I need is to be able to have a ‘Window’ class that I can put user controls onto and have the class handles it’s own responsibilities, which include some window behavior.
Thank you for the offer of extending the control, but I don’t think it’s in scope of your control, or feasible from your point of view (as a vendor) to take on the specific aspects of our business that your control would have to provide. Just as RadWindow itself is inherited from ContentControl to extend it’s base purpose, clients of the RadWindow contol will need to extend upon your already significant functionality to encapsulate behavior specific to their business.