Re: Inheritance and MFC
Hi Joe,
Presumably there is not a single line of code in CGrid that uses any =
feature of MFC
whatsoever, right?
That is the plan. Who knows whether it will work or not, but just for =
arguments sake, let's just say that it does.
If this is so, then it has no display mechanism, no way to interact =
with the mouse, no way
to display anything in a window, etc. It would be what we think of as =
a "document".
Nothing wrong with that.
This is my plan.
So what you would do is create a "view" on this object. The "view" =
would provide the
display and user interaction components.
That is a big correct-a-mundo.
There would be no reason to use serialization at all; anything that =
would be in a grid
should be easily serializable using simple I/O mechanisms, to write =
integers, floats, and
strings. So CObject buys nothing.
I didn't see a need to inherit from CWnd, since all I needed was =
Serialization.
(Is there no apparent reason to ever inherit from CObject as opposed to =
CWnd? or am I completely mistaken?)
I suppose I could have used CFile or something similar, but I am just =
messing around. Familiarizing myself with the interworkings of MFC.
Like I said. It is not complete.
All I want to do is add Scrollbars to the object.
Just trying to keep it seperate.
But if you DO make it a CObject, it is STILL a "document", with no =
display, drawing, or
windowing capabilities
That is my plan.
Think of a separation of data and display, at it becomes obvious that =
your CGrid would
most likely be contained in a CDocument class in MFC, and all drawing =
and interactions
would be in a CView, or a class which is embedded in a CView.
That is what I am thinking of, but a bit differently.
There is no Document, but there are variable that are stored via =
registry or disk.
I wanted the base class to just inherit from CObject, becuase that is =
all it needed, just to store to disk
Now, I am adding Scrollbars to the object, therefore it needs more than =
just CObject.
I guess I will have to change CGrid to inherit from CWnd and add the =
CScrollbars to the base class, since I can't
inherit from CObject twice.
All in all, is there never a need to inherit from CObject as oppposed to =
CWnd?
Since, everthing in MFC will be in a View and everything in a View needs =
needs CWnd.
What is the purpose of ever inheriting from CObject?
Should I just inherit from CWnd and never inherit from CObject?
What the heck is the purpose of CObject? An unused Reference? Like PURE =
in the dialog resource?
Thanks,
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message =
news:6tjm83h4t0oqhkb6d0i0fcj2e5lqmrtv8a@4ax.com...
Presumably there is not a single line of code in CGrid that uses any =
feature of MFC
whatsoever, right?
If this is so, then it has no display mechanism, no way to interact =
with the mouse, no way
to display anything in a window, etc. It would be what we think of as =
a "document".
Nothing wrong with that.
So what you would do is create a "view" on this object. The "view" =
would provide the
display and user interaction components.
There would be no reason to use serialization at all; anything that =
would be in a grid
should be easily serializable using simple I/O mechanisms, to write =
integers, floats, and
strings. So CObject buys nothing.
Therefore, there is no need to encapsulate a grid in a CObject as =
such.
But if you DO make it a CObject, it is STILL a "document", with no =
display, drawing, or
windowing capabilities, so now you need to create a grid-view, and =
that would be derived
from CWnd, so it would not need to be derived from the grid; I think =
you are confusing
display and data, representation and manipulation, and the confusion =
has led you down a
design path which is apparently confusing to you, and it should be, =
because it is probably
wrong. When a design starts exhibiting these problems, you should =
reconsider the design.
Think of a separation of data and display, at it becomes obvious that =
your CGrid would
most likely be contained in a CDocument class in MFC, and all drawing =
and interactions
would be in a CView, or a class which is embedded in a CView.
joe
On Tue, 3 Jul 2007 22:55:56 -0700, "Nobody" <Nobody@yahoo.com> wrote:
Hi Joe,
Well, if you made it a CObject, it is most definitely *not* =
independent of MFC! And the
concept of including it in an MFC class seems more than a little =
strange.
In fact, the "using ... a few other MFC functions" means you are =
already committed to MFC.
Yes, and No.
Yes, I have committed to using MFC, because that is what I am =
developing the project with.
No, because it is able to be used independent of MFC. (At least that =
is what I was trying to do.)
Yeah, your right, I need to clean it up somewhat to conform to do what =
I want, but I was holding that off for now.
I am a bit confused about segragating the class into independent =
"Seperately indentifiable" objects. Hence the post.
CGrid - Independent
CGridMFC - MFC Dependent - Only Serialization. (Does not need CWnd.)
CGridSB - MFC Dependent plus Scrollbars.
I suppose like David said, I can't go that route and I will have to =
just inherit from CWnd in the base class or the CGridMFC class.
Thanks anyways,
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message =
news:dc9m83dkbfgjg9gkj8itlkcrc33mhou1q7@4ax.com...
Well, if you made it a CObject, it is most definitely *not* =
independent of MFC! And the
concept of including it in an MFC class seems more than a little =
strange.
In fact, the "using ... a few other MFC functions" means you are =
already committed to MFC.
joe
On Tue, 3 Jul 2007 17:30:28 -0700, "Nobody" <Nobody@yahoo.com> =
wrote:
Hi Joe,
Why is a grid object not derived from CWnd in the first place?
I wanted to make the grid object independent of MFC.
The only reason I am using CObject is for Serialization.
I am using the registry and a few other MFC functions, OnDraw(), =
OnMouseMove(), etc.
I should actually make several layers, but it is what it is for now.
I noticed that the more I use the grid object, the more I have to =
keep adding scroll bars for pan, zoom, etc.
So, my idea was to make a CWnd GridSB Class that implements =
Scrollbars.
That class inherits from the Grid CObject class.
Then, I can leave the scroll bars inside of the CGrid Object, =
instead of Creating scroll bars each time.
This is basically what I have.
CGrid : public CObject
CGridSB: public CGrid, public CWnd
{
CScrollbar sb;
CreateScrollbars();
SetScreenRect(){ Position Scrollbars(); }
}
CView::OnDraw()
{
CGridSB sb;
sb.SetScreenRect(Rect);
sb.OnDraw(pDC);
}
Regards,
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message =
news:hndk83t2i52oo7o21fhrt0jpj8f5vn97u7@4ax.com...
Multiple inheritance is chancy in MFC. At least one rule is the =
CWnd class must be the
first class. But in this case, I don't see how a visible object =
like a grid could *not*
derive directly from CWnd, and since CWnd derives from CObject, =
there is no need for the
inheritance from CObject in the first place.
Why is a grid object not derived from CWnd in the first place?
joe
On Tue, 3 Jul 2007 02:49:21 -0700, "Nobody" <Nobody@yahoo.com> =
wrote:
Hi,
I have a grid object. The Grid Object inherits from CObject.
There are no controls and I was thinking about adding some. Zoom, =
Pan, etc.
So, I have extantiated a new class that inherits from CGrid and =
CWnd.
class CGridSB : public CGrid, public CWnd
Now, I would like to add some controls to the Grid Object.
The problem is that the controls needs an m_hWnd
I am not sure what to do?
VERIFY(c_sbHZoom.Create(
SBS_VERT | SBS_RIGHTALIGN | WS_CHILD |WS_BORDER,
Rect,
this,
1234)
);
_AFXWIN_INLINE void CScrollBar::ShowScrollBar(BOOL bShow)
{ ASSERT(::IsWindow(m_hWnd)); ::ShowScrollBar(m_hWnd, SB_CTL, =
bShow); }
I understand that the CGridSB oject needs to handle the Scrollbar =
messages, so I need a message map
and perphaps a DECLARE_DYNCREATE along with an IMPLEMENT_DYNCREATE =
member.
I just need to get past the m_hWnd error.
Thanks for your help,
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm