Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||File|Reload does not report errors|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description sgp 2002-09-09 04:42:01 UTC
If, after a .sxw file is opened in OpenOffice.org, that file changes on disk (eg, a developer unzips content.xml then re-zips to same_filename.sxw), File|Reload will *silently* fail if the new document is not valid. It will take the cursor to the top of the current document, giving the impression that the file has indeed been reloaded. I encountered this problem because I am writing an application which creates .sxw files. I was trying various features, reloading the file each time to check if the change worked as expected. The change appeared not to work, so I tried another, and so on. After half a dozen changes, OO.org crashed, and I found that I needed to keep on backing-out my changes until I found the bug in my code. This is a pain for non-OO.org developers trying to test that their applications work with the OO.org file format. It is also, presumably, a pain for OO.org developers. The workaround is to use File|Close, followed by File|Open, but this is a pain, especially since because closing the last document closes the application.
Comment 1 sgp 2002-09-09 04:47:30 UTC
Sorry, the mention of OO.org crashing was not very clear - I'm not sure why it crashed, but the crash meant restarting OO.org, re-loading the document (using File|Open), which was the first time OO.org said that there was a problem with the document. That bug (in my .sxw-creation code) had been made many revisions before, but File|Reload had been silently failing, so it was only when the crash forced me to use File|Open that I found the bug in my own code. File|Reload should perform the same checks, and issue the same errors, as File|Open.
Comment 2 stefan.baltzer 2003-03-31 17:25:06 UTC
I agree that File-Reload should behave EXACTLY like file-close-file-open. Confirming issue. -> Eric: Please have a look.
Comment 3 eric.savary 2003-11-05 18:26:42 UTC
ES: OOo creates a tmp file when the doc is opened and works on this tmp file the whole time. Not on the file on your home directory. ES->TM: for it's a framework issue, please evaluate.
Comment 4 malte_timmermann 2003-11-10 10:19:01 UTC
Seems ES wanted to send to TM, not to MT (me)...
Comment 5 thorsten.martens 2003-11-10 13:53:05 UTC
TM->MBA: Please have a look. As far as I know, a reload is surely not the same as a file-close / file-open operation for some reason. Maybe this is more a wish for a change in a feature or an enhancement than a real defect.
Comment 6 sgp 2004-07-02 03:32:28 UTC
I don't agree that this is an RFE; File/Reload should produce the same result as File/Close followed by File/Open. What is the purpose of File/Reload? The end user does not know or care that SO/OOo works on a /tmp file; that is an implementation detail. The functionality of File/Reload must have a defined purpose. From ES's comment, that purpose appears to be "no purpose". As a user, I would expect File/Reload to re-visit the file I had specified to be opened (not some temporary file SO/OOo had chosen to create) and, effectively, close the current file "in memory" and go back to my "staroffice somefile.sxw" state. Removal of the "File/Reload" menu item is an acceptable action. The only other action would be to make the function work as rationally expected.
Comment 7 sgp 2004-07-02 03:45:29 UTC
The existing definition from es (Nov 5 2003) sounds more suitable for an "Edit/Undo Changes" application than a "File/Reload". I do not find "File/Reload" essential, merely useful. Reassigning this as "Edit/Undo Changes" sounds more appropriate for this "feature" as currently implemented, unless I am missing something here.
Comment 8 Mathias_Bauer 2006-02-10 12:24:58 UTC
The code for reload is a nightmare because we try to keep the view though we have thrown away the document (otherwise we couldn't open the file for writing!). We could get rid of a bunch of issues by replacing the current procedure by a simple"close/load" procedure (of course with the "side effect" that the document closing will be *visible* to the user). Something like temporarily switching the window to "backing mode" and then reopening the file is what I would want to do. I definitely would opt for this change. Frank, please give a comment from the user experience standpoint. In case you agree the target could be set to "3.0"
Comment 9 frank.loehmann 2006-02-10 15:00:28 UTC
FL: The "Reload" function is no hard requirement for an office application from my point of view and the competition does not offer this function at all. I think this requirement comes from past times when SO was a "web browser" many years ago. Removing the function might be an option but I have no data to back this decision and so we maybe disappoint some "normal" users used to this functionality. Furthermore I do not understand that is is possible to exchange the original document while a tmp copy of the document it is loaded. I thought that even the original document file must be locked as long the copy of the document is opened somewhere. Disabled file locking on a Linux system? So I propose to rework the current implementation to the simple"close/load" procedure like MBA has described above. I have no problem with closing and reopening the document in front of the backing window (is this possible even if it is not the last doc?) and that this is visible to the user - this is feedback and indicates what is currently in progress. Even the cursors position must not be the same after reloading, because the current part of the document might not be contained in the original document at all and again it is feedback for the reload being in progress. But the container attributes (window position, size, document position inside the window and the document zoom level) should be restored from recently closed working document from a usability perspective. I would agree to set this to OOo 3.0 (to simplify internal doc handling), even if I think this is not the most important issue, because normal user will have no problems with the current implementation.
Comment 10 sgp 2006-02-10 23:14:24 UTC
WRT the file-locking issue, it's nothing to do with file locking AFAICT. On a standard Ubuntu "Breezy Badger" install (OOo 1.9.129), using reiserfs (mounted "rw,notail"), the following simple test: - Create test1.odt containing the text "Test One" - Create test2.odt containing the text "Test Two" (or indeed a garbage file) - Close test1.odt and test2.odt - File/Open test1.odt - $ cp test2.odt test1.odt (or 'echo foo > test1.odt') - File/Reload - Observe that test1.odt ("Test One") is still displayed