Apache OpenOffice (AOO) Bugzilla – Issue 123276
layer visibility status change after page switch and then are not correctly shown in lower tab
Last modified: 2014-02-10 09:32:27 UTC
1) open attached Draw document with 2 pages and some objects on every layers of page 1. 2) disable layers "Controls" and "Dimension lines" using SHIFT+left click on lower tab ==> (some object disappear and layer names become blue in lower tab) 3) change to page 2 4) back to page 1 ==> now all objects are shows again, but lower tab names remain in blue From now on, layer status shown in lower tab is wrong. Clicking again on lower tab seems synchronize real status with shown status, but with this bug become impossible to know if each layer is really on or off, without activating each every time.
Created attachment 81561 [details] Draw example with objects on layers
I forgot to mention, it is a regression, this effect was not present on 3.4.1
ALG: I checked with AOO341. The logic is to keep the state of the LayerTabBar, but to use their setting when page is changed. Example: New draw, one object on each layer (activate layer, draw object). Second page, same (I colored the objects to make them easier to distinguish). When switching pages the state of the Layers stays in the LayerTabBar, but is resetted on the newly shown page. Thus the error is: PageChange in draw/impress does not set the current LayerState correctly at the newly shown page. Checking...
ALG: With my testfile it works exactly the same in AOO400 and AOO341. Also works the described way in OOO330 and OOO320 (in OOO220 the controls layer is not shown, but else the same). In AOO341 your example file works, in AOO400 not. It works when I do the following: in AOO400 load testfile, change to 2nd page, draw an object on each layer, all switching (layer on/off, pages) works well. Something strange is going on (maybe in the file? How was it created?). When following the description and switching (step 3) a short flicker repaint shows all objects already...
I got the bad behavior on many different drawings, not only in the attached one, that is simply an extract. I will look for a drawing in my archive that do not show this behavior Maybe there is same interaction with some user settings that activate the bad behavior. Apart grid settings, my profile is quite new created by 4.0 installer.
Confirmed on Linux 64 bit too (OpenOffice 4.0.1 RC1); same behavior as Armin described. I didn't test with older versions.
ALG: Looks as if with the page change a DrawViewShell::ReadFrameViewData is somehow triggered for the shell change which deletes the layers set, need to check deeper. @efa: Thanks for the additional infos!
ALG: DrawViewShell::Deactivate was changed in drviews1, thus there will be no deactivate and thus the values will not be saved. The following activate will then use the wrong values, as it seems. Need to find out why this was changed...
ALG: Done by af with r1486578, as fix for task 122332 as it seems. Af knows better about this context switches, thus I will note him about this sideeffect of the former fix. @af: The missing call to DrawViewShell::Deactivate leads to problems when switching to the 2nd page in the example: DrawViewShell::ReadFrameViewData is called in activate without a former call to DrawViewShell::WriteFrameViewData since deactivate is missing. In this example the changed visible layers is lost, but in principle any changed setting in a FrameView will be lost this way. Please have a look.
(In reply to Armin Le Grand from comment #9) > ALG: Done by af with r1486578, as fix for task 122332 as it seems. Af knows > better about this context switches, thus I will note him about this > sideeffect of the former fix. > > @af: The missing call to DrawViewShell::Deactivate leads to problems when > switching to the 2nd page in the example: DrawViewShell::ReadFrameViewData > is called in activate without a former call to > DrawViewShell::WriteFrameViewData since deactivate is missing. In this > example the changed visible layers is lost, but in principle any changed > setting in a FrameView will be lost this way. Please have a look. While at it, please look at bug 121863 comment 19
Looks like there is a little more work necessary than just not forwarding the Deactivate() call from DrawViewShell to ViewShell. In fact, the purpose of the change was to omit the call to BroadcastContextForActivation() in SfxShell::Deactivate(), where SfxShell is the base class of ViewShell. Fixing this should be straightforward. The only question is, how to do it in a way, that does not look like a hack. At the moment I am thinking about adding a flag to the context change broadcaster (the one that has the BroadcastContextForActivation() method) that would deactivate it temporarily, and deactivate it from inside DrawViewShell::Deactivate(). But that does look a bit like a hack.
happen about with all drawings, also simples one like the new attached
Created attachment 81685 [details] simplest example
"af" committed SVN revision 1528376 into trunk: 123276: Properly forward Deactivate() call and still don't broadcast context ...
Added a flag to the ContextChangeBroadcaster in sfx2/source/sidebar that allows DrawViewShell::Deactivate() to temporarily deactivate context change broadcasting and still forward the Deactivate() call to its base class.
ALG: Checked, works again, closing.