[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Child documents [Was: Adding open files to MDI "Window" menu]
From: |
Greg Chicares |
Subject: |
Re: [lmi] Child documents [Was: Adding open files to MDI "Window" menu] |
Date: |
Sun, 15 Mar 2009 16:48:45 +0000 |
User-agent: |
Thunderbird 2.0.0.19 (Windows/20081209) |
On 2009-03-15 06:33Z, Greg Chicares wrote:
> On 2009-01-30 22:57Z, Vadim Zeitlin wrote:
>>
>> I'm continuing my trip in the past of this mailing list archives and by
>> now I reached the discussion about the child documents. To give you more
>> context, the full contents of the message I'm replying to can be seen at
>>
>> http://lists.nongnu.org/archive/html/lmi/2008-03/msg00038.html
>>
>> I don't think the thread it makes part of has anything else related to this
>> subject though.
>
> The concept is quite simple; the implementation is less so. To make it all
> clearer, I implemented it in the spirit of that 2008-03 message, correcting
> some errors along the way and using some ideas from your message, and then
> uploaded a patch here:
> http://savannah.nongnu.org/support/?104485
I just uploaded an improved version:
https://savannah.nongnu.org/support/download.php?file_id=17697
I'm not sure we've quite decided whether to do all of this in lmi,
all of it in wx, or parts in both. If it's all to be in lmi, then
this is a (still unpolished) proposal of the changes I suppose we
should make. Otherwise, it seems likely to make any wx changes
easier--so, either way, it seemed like a good idea.
However, it has defects due my limited understanding of the wx
doc-view implementation (or of wxList). Let me discuss them here,
providing simple testcases.
> It seems to work, and my very limited testing finds no user-observable
> defects. Here's the fundamental testcase:
> start lmi
> open 'sample.cns' from your local lmi cvs tree
> ctrl-R
> [optionally refocus the 'sample.cns' window; hit alt-R again; repeat...]
> [optionally, also do ctrl-shift-R with the '.cns' window focused]
> close 'sample.cns'
> All the '*.ill' child views close; then the 'sample.cns' view closes.
> That's what we want.
For the following testcases, 'sample.*' input files mean the ones in
lmi cvs. I won't repeat "start lmi" each time.
Test 0a
open 'sample.cns'
click that file's MDI-child close button
Expect CensusDocument::OnCloseDocument() to be called exactly once.
(It pops up a messagebox on entry and on exit.)
This succeeds.
Test 0b
open 'sample.cns'
File | Close [same as test 0a, but menu command instead]
Expect CensusDocument::OnCloseDocument() to be called exactly once.
Error: it's called twice.
Test 0c
open 'sample.cns'
File | Exit [same as test 0a, but exit lmi instead]
Expect CensusDocument::OnCloseDocument() to be called exactly once.
Error: it's called twice.
Test 1 (simplified version of testcase quoted above)
open 'sample.cns'
ctrl-R
click the 'sample.cns' MDI-child close button
Expect CensusDocument::OnCloseDocument() to be called exactly once.
Expect the child document to close, then its parent.
This succeeds.
Tests 1a and 1b (vary "close" methods as in 0a and 0b)
Error: same as for 0a and 0b, but worse because the second call
to CensusDocument::OnCloseDocument() crashes the program. Later
tests could be extended this way, but to do so seems pointless
until this defect is resolved.
Test 2
Same as test 1, but s/Ctrl-R/Ctrl-Shift-R/
Same outcomes.
Test 3
Same as test 1, but open two child doc-view pairs:
open 'sample.cns'
ctrl-R
refocus the 'sample.cns' window
ctrl-R
click the 'sample.cns' MDI-child close button
This succeeds.
Test 4
Same as test 3, but close one of the children manually first:
open 'sample.cns'
ctrl-R
click the 'sample.000000001.ill' MDI-child close button
ctrl-R
click the 'sample.cns' MDI-child close button
This crashes.
Therefore, we have:
Defect 1: multiple calls to CensusDocument::OnCloseDocument()
depending on method used for closing.
Defect 2: previously-closed children not removed from parent's
child list. See IllustrationDocument::~IllustrationDocument()
as patched: attempting to call
m_documentChildren.DeleteObject(this);
in order to address the observed defect directly simply causes
a different and earlier crash.