Re: [api-dev] DocumentLoader memory leaking on cleanup
On 10/26/2010 05:26 PM, Chris Rider wrote: As you can tell from the log file, the close method is being called, but not the dispose. Do I need to dispose also? Couldn't really find enough documentation to figure out *exactly* what those two methods entail. I kind of assumed it was something like the difference between clearing the objects memory or not. No, it a component supports XCloseable, you must call close(), otherwise dispose(). As close() will call dispose() internally, all you can get from an explicit dispose() call is a DisposedException. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentLoader memory leaking on cleanup
Please disregard / delete / etc this thread...
I am merging this to another post
On 10/26/2010 11:26 AM, Chris Rider wrote:
I'm just creating logs with a function (see below for example)
I'm pretty sure it isn't being referenced anywhere else. We are merely
using this to initiate opening of the file.
Here is my C++ function...
void Cleanup(const Reference &component) {
WriteLog( "pid: %d - Cleanup\n", getpid() );
Reference< XCloseable > xCloseable(component, UNO_QUERY);
if ( xCloseable.is() ) {
WriteLog( "pid: %d - Cleanup - close - dispose\n", getpid() );
xCloseable->close(false);
} else {
WriteLog( "pid: %d - Cleanup - dispose\n", getpid() );
component->dispose();
}
}
As you can tell from the log file, the close method is being called,
but not the dispose.
Do I need to dispose also? Couldn't really find enough documentation
to figure out *exactly* what those two methods entail. I kind of
assumed it was something like the difference between clearing the
objects memory or not.
Besides any concern for other references being possibly needed (I
highly doubt there are any of consequence), it probably couldn't hurt
to dispose right after closing, within the same true if condition (?)
Thanks!
Chris
On 10/26/2010 03:00 AM, Mathias Bauer wrote:
On 10/25/2010 07:10 PM, Chris Rider wrote:
We are using DocumentLoader to manage the opening of PowerPoint files,
and have recently discovered what appears to be a memory leak.
As a quick background, these are self-advancing presentations, created
using Microsoft by the end-user, who then uses our product (CentOS
based) to display the files.
When the cleanup routine is called, it appears to do its thing, but a
bit of time later, the machine is almost frozen from all of its memory
being used up... and after taking a look at the processes on the
machine, we tracked it back to this.
Below is from our log file...
It looks like it reaches the end of the slideshow (event
OnEndPresentation) and fires the Cleanup routine... but is it working
past that point? Appears to not be.
Are there any known issues with this sort of thing? Anyone else seeing
this?
Thanks!
Chris
1288025660 : pid: 6935 - Acquiring lock...
1288025660 : pid: 6935 - Lock acquired!
1288025660 : pid: 6935 - Connected successfully to the office
1288025660 : pid: 6935 - XComponentloader successfully instantiated
1288025660 : pid: 6935 -
argv[1]=/home/silentm/public_html/multimedia/951918099.Clarian.ppt
1288025660 : pid: 6935 - Document:
file:///home/silentm/public_html/multimedia/951918099.Clarian.ppt
1288025661 : pid: 6935 - Starting Presentation...
1288025661 : pid: 6935 - Presentation Started!
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Releasing lock...
1288025661 : pid: 6935 - Lock released!
1288025661 : pid: 6935 - Wait for end!
1288025661 : pid: 6935 - Event : OnUnfocus received
1288025661 : pid: 6935 - Event : OnStartPresentation received
1288025661 : pid: 6935 - Event : OnFocus received
1288025661 : pid: 6935 - Event : OnLoad received
1288025662 : pid: 6935 - Event : OnEndPresentation received
1288025662 : pid: 6935 - Ending!
1288025662 : pid: 6935 - Event : OnViewClosed received
1288025662 : pid: 6935 - Event : OnUnfocus received
1288025664 : pid: 6935 - Cleanup
1288025664 : pid: 6935 - Cleanup - close - dispose
I don't know how you created your logs, but at least in this log I
don't see traces of the document being closed (Event OnClose,
disposing etc.). But maybe that's part of the last line.
Besides that, the document being closed does not mean that it is
removed from memory. It's possible that it is still referenced
somewhere and so the object is not destroyed. I think that eating up
the memory completely - as you described it - would require thousands
of such dangling references, but you never know.
So look for references to documents (models) in your code. In case
your application is implemented in Java, don't rely on the garbage
collection doing the work for you, it might kick in just too late.
Regards,
Mathias
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
[api-dev] Document Server chaos -- not talking properly, intermittently
(I previously posted something about Document Loader - that is now revised and different, hence this post ~~ You'll find this post much more informative, I hope!) Please forgive me for causing any confusion... I was put on this project after another engineer here took another position, so I've been playing catch-up on understanding it fully enough to at least put out a lucid question to this community. Your patience and time is very much appreciated!!! The previous developer wrote a C++ program that we call DocumentLoader, that talks to the Document Server, and loads a PPT file. The Loader file has been through extensive testing and debugging, so I/we HIGHLY doubt the problem lies within it (been wrong before though!). Typically, these PPT files are setup as "slideshows" that auto-advance their slides and usually repeat/rotate, as managed by our own product (a type of multimedia messaging solution). Just for the sake of example, this might be a "daily announcements" slide-show set to display (amongst other types of messages) every 5 minutes (the other types of messages would show the remainder of the time, rinse, repeat, etc.) So here's the problem.. Whenever DocumentLoader tells the Document Server to take down the PPT file, it appears to; but when it comes time to load it to display it again, it will - seemingly without problem... except that the machine's memory keeps getting sucked down (the machine that's running the server program). And, each time it cycles through (loads), there is about one-second added to the load time. So a PPT that normally takes about 2 seconds to load, by the 6th time, takes like 8 seconds. And to make matters worse, once we hit about a dozen or so loads, the machine practically becomes non-responsive until we restart it. Also, (more just to see my debugging logic) we occassionally see multiple instances of the DocumentLoader program (like 20 or more) trying to load the same PPT file. I figure this is "normal" in-so-much-as the loader is trying to talk the server into loading that PPT (in the timed loop I described above), and the server is failing for whatever reason to either respond to the loader and/or actually load the file. I've been consulting with the previous engineer, as well as another programmer here, and there is some agreement that there could be a memory leak in the server program. It is very hard to debug, because we have this deployed on hundreds of machines, and only a handful or so behave this way ~ seemingly randomly, at that. I've not been able to find much info about this "server" ~~ can anyone enlighten me? Furthermore, is this a known issue of any kind? Even if just to say "welcome" (I'm new to the list), I'd appreciate any ideas!!! :) Humbly, Chris - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] DocumentLoader memory leaking on cleanup
I'm just creating logs with a function (see below for example)
I'm pretty sure it isn't being referenced anywhere else. We are merely
using this to initiate opening of the file.
Here is my C++ function...
void Cleanup(const Reference &component) {
WriteLog( "pid: %d - Cleanup\n", getpid() );
Reference< XCloseable > xCloseable(component, UNO_QUERY);
if ( xCloseable.is() ) {
WriteLog( "pid: %d - Cleanup - close - dispose\n", getpid() );
xCloseable->close(false);
} else {
WriteLog( "pid: %d - Cleanup - dispose\n", getpid() );
component->dispose();
}
}
As you can tell from the log file, the close method is being called, but
not the dispose.
Do I need to dispose also? Couldn't really find enough documentation to
figure out *exactly* what those two methods entail. I kind of assumed it
was something like the difference between clearing the objects memory or
not.
Besides any concern for other references being possibly needed (I highly
doubt there are any of consequence), it probably couldn't hurt to
dispose right after closing, within the same true if condition (?)
Thanks!
Chris
On 10/26/2010 03:00 AM, Mathias Bauer wrote:
On 10/25/2010 07:10 PM, Chris Rider wrote:
We are using DocumentLoader to manage the opening of PowerPoint files,
and have recently discovered what appears to be a memory leak.
As a quick background, these are self-advancing presentations, created
using Microsoft by the end-user, who then uses our product (CentOS
based) to display the files.
When the cleanup routine is called, it appears to do its thing, but a
bit of time later, the machine is almost frozen from all of its memory
being used up... and after taking a look at the processes on the
machine, we tracked it back to this.
Below is from our log file...
It looks like it reaches the end of the slideshow (event
OnEndPresentation) and fires the Cleanup routine... but is it working
past that point? Appears to not be.
Are there any known issues with this sort of thing? Anyone else seeing
this?
Thanks!
Chris
1288025660 : pid: 6935 - Acquiring lock...
1288025660 : pid: 6935 - Lock acquired!
1288025660 : pid: 6935 - Connected successfully to the office
1288025660 : pid: 6935 - XComponentloader successfully instantiated
1288025660 : pid: 6935 -
argv[1]=/home/silentm/public_html/multimedia/951918099.Clarian.ppt
1288025660 : pid: 6935 - Document:
file:///home/silentm/public_html/multimedia/951918099.Clarian.ppt
1288025661 : pid: 6935 - Starting Presentation...
1288025661 : pid: 6935 - Presentation Started!
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Frame:
1288025661 : pid: 6935 - Releasing lock...
1288025661 : pid: 6935 - Lock released!
1288025661 : pid: 6935 - Wait for end!
1288025661 : pid: 6935 - Event : OnUnfocus received
1288025661 : pid: 6935 - Event : OnStartPresentation received
1288025661 : pid: 6935 - Event : OnFocus received
1288025661 : pid: 6935 - Event : OnLoad received
1288025662 : pid: 6935 - Event : OnEndPresentation received
1288025662 : pid: 6935 - Ending!
1288025662 : pid: 6935 - Event : OnViewClosed received
1288025662 : pid: 6935 - Event : OnUnfocus received
1288025664 : pid: 6935 - Cleanup
1288025664 : pid: 6935 - Cleanup - close - dispose
I don't know how you created your logs, but at least in this log I
don't see traces of the document being closed (Event OnClose,
disposing etc.). But maybe that's part of the last line.
Besides that, the document being closed does not mean that it is
removed from memory. It's possible that it is still referenced
somewhere and so the object is not destroyed. I think that eating up
the memory completely - as you described it - would require thousands
of such dangling references, but you never know.
So look for references to documents (models) in your code. In case
your application is implemented in Java, don't rely on the garbage
collection doing the work for you, it might kick in just too late.
Regards,
Mathias
-
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Although I am ignorant in much of this, I do have some random thoughts. Mathias Bauer mentioned allowing the container to control changes for some items (such as he did with notes2), but that this may be a problem with larger objects such as graphics objects and even OLE objects. On the other hand, I do not expect that an OLE object will have any ability to actively participate in the undo process, which forces implementation back to the container (or you simply state that changes made to an OLE object internally are not undoable). For some reason, I keep thinking about the implications of a linked sheet in a Calc document. Now it sounds like two possible interfaces, one controlled by the container and one controlled by the object (that may have an edit engine). There was also talk of throwing multiple types of exceptions when an error occurs. Does this prevent some languages (such as Basic, Perl, and similar) from participating in this scheme? Can/will the undo API affect extensions? Any thoughts on database actions? It does not seem reasonable that a SQL statement will participate, even for an internal Base document, this could be a very long running transaction. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Frank, Frank Schönheit wrote: For the moment, I declared an UndoFailedException, derived from css.uno.Exception, and let undo/redo throw it. Still an euphemism for "anything can go wrong", though, so I am not that happy with it ... I think a new UndoFailedException is better than css.uno.Exception. A client can react on this with a small cleanup of whatever UndoStack related doings and than proceed further. While catching a css.uno.Exception the proper reaction is much more unclear. Maybe it is necessary to quit the whole process? Kind regards, Ingrid - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
On 10/26/10 11:48, Frank Schönheit wrote: I think any kind of error can happen inside an undo implementation for a single action, so I can't think of any reasonable limitation here. A WrappedTargetException might be appropriate, but then again, this is just an euphemism for "anything can happen". I see it differently. ... If an initial undo method has been specified to raise n different exceptions, and it is later found out that an additional exception E' would be needed, there are two choices: - E' is of general interest to callers of undo, they would want to react to it in specific ways. This is similar to detecting that a method misses a parameter: Extend the method (add the raises-specification to the existing method definition, rendering it incompatibly, or add a new interface with the fixed method), fix up the implementation, fix up the call sites. Given the hurdles imposed on incompatible API changes, I dare to go this way - experience shows rarely anybody ever goes through this pain, "only" for having a clean API. Usually one ends up with throwing, guess, WrappedTargetRuntimeExceptions (I thus consider the mere existence of this class a bad hack. Well, a way-too-easy door opener for bad hacks, that is.). For the moment, I declared an UndoFailedException, derived from css.uno.Exception, and let undo/redo throw it. Still an euphemism for "anything can go wrong", though, so I am not that happy with it ... For undo, I see three interesting return cases: - Normal return; the underlying data model is in a state where the respective changes are indeed undone. - Exception "failed for some reason, undo call completely rolled back", i. e. the underlying data model is in the state it was in before the call to undo. It would probably be useful (if only for debugging) to transport the "for some reason" in the exception (as an any containing an exception). - Exception "failed for some reason, but not rolled back", i. e. the underlying data model is in some valid state, but it is potentially neither the state before the call to undo, nor the state of a successful undo. Again, it would probably be useful to transport the "for some reason." Everything else (failed, and the underlying data model is in some potentially invalid state) calls for a runtime exception. So, the UndoFailedException might indeed be the way to go here. -Stephan - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Attempt for an UNO Undo API
Hi Stephan, >> I think any kind of error can happen inside an undo implementation for a >> single action, so I can't think of any reasonable limitation here. A >> WrappedTargetException might be appropriate, but then again, this is >> just an euphemism for "anything can happen". > > I see it differently. > ... > If an initial undo method has been specified to raise n different > exceptions, and it is later found out that an additional exception E' > would be needed, there are two choices: > > - E' is of general interest to callers of undo, they would want to react > to it in specific ways. This is similar to detecting that a method > misses a parameter: Extend the method (add the raises-specification to > the existing method definition, rendering it incompatibly, or add a new > interface with the fixed method), fix up the implementation, fix up the > call sites. Given the hurdles imposed on incompatible API changes, I dare to go this way - experience shows rarely anybody ever goes through this pain, "only" for having a clean API. Usually one ends up with throwing, guess, WrappedTargetRuntimeExceptions (I thus consider the mere existence of this class a bad hack. Well, a way-too-easy door opener for bad hacks, that is.). For the moment, I declared an UndoFailedException, derived from css.uno.Exception, and let undo/redo throw it. Still an euphemism for "anything can go wrong", though, so I am not that happy with it ... Ciao Frank -- ORACLE Frank Schönheit | Software Engineer | frank.schoenh...@oracle.com Oracle Office Productivity: http://www.oracle.com/office - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Dialog control like JPanel in UNO awt
Hi,
Il 26/10/2010 05:33, Pivithuru Wijegunawardana ha scritto:
Hi,
I am searching for a JPanel in java like performing dialog control in
Openoffice to contain some other controls inside. And this control model
should be able to make visible and invisible such that the controls inside
it also does the same action. I looked into UnoControlGroupBoxModel, but it
seem to be only a visual component to group controls.
Is the above task possible in UNO awt? If it is possible what control I
should use for that?
The basic and most spread technique to control the visibility of groups
of controls is by means of "dialog steps"
You may think to dialog steps just like to layers.
Each layer may contain controls.
Both dialog and control models offer a "Step" property that can be set
to an integer value at design time or even at runtime.
If you set the Step property of the dialog to a given value, only
controls with the same Step value are shown
The Step=0 have a special meaning:
If you set the *dialog* Step to 0 , all controls will be made visible,
regardless their Step actual value.
If you set one control Step to 0 , that control wil be always visible,
regardless the current Step value of the dialog.
A more versatile technique is by using the service:
com.sun.star.awt.UnoControlContainer
Is not easy to use this control in dialogs, because it is not available
in the toolbox of the dialog designer (you cannot use it at design time)
Another problem is that UnoControlContainer is not even registered at
the XMultiServiceFactory of the UnoDialog model, so in theory you
couldn't even use it at runtime.
In order to workaround the above mentioned limitations, I use a
technique that makes use of normal FixedText controls as "placeholders"
at design time.
(Actually you can use any kind of control as placeholders but the
fixedtext is the more suitable since it doesn't react to mouse/keyboard
events and it doesn't eat much resources )
At runtime, placeholder controls are replaced (or better: overlayed) by
a UnoControlContainer instanciated from the main MultiServiceFactory
Please, see the example below:
(before to run it you should prepare an Uno dialog named "Dialog1" with
two labels (UnoFixedText controls) named "Label1" and "Label2"
More examples of that technique are in the source code of the
BasicAddonBuilder extension:
http://www.paolo-mantovani.org/downloads/BasicAddonBuilder/
regards
Paolo Mantovani
--8<--
REM * BASIC *
Sub Main
oDlg = CreateUnoDialog(DialogLibraries.Standard.Dialog1)
xray oDlg
oLbl1 = oDlg.getControl("Label1")
oLbl2 = oDlg.getControl("Label2")
'create a child window in the area of the oLbl1
aPosSize = GetRect(0, 0, oLbl1.Size.Width, oLbl1.Size.Height)
oViewFrame = CreateChildFrame(oLbl1.Peer, aPosSize)
'create a control container service that will host the whole TranslateBox
oCont1 = CreateUnoControl("Container")
With oCont1.Model
.Border = 1 ' 3D border
'.BackgroundColor = //
End With
oCont1.createPeer(oViewFrame.ContainerWindow.Toolkit,
oViewFrame.ContainerWindow)
oViewFrame.setComponent(oCont1, Null)
'create a child window in the area of the oLbl1
aPosSize = GetRect(0, 0, oLbl2.Size.Width, oLbl2.Size.Height)
oViewFrame = CreateChildFrame(oLbl2.Peer, aPosSize)
'create a control container service that will host the whole TranslateBox
oCont2 = CreateUnoControl("Container")
With oCont2.Model
.Border = 1 ' 3D border
'.BackgroundColor = //
End With
oCont2.createPeer(oViewFrame.ContainerWindow.Toolkit,
oViewFrame.ContainerWindow)
oViewFrame.setComponent(oCont2, Null)
oButton1 = InsertNewControl(oCont1, "Button", "Button1")
oButton1.Label = "1"
oButton2 = InsertNewControl(oCont2, "Button", "Button2")
oButton2.Label = "2"
oDlg.execute
End Sub
'__
Function CreateChildFrame(oParentWin As Object, aPosSize As Object) As
Object
Dim oChildWin As Object
Dim oToolkit As Object
Dim oChildFrame As Object
oToolkit = oParentWin.getToolkit
Dim aDescriptor as new com.sun.star.awt.WindowDescriptor
With aDescriptor
.Type = com.sun.star.awt.WindowClass.SIMPLE
.WindowServiceName = ""
'.ParentIndex = 0
.Parent = oParentWin
.Bounds = aPosSize
.WindowAttributes = com.sun.star.awt.WindowAttribute.SHOW '+
com.sun.star.awt.WindowAttribute.BORDER
End With
oChildWin = oToolkit.createWindow(aDescriptor)
oChildFrame = createUnoService("com.sun.star.frame.Frame")
oChildFrame.initialize(oChildWin)
CreateChildFrame = oChildFrame
End Function
'__
Function GetRect(nX, nY, nWidth, nHeight) As Object
Dim aRect as new com.sun.star.awt.Rectangle
With aRect
.X = nX
.Y = nY
.Width = nWidth
.Height = nHeight
End With
GetRect = aRect
End Function
'
Re: [api-dev] DocumentLoader memory leaking on cleanup
On 10/25/2010 07:10 PM, Chris Rider wrote: We are using DocumentLoader to manage the opening of PowerPoint files, and have recently discovered what appears to be a memory leak. As a quick background, these are self-advancing presentations, created using Microsoft by the end-user, who then uses our product (CentOS based) to display the files. When the cleanup routine is called, it appears to do its thing, but a bit of time later, the machine is almost frozen from all of its memory being used up... and after taking a look at the processes on the machine, we tracked it back to this. Below is from our log file... It looks like it reaches the end of the slideshow (event OnEndPresentation) and fires the Cleanup routine... but is it working past that point? Appears to not be. Are there any known issues with this sort of thing? Anyone else seeing this? Thanks! Chris 1288025660 : pid: 6935 - Acquiring lock... 1288025660 : pid: 6935 - Lock acquired! 1288025660 : pid: 6935 - Connected successfully to the office 1288025660 : pid: 6935 - XComponentloader successfully instantiated 1288025660 : pid: 6935 - argv[1]=/home/silentm/public_html/multimedia/951918099.Clarian.ppt 1288025660 : pid: 6935 - Document: file:///home/silentm/public_html/multimedia/951918099.Clarian.ppt 1288025661 : pid: 6935 - Starting Presentation... 1288025661 : pid: 6935 - Presentation Started! 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Frame: 1288025661 : pid: 6935 - Releasing lock... 1288025661 : pid: 6935 - Lock released! 1288025661 : pid: 6935 - Wait for end! 1288025661 : pid: 6935 - Event : OnUnfocus received 1288025661 : pid: 6935 - Event : OnStartPresentation received 1288025661 : pid: 6935 - Event : OnFocus received 1288025661 : pid: 6935 - Event : OnLoad received 1288025662 : pid: 6935 - Event : OnEndPresentation received 1288025662 : pid: 6935 - Ending! 1288025662 : pid: 6935 - Event : OnViewClosed received 1288025662 : pid: 6935 - Event : OnUnfocus received 1288025664 : pid: 6935 - Cleanup 1288025664 : pid: 6935 - Cleanup - close - dispose I don't know how you created your logs, but at least in this log I don't see traces of the document being closed (Event OnClose, disposing etc.). But maybe that's part of the last line. Besides that, the document being closed does not mean that it is removed from memory. It's possible that it is still referenced somewhere and so the object is not destroyed. I think that eating up the memory completely - as you described it - would require thousands of such dangling references, but you never know. So look for references to documents (models) in your code. In case your application is implemented in Java, don't rely on the garbage collection doing the work for you, it might kick in just too late. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
Re: [api-dev] Re: Attempt for an UNO Undo API
On 10/18/2010 05:16 PM, Malte Timmermann wrote: Or implementations w/o support for ref counting: For example, each EditEngine Undo action needs to have an EditEngine*. And EditEngines in OOo are destroyed and re-created quite frequently. Maybe using an own Undo manager for the EditEngine is wrong. When we implemented Notes2, I finally ended up with letting the container (Writer) tracking the changes, I didn't create an additional undo manager for the note(s). That means, each time when an undo entry shall be created, the Writer just copies the content of the outliner object inside the note. For more complicated cases this could be improved by a better encapsulation of what needs to be copied by providing suitable methods in the Outliner class. This way we got an Undo that is not prone to crashes and that doesn't depend on whether the user is editing the note or the text of the document. It also appeared that giving access to all entries of the undo stack while editing in a note doesn't create a problem if the implementation of the notes view is aware of sudden destruction (something that IMHO is necessary anyway). I think that we could apply this idea to drawing objects also. For OLE objects OTOH this probably wouldn't help as copying the whole object each time it changes surely would be too much. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
