Thanks to all for the response. Led Mike - think you may have me sorted on this one. The objects primary intent is not to render so you are correct that Separation of concerns would suggest my idea was a bad idea. Thanks to all for the response. Paul C

Hi David, I have a splitter window. One view is the list of available objects (which is pretty simple ) and the other is the view of the selected object. If the second view has contain all of the code to be able to render each object type then it will be an enormous amount of code. The list of available objects will be extended in the future and I was trying to come up with a way of having each object be able to render itself rather than have the one view 'know' about all of the objects and ultimately each time an addition was made it breaking previous code. Or is this just a dumb idea for a Thursday afternoon.... Paul C

Hi, MFC - VS2005, based application. I have a number of objects, derived from the same base class. In the future I expect to be adding more. Two views are provided on my app a CView based splitter, one is a simple list of the available objects the other is pane within which I would like each object type to render itself. The view of each object while complex will have some similarities so I would anticipate a display class with inheritance etc. So what might be the best way of implementing this display ? Derive my display objects from CWnd and as the user selects each one in the list pane create and inject a new display object into the CView client area ? Or ??? Many Thanks, Paul C