Render multiple object in single view
-
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
-
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
How about a splitter window?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
-
How about a splitter window?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
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 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
PRC wrote:
Or is this just a dumb idea for a Thursday afternoon....
No, Yes, Maybe. It depends. If these object's primary responsibility is to render then it's fine. If these objects have more business oriented responsibility then adding rendering to them is not a good idea. Separation of concerns[^] In that case you could consider designing a rendering interface and implement however many renders you need for each type of object. You might use inheritance or any other design for the renders.
-
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
Hello, you can define a draw function for each object in its class, and make that class inherited from an interface. class Object { ..... virtual void draw() = 0; .... }; class Circle : public Object { virtual void draw() {} }; and call each objects'draw method in the view. you may also want to look at the visitor pattern. Hope this helps. Bekir.
-
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
PRC wrote:
...and the other is the view of the selected object.
Which (I think) would require a separate
CView-type class for each. In the pane that controls the list of available objects (e.g.,OnItemChanged()method if usingCListView), figure out which object is selected and tell the splitter window to change to the corresponding view. I did this once with a gymnastics-related application. I only had 3 items in the left pane, however."Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
-
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