|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Shapes disappear from hidden sections | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Writer | Reporter: | schulten | ||||||
| Component: | ui | Assignee: | openoffice | ||||||
| Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> | ||||||
| Severity: | Trivial | ||||||||
| Priority: | P3 | CC: | issues, issues, jsc, michael.brauer | ||||||
| Version: | OOo 1.1 Beta | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 2000 | ||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
| Developer Difficulty: | --- | ||||||||
| Attachments: |
|
||||||||
|
Description
schulten
2003-05-17 17:05:16 UTC
Created attachment 6240 [details]
Form controls in hidden sections are lost when file is saved
Created attachment 6287 [details]
stripped bugdoc
confirming and targeting in the stripped bugdoc: * select one iof the radio buttons * save the document * reload the document * select the other radio button => the other section is shown, but does not contain the form controls anymore removing "randomly" from the subject - this is pretty good reproducible fs->mib: sounds like an XML file format problem to me... When a section is hidden (this is what the macro in the bugdoc triggers, by changing a user variable), then the controls in this section seem to be removed from the document, and stored somewhere else. Especially, the control models are removed from the form component hierarchy. Thus, they're not saved later on. I suspect that something similar holds for the shapes - they are also not present after reloading the document. note: the bug also happens on 6.0/1.0.x (which is not really surprising and supports the theory of the file format problem) In fact, it is not an XML filter problem, but an API problem: The API does not offer shapes in hidden sections, and it also does not handle shapes that are inserted into hidden sections correctly. Since the XML filters are API based, there is a problem in the import and in the export. Both API issues are caused by the fact that shapes in hidden sections are removed from the draw page. Related to the API problem is the issue that controls in hidden sections are also removed from their forms. The issue could be fixed in two ways: 1. The hidden shapes are not removed from the page any longer, but get a flag that they are hidden. This flag has to be evaluated by the UI and drawing methods, so this solution is not simple. 2. The hidden shapes are removed from the draw page, but the API and the form layer are able to handle such shapes. This solution is not simple as well. Both solutions are not doable for the OOo 1.1 RC, so I'm retargeting this bug to OOo 2.0. Armin, what do you think would be the right solution for the problem? changing component/QA contact to Writer. In fact, we're talking about all kinds of shapes here (not only form controls), which are lost from hidden sections. An idea for a quick, preliminary solution: How about showing all hidden sections during store and hiding them again afterwards? The lost shapes problem has been retargeted for OOo 2.0, because the solution is not simple. I'd like to try and convince you to raise priority and fix it in 1.1. Since the issue causes a data loss, it is quite serious. Data loss problems deserve high priority. One of my customers, a 1000 employee company is testing StarOffice for migration from MS to OOo, and they make heavy use of Word document templates with hidden sections today. The issue would more or less rule out SO for migration, which would be bad for Sun and me. I admit to have a commercial interest there too, they contacted me for consulting ;-) Data loss, important potential customer. Do you think it possible to give this problem enough priority to workaround/fix it in 1.1? changed summary The problem is not the export, but the import. For the export, one could simply make the shapes visible temporarily. But for the import, one has to make sure that the objects get invisible again. This sounds easy, but it isn't. There is a hight risk that other things break when changing the import. That's the reason for the 2.0 target. However, since the bug is a data loss, we will try to solve it as soon as possible (what due to the complexity of the fix will be later than the 1.1). To really solve this issue we have to add three new layers to the drawing layer that contain the hidden objects for the corresponding three already existing layers. These layers have to be supported by the API as well. The proposed solution looks very complicated at first sight. Since it is also a lot of work, let me ask again: if the problem occurs during import, why can the import filter not make all sections visible during import and hide them once the file has been read? This could save a lot of work, and it's not really a dirty solution. What I dislike about the new hidden three-layer drawpage is, that it will be extremely complicated to look for a particular shape, if it can be on one out of 6 (!) layers. Making the sections visible during import (and export) is not as simple as it might look like. There is no feature like "display hidden sections" and there are also conditions that can control the visibility. The problem with this issue is not that it is not fixable, but that any quick workaround has a high risk of either breaking the section export/import or the shape import/export in general, and that a safe and clean solution takes some time. The layers I've mentioned are an implementation detail. The will not be visisble in the user interface. This one got fixed via internal 108784 in CWS Aig02, thus it's fixed since Build 645m10. Verified in OOo build 645m13.8660 Status set to fixed and Target to OOo1.1 Closed. |