Re: [lmi] Child documents

[Greg Chicares]

On 2009-12-25 19:17Z, Vadim Zeitlin wrote:
> [this is a return to a very old discussion but I really, really do intend
>  to finish it this time so that we won't have to return to it again]

[I find that I've neglected to reply. Merry Christmas if I haven't
wished you one already.]

> On Sun, 15 Mar 2009 19:25:03 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Ted Neward's _Advanced OWL 5.0_, ISBN 1-884777-46-5, contains the only
> GC> discussion I've ever seen of OWL's child document idea, which is where
> GC> I originally got this lmi idea. He calls this "one of the most underused
> GC> features in OWL". Comparing that to a full embedding concept (like ole
> GC> or opendoc), he says "Compound documents in OWL are far more limiting.
> GC> They simply group TDocument objects in a hierarchy, cascading operations
> GC> on a parent document to, in turn, be called upon by each of the children,
> GC> which implies that wxDocument::Save[As]() would save child documents
> GC> (as the analogous OWL TDocument::Commit() indeed does).
> 
>  I haven't read the book (it's esoteric enough for even Google Books to not
> index it) but this concept does make sense to me in the form described
> above. However this is subordinate to Save[As]() working this way, i.e.
> cascading from the parent document to children.

Yes--I'm really only interested in deletion of the parent causing
automatic deletion of the children (and inhibiting commands that
wouldn't make sense for these children--discussed below).

> GC> Compared to that "far more limiting" concept, what lmi uses is still
> GC> more limited, because it omits the Save[As]() part: all that remains is
> GC> to "simply group TDocument [wxDocument] objects in a hierarchy" and to
> GC> cascade only one operation, i.e., closing.
> 
>  I thought that this was indeed just a limitation and so it still made
> sense. However now I'm less sure: if a child document can't be saved
> independently of the main one

It can't be saved in any sense whatsoever.

> (and, in any case, can't be opened
> independently of it because the user never selects any parent document so
> creating/opening child documents is always done programmatically anyhow),
> what exactly can it be used for that just a view can't?

Yes: *that* is the question.

> GC> Suppose you load a document in a word processor, and issue a print-
> GC> preview command. A "view" is created. If you close the document,
> GC> then the view presumably vanishes. If you change the document, then
> GC> you can't reproduce exactly the same view. It's an ephemeral view
> GC> that's thrown away if you don't print it immediately. That's the
> GC> kind of thing I'm talking about.
> 
>  I didn't pay enough attention for this part when reading this message the
> first (and subsequent...) time(s) but now I think that it is key to my gut
> feeling of discomfort provoked by this child document concept: if it's so
> similar to a view, why don't we just use views instead?

I suppose a separate document is a convenience rather than a necessity;
or at least it seems convenient to an old OWL hand.

Here's a complete description of the additional behavior I seek.
  File | New | Census  # creates window 'A'
  Census | Run case    # creates window 'B'
  Window | Next        # focuses window 'A'
  [MDI-menu] | Close   # closes only 'A', and that's the problem.
I want 'B' to close whenever 'A' closes for any reason.

At the same time, I want to preserve an existing behavior that I have
kludged in via the 'flags' argument of wxDocTemplate::CreateDocument():
or-ing in my own LMI_WX_CHILD_DOCUMENT causes IllustrationView::is_phony_
to be set to 'true', and then is_phony_ is used to disable numerous
commands that wouldn't make sense for the "child". All the "magic" is
really in MakeNewIllustrationDocAndView().

You might look at this as a horror rather than a convenience, and that's
okay--I just want these particular behaviors, and I'm happy if they can
be achieved by more tasteful means. Felicitously enough, we're resuming
this discussion just when we've been talking about completely replacing
the census-view class anyway.