Re: The concept behind a custom view object.
TravKliewer wrote:
I've tried before with specific questions. The idea was I'd try down a path
and when I get blocked, I'd ask for a suggestion of a solution to the
problem, but that didn???t work. So let???s try a different approach. Maybe I
just need to be pointed down the right direction. The very basic view in a
Doc/View architecture is the class CView. Then when more distinct
functionality is required, one would use a derived class such as CFormView or
CScrollView. And then an application project would produce a custom class
that one develops specific to the program. Well, the problem I have is the
user interface. I understand that when view needs to be redrawn either in
whole or in part, the framework calls the function OnDraw. And, the concept
behind the whole Doc/View architecture is the view is responsible for getting
user input and updating the document via document functions. (If someone has
a better, more clear way of describing that, by all means.) I'm just not sure
how to go about doing that. But, I do have some ideas.
First, I could draw the whole view in the OnDraw function and just capture
user produced event via functions like the OnLButtonDown. And if the user
clicks on a certain area of the view, for example in a rectangle that holds a
particular user interface part, is calls the appropriate document function to
update the document. Or something to that effect, the key here is that the
entire view is draw in a single or a small group of functions and the UI is
handled entirely by the view class through mouse and keyboard events.
The other idea is using developing my own ActiveX components and, I guess,
using the CFormView class to contain my custom controls. But I'm not familiar
enough with ActiveX programming to make it work right now. It seems
complicated and difficult, but not entirely beyond my capacity to learn. I
could eventually figure it out.
The last idea I have is using CWnd derived classes and create them as child
objects of the view class. Then having them respond to the mouse and keyboard
events. That would be easy to do and the view class wouldn't have to worry
about any of the specific function and drawing of the UI elements. But I
can't figure out how to attach the derived CWnd classes to the view. Or in
other words, my window classes don't respond to the events, or the framework
doesn't know when function to call when and event happens. Again, not
entirely beyond my ability to figure it out, it just takes time.
So, here's my question(s). Is one of those paths better than the other? Or,
maybe it depends on the specifics of my application. Perhaps, I'm missing the
point entirely. Perhaps, I'm not staying within the ideology of the
architectural design. Or, if I'm lucky I was able to express my dilemma
enough, at least indirectly, that someone can help direct me to the right
resources to learn the proper capitalization of this concept. In any case,
any advice would be helpful. Thank you so much in advance.
All three of the approaches you describe have their uses. The key to
picking the best one for your needs is reusability. It sounds like you
need something that is like a control.
The only time you would want to draw a control directly on the CView is
if you need a lot of them. Such as the cells in an Excel spreadsheet or
grid control. Creating a separate window (of any kind) is impractical
if you are displaying hundreds of them at once. You can just draw
something the looks like a control, but is just paint.
A CWnd-based custom control is a good approach if it is only going to be
used in C++ MFC projects. These are not hard to write and many examples
can be found on codeproject.com and codeguru.com. This approach is easy
to learn and very educational.
The main advantage of an ActiveX control is that it can also be used in
other environments, such as VB and web forms. MSDN has a tutorial on
how to write them (named CIRCLE, if I recall). More work to write, but
more reusable.
There is also a fourth approach, easier in many cases. If you can use a
standard control with changes to its appearance and mouse responses then
you simply derive a class from that control and start customizing the
paint and mouse handlers.
So what kind of thing(s) do you need in your view?
--
Scott McPhillips [VC++ MVP]