Apache OpenOffice (AOO) Bugzilla – Issue 18200
"Overwrite" flag in storeAsURL disturbs further save operations
Last modified: 2005-02-28 12:29:46 UTC
When a document (in this case a macro generated database report, that has to be further edited manually, but before that is automatically saved to the right location in the filesystem) is stored by calling oDocument.storeAsURL(sUrl, mFileProperties()) where mFileProperties(0).Name = "Overwrite" mFileProperties(0).Value = FALSE, all subsequent attempts to save the file via the "Save" menu entry in the GUI fail with a 'file exists' error. This occurred with OOo1.0.3, didn't change until OOo1.1RC1 and affects Win and Linux alike. This is mainly a nuisance, since you can close the document after it has been generated and saved, and every thing is forgotten when you reopen it, but it's still a bug (and should be easy to fix, I guess).
Hi Mathias, Think this one belongs in framework? Noel
I don't think that this is really a bug. "storeAsURL" does the same as "SaveAs" from the menu and so it consequently disables the "Save" button, because the document now is "safe". Keeping "Save" enabled wouldn't help you because it saves the document again to the same location you already saved it by macro (because with "storeAsURL" you changed its location). If you want to avoid that, use "storeToURL" in your macro. This keeps "Save" enabled and also doesn't change the location.
Sorry, but I have to insist it's a bug, I'll try to explain this a little further: I didn't mean that the Save button gets disabled while a document doesn't need saving, I was talking about an error that occurs when you try to save an altered document that has initially been saved by a macro using the 'SaveAsURL' function with the overwrite property set to false. Intended (and perfectly functional until 1.0.3) is the following: - the user clicks on a button in a database form - a macro generates a document from the current form content - the macro automatically names and saves the (incomplete) document to a given location (which depends on the database record and should therefore not be left to the user), leaving the document open for further editing - the user completes the document and clicks the "Save" Button in the File-Menu (possibly several times) to save his/her work. Since the macro can be invoked at any time, it has to make sure it won't overwrite an already finished document, so the 'Overwrite' property of the 'StoreAsURL' function has to be set to false. What is happening now is that, once the routine has successfully saved the document, this setting seems to be remembered by OOo, producing an error message when the user tries to save his/her work later. "StoretoURL" wouldn't do the job either: the user would be left with an unnamed document and the choice to save it wherever he or she wants... kind regards, Knut Hohenberg
OK, I agree that *this* is a bug. But the summary is wrong, I changed it to a more appropriate one. I pass the issue to the responsible developer for confirmation.
.
Looks like document's itemset entry was not cleared in time.
We need a clear definition which parts of the MediaDescriptor are considered to be properties of the medium and which are just temporary parameters. This should be added to the IDL and DevGuide documentation.
The original issue is fixed. The MediaDescriptor entries liftime review is covered by issue 29142.
Verified.
Closed.