I use FillAuto into a region sPremiereLigneDonnees = "A7:Q7" My columns A and B are hidden and the macro doesn't copy the formulas in these columns. For the displayed columns, formulas are copied as exepted. This behavior was not present in a previous version. An user told me that this bug is not present with Apache OpenOffice 4.1.1. Tested with Ubuntu 14.04 with LibreOffice Version: 4.2.6.3 Build ID: 420m0(Build:3)
Hi.. Perhaps same problem as Bug 56799 ?
Please provide a sample document with the macro. Change back to unconfirmed after you have provided the document.
Created attachment 109512 [details] Example I've attached a file with the problem. In the sheet "Modèle_résultats", the A & B columns are hidden. The button "Générer les feuilles de résultats" (in Menu sheet) copy the sheet "Modèle_résultats" but without formulas after the line 10 in A and B columns. If I show the A and B columns, all works perfectly. All the formulas are copy in new sheets generated ! But I want that the column A and B stay hidden. Sorry for my english.
Thank you very much for the easy test case. It appears I don't experience the problem. After I click "Générer les feuilles de résultats" and let it run, I select all columns and right click C - Show. Resu6M A7 has: =IF(SUMPRODUCT((INDIRECT($H$1&".$J$7:$J$200")=$I$1) * (INDIRECT($H$1&".$K$7:$K$200")=D7) * (INDIRECT($H$1&".$A$7:$A$200")))=0;"";SUMPRODUCT((INDIRECT($H$1&".$J$7:$J$200")=$I$1) * (INDIRECT($H$1&".$K$7:$K$200")=D7) * (INDIRECT($H$1&".$A$7:$A$200")))) Results were: Feuille « Resu3F » : OK (63 concurrents). Feuille « Resu3M » : OK (66 concurrents). Feuille « Resu4F » : OK (74 concurrents). Feuille « Resu4M » : OK (72 concurrents). Feuille « Resu5F » : OK (67 concurrents). Feuille « Resu5M » : OK (68 concurrents). Feuille « Resu6F » : OK (67 concurrents). Feuille « Resu6M » : OK (72 concurrents). Would it be possible for you to test using LibO 4.3.x? Win 7 64-bit Version: 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08 Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+ Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29 and Version: 4.3.3.2 Build ID: 430m0(Build:2)
Yes, it seems good but it doesn't... My model sheet contains 10 formulas (A7 to A16) like others columns. Check the cell A17. For me, this cell is empty. The C17, D17 are full.
(In reply to migrec from comment #5) > Yes, it seems good but it doesn't... My model sheet contains 10 formulas (A7 > to A16) like others columns. > > Check the cell A17. For me, this cell is empty. The C17, D17 are full. Ok looking at the sheet "Modèle_résultats", A7-16, B7-16, C7-16 have formulas. So are you saying that the Resu sheets should have formulas in A & B all the way down like C is having? Like to Rang 72 in Resu6M?
(In reply to Beluga from comment #6) > Ok looking at the sheet "Modèle_résultats", A7-16, B7-16, C7-16 have > formulas. So are you saying that the Resu sheets should have formulas in A & > B all the way down like C is having? Like to Rang 72 in Resu6M? Yes ! The Resu* sheets should have formulas in A & B columns from line 7 to line 72 for Resu6M.
Ok thanks for the information. I'm setting to NEW because of it.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Created attachment 129944 [details] Example FillAuto
Version: 5.2.4.2 ID build: 3d5603e1122f0f102b62521720ab13a38a4e0eb0 Windows 5.1 Bug still present. When cell are visible, it works fine, else FillAuto (FillSeries) do nothing. It seems to me, it was made for filter, but correct way is exclude filtered, not hidden cells.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Migrec, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This change was introduced with the following commit https://github.com/LibreOffice/core/commit/f61cbce529d039bb0e208e81cf66974cc4428420 in order to prevent overwriting hidden rows or columns.
(In reply to Andreas Heinisch from comment #14) > This change was introduced with the following commit > https://github.com/LibreOffice/core/commit/ > f61cbce529d039bb0e208e81cf66974cc4428420 in order to prevent overwriting > hidden rows or columns. So it's not a bug, but a feature?
Imho it is a feature. Imagine a table with hidden rows where you store some information and you may forget about it. Then you do an autofill either via GUI or macro and overwrite it. After the save you have no chance to recover your overwritten data anymore. You don't even know that you have overwritten something. The same holds for filtered data.
Thanks, let's call it that, then :)
(In reply to Andreas Heinisch from comment #16) > Imho it is a feature. Imagine a table with hidden rows where you store some > information and you may forget about it. Then you do an autofill either via > GUI or macro and overwrite it. After the save you have no chance to recover > your overwritten data anymore. You don't even know that you have overwritten > something. The same holds for filtered data. Then that calls for a warning before or after autofill, to ask you whether you accept overwriting - just like it warns you when you paste data onto cells that already contain data. Or - an option in Tools > Options to customize this behaviour. Instead, you eliminated an important feature to intentionally work with hidden rows/cols. Imagine you have hundreds or thousads of rows - would you find it practical to keep them all unhidden/ungrouped in order to autofill?
(In reply to vic from comment #18) > (In reply to Andreas Heinisch from comment #16) > > Imho it is a feature. Imagine a table with hidden rows where you store some > > information and you may forget about it. Then you do an autofill either via > > GUI or macro and overwrite it. After the save you have no chance to recover > > your overwritten data anymore. You don't even know that you have overwritten > > something. The same holds for filtered data. > > Then that calls for a warning before or after autofill, to ask you whether > you accept overwriting - just like it warns you when you paste data onto > cells that already contain data. > Or - an option in Tools > Options to customize this behaviour. > > Instead, you eliminated an important feature to intentionally work with > hidden rows/cols. > Imagine you have hundreds or thousads of rows - would you find it practical > to keep them all unhidden/ungrouped in order to autofill? Let's loop in UX. So the proposal is to stay with the original request, but with the condition that a warning is implemented at the same time (an option is dangerous because as we have seen countless times, people set options, forget about them and then scream about losing data).
(In reply to Markus Mohrhard from bug 56799 comment 21) > Actually this was a deliberate change and not a regression. Hidden rows and > columns are ignored where ever we touch some code that does not do it yet. > > There are just too many issues that users had with accidentally overwritten > content. (In reply to Andreas Heinisch from comment #14) > This change was introduced ... in order to prevent overwriting > hidden rows or columns. Good arguments to keep the current behavior. The warning sounds reasonable but imagine the infobar pops up every time you interact with hidden cells. Sounds annoying to me - and requires at least an option "[x] Show this warning" to opt-out.
(In reply to Buovjaga from comment #19) > Let's loop in UX. So the proposal is to stay with the original request, but > with the condition that a warning is implemented at the same time (an option > is dangerous because as we have seen countless times, people set options, > forget about them and then scream about losing data). Thank you for considering! We need that option to disable it, just like you have an option to disable the warning when overwriting data at pasting. But I'd be happy to at least have the feature even without ability to disable that warning. 2 questions though: 1) do users complain much that they disabled the just-mentioned warning at pasting and then lost data? 2) how come there is no warning whatsoever when you Paste a column of data over hidden rows? the data actually DOES go into those hidden rows, unlike when you autofill. Do users complain much that they lost their data?...
(In reply to vic from comment #21) > 2) how come there is no warning whatsoever when you Paste a column of data > over hidden rows? the data actually DOES go into those hidden rows, unlike > when you autofill. > Do users complain much that they lost their data?... Correction: the warning at pasting over hidden rows only appears when you have some data about to be overwritten inside those hidden rows. But the point remains that it's strange that this is still allowed, while autofill in hidden rows - NOT. So let's allow the same for autofil, and only pop that same warning when you actually have data inside those hidden rows/cols, and with same ability to disable the warning.
In fact, that option text in Menu > Tools > Options > " Show overwrite warning when pasting data" could be made more general, like "Show warning when overwriting data" and can be used in both scenarios (pasting and autofilling)
*** Bug 137774 has been marked as a duplicate of this bug. ***
(In reply to vic from comment #21) > (In reply to Buovjaga from comment #19) > > Let's loop in UX. So the proposal is to stay with the original request, but > > with the condition that a warning is implemented at the same time (an option > > is dangerous because as we have seen countless times, people set options, > > forget about them and then scream about losing data). > Thank you for considering! > We need that option to disable it, just like you have an option to disable > the warning when overwriting data at pasting. I may have misunderstood a bit Buovjaga's "option"; to clarify: I personally agree with the Warning, and I meant it is good to have an option to disable the warning. So, this (allow autofill on grouped/hidden but with warning at overwriting) would be one solution. For an alternative solution - please see this: bug 167807 (please let me know if simply adding it to "See Also" in this bug's settings already has notified you all: I'm new to this forum).
Bug 137774 comment 4 says (In reply to Justin L from comment #4) > I would consider autofill affecting hidden rows as a bug it if were to > happen. It very intentionally does not work that way. See bug 113785. So let's show this to Justin as well.
(In reply to Buovjaga from comment #26) > Bug 137774 comment 4 says > > (In reply to Justin L from comment #4) > > I would consider autofill affecting hidden rows as a bug it if were to > > happen. It very intentionally does not work that way. See bug 113785. > > So let's show this to Justin as well. I can't envisage anybody working with an array that DOESN'T include formulae - they use a school note book for that. How destructive would it be if a user selected a part of the array that contained the formulae, changed one cell formula and filled down using any method available in a spreadsheet. I can just imagine how far the next Mars transit would get if half the fuel calculations were still in metric and not updated when NASA realised that the USA utilises imperial measurements and only changed the METRIC formulae on SOME of the calculations. Perhaps you could give a use case where you WOULDN'T want all the formulae to be identical for the same task. If somebody hides descriptive text rows because they're in the way then they probably didn't really need the text rows in the first place. If they have produced their work flow around hidden text rows and don't have the mouse to correctly select the area for formulaic change then they should probably stick to a school note book. Perhaps somebody should thoroughly investigate and update OASIS to fit into the new era.