Re: Single Document MDI-like interface questions

Tech-Archive recommends: Speed Up your PC by fixing your registry

See below...
On Mon, 27 Jul 2009 01:15:42 -0700 (PDT), Woody <ols6000@xxxxxxxxxxxxx> wrote:

Joseph M. Newcomer wrote:
This is supported in MFC by simply not writing to the document. So why is this an issue?

It's not an issue, it's a spec. I included such specs to show that
that part of the MFC framework isn't needed, to compare the effort
necessary. Print preview, for example, is a definite reason not to
write your own, but it isn't needed here.
****
So what? At any given moment, I have applications that do not require some part of the
MFC framework; this is not a justification for throwing it out! Since you don't need the
ability to write the file, you don't use it. My original question: why is this even
brought up as an issue? I don't use CStringA most of the time. I don't use CArchive,
ever. I rarely have to call MDIActivate. Most applications don't require multiple
different views. If I discarded MFC every time I didn't need a feature, I would not have
gained anything.

You wave this about as if it is even vaguely relevant to the discussion. I would not have
even considered it as part of the problem space. It doesn't need to be written, I don't
write it. Disable the Save/SaveAs menu items, or even remove them and their shortcuts
entirely! Topic closed, move on to *real* problems. This is at best trivial.
****

Define "batch processing" and how you set up a sequence of files to be handled.

The user opens document #1, then clicks "batch" on a menu. The pgm
assembles a list of all the eligible files (documents), then opens
them in order (output is to a file as well as the screen).
****
Why have to open any document? You should be able to start out with NO documents open.
Next, you are confusing processing with viewing? I would consider opening the documents
with the "batch view" as the only view, instead of all seven views you mention. The
"batch view" would probably be a CFormView with only a progress bar in it. Not a big
deal. When in batch mode, I would create documents using a different CMultiDocTemplate
suitable for the batch processing. And I wouldn't open any other views. This Ain't
Rocket Science. It's called an "if-statement".
****

Without a whole lot of effort.

This is not a very constructive answer. I put in a lot of effort and
didn't get a satisfactory result, so I asked those who have a deeper
understanding of doc/view to outline for me how they would implement
this specification.
****
Depends on how you approach the problem. Note that alternatives you suggest (such as
inventing your own framework) involve MASSIVE effort. Some of the requirements you have
involve the same effort no matter what framework you are using, so I was referring to the
expenditure of effort above and beyond the requirements. If you need to do a complex
layout of windows, this involves a lot of geometric calculations. They look the same in
MFC and raw Win32. If you want to do batch processing without bringing up seven views,
this is trivial; just launch the document from a different template (for which you have
NOT called AddDocTemplate!). Multiple toolbars take the same effort in any system, but in
MFC most of the support is already there. Use it.

Your original post did not indicate, for example, WHY your document failed to open a
second time; the very *first* thing I would have tried under those conditions is to
single-step into MFC and see WHY. You erroneously hypothesized, based on no evidence
whatsoever, that it was because the document template was not destroyed. There is
absolutely no rationale as to how you could have arrived at such a conclusion; it doesn't
even make sense. Document templates should not be destroyed until the program terminates.
So you sit there and stare at the screen, say "this doesn't work because the template is
not destroyed" instead of doing the obvious single-stepping to see what went wrong. There
is a reason it does not come up, and the reason can be discovered. You apparently made no
effort to exercise the simplest discovery technique. If you just flail about, playing
by-guess-and-by-golly, you learn nothing, and cannot describe the problem adequately so we
can answer it (the code I showed is from an application where views are regularly
destroyed and then later re-opened by the users; it is from a running product. All I did
was sanitize the class names to "red" and "green"). I might have spent 10-15 minutes
doing single stepping to learn what went wrong, and then I'd know. And I could probably
fix it. Instead, you fail to do any analysis, and decide that the correct solution is to
discard all of MFC and rewrite it from scratch. This attitude is, to say the least,
incomprehensible.

