In Version 4.0.0.0.alpha1+ (Build ID: e14b5f33ceae3280b46eb97a88b949d00263956) on Ubuntu 12.04 opening of file with conditional formatting elements original conditional formatting setting (in sample file if cell value is > 0, than cell style = Number) is changed to empty value (if cell value is equal = (empty box), then Default style). When the same file is opened in previous versions of libeoffice, conditional formatting settings survive on file open. This problem arised from testing of peoblems with conditional formatting here https://bugs.freedesktop.org/show_bug.cgi?id=57176
Created attachment 71012 [details] Conditional formatting settings are lost on file open
(In reply to comment #1) > Created attachment 71012 [details] > Conditional formatting settings are lost on file open Conditional formatting settings mentioned in the first comment are in cells J12:AN26
[Reproducible] with reporter#s sample and with parallel installation of "LOdev 4.0.0.0.alpha1+ - ENGLISH UI / German Locale [Build ID: 6aabe09ac092c51d4b394bde9c7ea0055b952e3)]" {tinderbox: Win-x86@6, pull time 2012-11-26 00:29:34} on German WIN7 Home Premium (64bit) with own separate User Profile: In janv.N12 with menu 'Format -> Conditional Formatting -> Condition' only the "Cell Value is" is shon correctly, "Bigger Than" is shoen as "equal to", and in the condition field nothing is shown instead of the number "0". Might be a UI problem, CF works correctly for that cell, and when I save an edited document with LibO 4.0 the conditions for N12 are shown correctly in LibO 3.6.4 With "LibreOffice 3.6.4.3 rc" German UI/ German Locale [Build-ID: 2ef5aff] {pull date 2012-11-28} on German WIN7 Home Premium (64bit) I see the conditions shown correctly in the dialog. Has nothing to do with "old document", when I correct the CF settings for N12 wiht LibO 4, close CF dialog and reopen dialog my correct settings are "lost" again. And even worse: My changes will not be applied. I tried to change the existing ">0" condition to ">0,5", but my changes were not applied. @Spreadsheet Team: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC). Please tell me if it would be useful to try to narrow down version where bug appeared.
Comment on attachment 71012 [details] Conditional formatting settings are lost on file open fix mimetype of attachment
Created attachment 71027 [details] Screenshot comparison Screenshot shows different contents in CF dialog with 3.6.4 and 4.0 My conclusion that effect has nothing to do with "from old version" might have been too rush, I can't reproduce the problem with a simple document newly created with LibO 4.0. But I see document exchange problems related to CF between 3.4 and 3.6.4.3, I still need to do some further research to understand all that.
Obviously one for me.
(In reply to comment #6) > Obviously one for me. And actually not a bug. The behavior changed a bit and as you can see in the Manage conditional formats dialog the conditions are still correct. Begiining with 4.0 we allow overlapping conditional formats. That means that you have a conditional formatting in A1:C4 and define a new one in B1. Then they will be applied in the order of the definition. I have to talk to the UX guys how to make this new behavior more transparent to the user. This step was the last step that I wanted to archive with range based conditional formats. Please always check with Formats->Conditional Formatting->Manage... the conditional formats.
Removing the blocker attribute.
(In reply to comment #7) > (In reply to comment #6) > > Obviously one for me. > > And actually not a bug. The behavior changed a bit and as you can see in the > Manage conditional formats dialog the conditions are still correct. > > Begiining with 4.0 we allow overlapping conditional formats. That means that > you have a conditional formatting in A1:C4 and define a new one in B1. Then > they will be applied in the order of the definition. > > I have to talk to the UX guys how to make this new behavior more transparent > to the user. > > This step was the last step that I wanted to archive with range based > conditional formats. Please always check with Formats->Conditional > Formatting->Manage... the conditional formats. I'm not sure if I understood clear this comment. I'm sure this is a problem. If there is a dialogue on conditional formatting conditions, those settings should appear in right place and in right way. With manage option I can only remove conditional formatting areas, there is nothing to do with settings.
@andis.lazdins@gmail.com Please do not use your e-mail client for comments, please do not cite! @all: A major problem is that there still does not exist any description for the new CF design (at least I do not know any). Concerning severity of the problem I currently am not sure. It sould be possible to exclude CF definition of a cell from the CF range to what the cell belong without chin ups, and UI should contribute useful information, if the operation "change CF definition for single change in range" is impossible, that should be mentioned somewhere and may be dialog should not accept that change. But it's a bad solution that UI pretends to accept a change without any warning. I agree with Markus' decision to remove the "blocker" importance (I should have done that with my comment 5). It's not a general problem making impossible any edit of CF as I thought after my first tests. But nevertheless this one might cause serious problems for many users.
(In reply to comment #10) > @andis.lazdins@gmail.com > Please do not use your e-mail client for comments, please do not cite! > > @all: > A major problem is that there still does not exist any description for the > new CF design (at least I do not know any). A blog post is already in work to explain it. However I still need to get input from the UX team how to deal with the overlapping conditional formats in the dialog. > > Concerning severity of the problem I currently am not sure. It sould be > possible to exclude CF definition of a cell from the CF range to what the > cell belong without chin ups, and UI should contribute useful information, > if the operation "change CF definition for single change in range" is > impossible, that should be mentioned somewhere and may be dialog should not > accept that change. But it's a bad solution that UI pretends to accept a > change without any warning. It accepts the change. Imagine you define a conditional format value is equal 1 in the range A1:C4 and now you also need a conditional format value is equal 2 for A1. Then you can now define the conditional format first for A1:A4 and then select A1 and define a new one. It might not make much sense for formulas like equal to but for some of the new conditional formats that depend on the range of the format it is quite important. Imagine you define top 3 elements(new format in 4.0) that highlights the cells with the 3 highest values and you want to highlight also only one specific cell if it is greater than zero. > > I agree with Markus' decision to remove the "blocker" importance (I should > have done that with my comment 5). It's not a general problem making > impossible any edit of CF as I thought after my first tests. But > nevertheless this one might cause serious problems for many users. It is right now only a UX problem. The conditional formats are all there.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7073310431becb1a69af0c7187b9844ce7901cd5 make editing conditional formats more obvious, related fdo#57895 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=98f1295fe749100f3564c4b4ca66f106d25739c0&g=libreoffice-4-0 make editing conditional formats more obvious, related fdo#57895 It will be available in LibreOffice 4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Please check in beta2 if you can live with this solution.
The problem is gone in Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799) Thank you!