On 10/03/2010 14:26, fan Zheng wrote: > Hi, Michael: > Thanks for your response! > > 2010/3/10 Michael Stahl <michael.st...@sun.com> > >> On 09/03/2010 08:27, fan Zheng wrote: >>> Hi, All: >>> >>> I have a question about the Change Recording (Redline), would you pls >> give >>> me some tips on it? >>> >>> As all we know, under the redline mode "Show", the content of all changes >>> with type "Delete" recorded in the redline table of current document will >>> still be visible in the context. >>> >>> And if we change the redline mode from "Show" to "Hide", said "Delete" >> typed >>> changes related content will be invisible by moving said content from >> main >>> body of document into the segment of hided changes (SHC). >>> >>> Said operation Hide for "Delete" changes was designed in 2 ways >> (Implemented >>> in SwRedline::Hide()): >>> A. Move delete changes related content from main body into SHC; >>> B. Make a copy of delete changes related content in SHC, and remove the >>> original content from main body; >>> >>> Said design B is for almost all invoking of SwRedline::Delete(). And >> design >>> A is only invoked in the SwDoc::CompressRedlines(), which is a method for >>> combining the existed change records. >>> >>> My question is, what do we concerned about to make the design of Hide in >> 2 >>> different ways? >> this is a very interesting question. >> in fact i have probably asked it myself :) >> the problem is that nobody knows the answer... the original authors of the >> sw redline code have left many years ago. >> >> i can only speculate that in some cases there can be a difference whether >> some range is moved or copied and then deleted. >> for example, if the range contains frames, or footnotes, which have a >> special section at the beginning at the nodes array for their content. >> or maybe the reason has something to do with undo. >> > > > Doing something with undo... Gash, that is my biggest headache currently. > > In OO, Some flying object related undo action in SW, for example the inherit > class of SwFlyingUndoBase, refer a SwFlyFrmFmt pointer as a member data, all > the recording modifications must be undone or redone on the flying object > through said pointer. For maintaining the validate of the pointer, any user > modification of flying object must have corresponding undo action to be > recorded into undo list. Some special modifications, such as the deletion of > flying object, will just remove the corresponding SwFlyFrmFmt from the > flying frame format list of data module (SwDoc::pSpzFrmFmtTbl), and the > exact memory alloced in heap is not actually destructed. The destruction of > said flying frame format could be invoked inside the corresponding undo > actions. > > But on the other side, in the process of changing redline mode from "Show" > to "Hide", the Deleted sections will be copied into SHC (by > SwRedline::CopyToSection) and the original parts will be deleted from data > module (by SwRedline::DelCopyOfSection), which is the directly deletion > without any corresponding undo action recorded in (of cause should be > designed like this. For changing redline mode from Show to Hide is not exact > a user modification). That means, if there is any flying object inside > corresponding deletion range, it will be deleted directly (destructed > already). Any said flying object related undo actions recorded in list > become time bombs. Crash is just standing at the corner of the street.
hmmmm.... that sounds pretty bad... i'm not (yet) familiar with most of the code that handles frames. i've looked a bit in issuezilla, and there is this: http://www.openoffice.org/issues/show_bug.cgi?id=101666 this issue seems to be caused by the design flaw you describe. > In general, this is a problem about a same data managed by different > patterns. Obviously, the design of undo action and design of redline is made > by different person or team, right? i'm not sure... from what i've heard i think it was more a problem of "the boss says it must be finished tomorrow, so let's take some shortcuts". nowadays we don't work like that anymore :) > The best way for solving said problem should be: shift "copy/delete" way > into "move" way. And that is why I asked the former question... there is also a comment in the issue by cmc (Caolán McNamara): > Hmm, using MoveToSection/MoveFromSection in the redline stuff instead of > CopyToSection/DelCopyOfSection would workaround this by transferring the > SwFrmFmt around instead of making a copy of it and deleting this original, but > causes other problems later. redlining is such a horror maybe cmc remembers what problems exactly are caused by Move...? > Do you any better idea on it? maybe it would be possible to create a copy of the SwFrmFmt when creating the undo object? that way the show/hide cannot invalidate the undo object. > Thanks alot ! > Easyfan.Zheng > >> maybe there was a reason many years ago, but today that reason no longer >> exists? >> >> i guess the only way to find out would be to change the implementation to >> do it only one way, and then test a lot to see what breaks. >> >> actually, imho, the redline design in writer is fundamentally broken, >> because the redlines are really part of the document model. >> the option to change the redline mode from "Show" to "Hide" is purely a >> view option, and should not change the document model in any way. regards, michael -- "Simplicity is the ultimate sophistication." -- Leonardo da Vinci --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@sw.openoffice.org For additional commands, e-mail: dev-h...@sw.openoffice.org