In case you are wondering how we became MFC experts, we spent a fair amount of time single
stepping through code to try to understand it. Once you have that understanding, you can
easily manipulate the world. But we can't do that for you. If you have tried something
that doesn't work, it is *essential* that you discover why. Since I know that the code I
gave you has no problem re-opening views, if your views do not re-open, *something else*
is wrong. But I have no idea how to determine what that is. If I had written the code
and it wasn't working, my very first reaction is to discover *why*. Once I identified the
problem, I could either fix it, or ask a meaningful question. So, until you can explain
*why* the window fails to come up, identifying specifically the place in MFC that returns
an error code, we have no way to tell what you have done that has caused this problem, and
have no way to answer your question.

You asked a question that was interesting, I gave an answer copied directly from my
existing code. I will admit that it took me some effort to arrive at that code, ten years
ago, but you got it free. So how did we fail to answer your question?

Note that the batch requirement came much later in the discussion. But I've given you the
answer to that, once you explained what you meant to do. I might do like I did in one
application, create a dialog with file names in a listbox on the left and selected file
names in a listbox on the right, with > >> < and << keys (add selected, add all, remove
selected, remove all), and while I admit freely that this takes longer than ten minutes,
it takes longer than ten minutes in raw Win32, but it is several times easier to do in MFC
(besides, I've written this code many times). And if I wanted to, I would put a CTreeCtrl
on the left side, with all the drives shown; clicking on a drive and expanding it shows
all the folders in the drive, and clicking on a folder shows all the *.xxx files in that
folder; since no folder is enumerated until it is expanded, this works very efficiently.
And yes, I'd expect to spend about a day writing this in MFC (or a few days, in raw
Win32). But note that the complexity of the solution is dictated by the needs of the
solution, not by MFC itself. I'd probably write the RHS as an owner-draw listbox, so it
would show the full path for the filenames not in the current directory, but that's just a
fine point; I'd spend 20 minutes doing this (because I have a ton of owner-draw listbox
functions lying around, and I could grab whichever one seemed easiest to adapt). This is
*much* easier to do in MFC than in raw Win32 (because I first did this in raw Win32, back
around 1992, when we didn't even have tree controls and I had to fake them in an
owner-draw listbox by using indentation!) But the MFC part, "not showing all seven
views", is trivial. Anything that requires *not* executing code is usually trivial.

As far as changing the toolbar, the first thing I would do is spend 30 seconds looking at
the CView members. The OnActivateView looks like a place I would want to determine what
toolbar to display. I would then look at how to change a toolbar. I would look at how
the mainframe is created and how the toolbar is created. Then I would create two other
toolbars. In the OnActivate, I would SendMessage to the mainframe a user-defined message
that conveyed, in some form or other, the desired toolbar to display. Maybe a pointer to
a CToolBar object, maybe an enumeration value selecting the desired toolbar. Not counting
toolbar construction (boring pixel editing), perhaps ten minutes work. So to save ten
minutes, you think you should write your own framework from scratch?
joe
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Single Document MDI-like interface questions
    ... what I would most likely do for the OnActivate is create yet ... and would implement virtual methods that specified which toolbar to use. ... MFC framework; this is not a justification for throwing it out! ... with the "batch view" as the only view, instead of all seven views you mention. ...
    (microsoft.public.vc.mfc)
  • MS/BCGSoft FeaturePack a one big [embarassing] hack and developers nightmare?
    ... I've been trying to port an MFC app that I wrote few years ago to VS2008 ... Otherwise FeaturePack panes would simply ... You would assume that to create a toolbar without a gripper is as simple ...
    (microsoft.public.vc.mfc)
  • Equivalent to OnUpdateCmdUI? (how to update menus/toolbars in .NET?)
    ... having to implement a lot of the framework that was provided in MFC. ... I'm trying to figure out how to update the state of menu items and toolbar ... views (sub-form windows). ...
    (microsoft.public.dotnet.framework.windowsforms)
  • RE: MFC Toolbar Button Size Corruption
    ... You are right to be concerned about future changes in MFC catching you out ... The reason I called OnSettingChange on CToolBar ... class resulted in the wizard adding an OnSettingChange method to my class. ... The application contains a toolbar. ...
    (microsoft.public.vc.mfc)
  • Re: disappearing toolbar
    ... Something must be setting it to NULL (internal workings of MFC) because what ... implemented toolbar as like this ... CToolbar and after resizing the window, the toolbar again disappeared, ... window toolbar disappears ...
    (microsoft.public.vc.language)