LibreOffice 3.5:build-403 Version ID : 350m1(Build:403) OpenSuse 11.4 64Bit When selecting a column and searching for replacement the first item is found but replace is not appied and column is deselected. very annoying
On pc Debian x86-64, with 3.5.4 Debian package (testing repo), I don't reproduce this problem. On a column contained 2 times the value I want to replace: a) If I use "Replace" on the whole column it unselects the column it replaces only the first cell with the value it highlight the cell where there has been the replace b) If I use "Replace All" on the whole column it unselects the column it replaces all the cells with the value it highlight all the cells where there has been the replace Could you give try a newer LO version (last one is 3.5.5) and tell us if you reproduce this problem?
Sorry this not exactly what is happening. I use to select a column , then search in this column for a string , it is a conditional search and I only need replace at some places not replace all . So I first do a search for the string , if the condition apply then i do the replacement and search for the next occurence, so not all occurences of the string should be replaced as in your test. repeat your steps but do first a search to find the first occurence , then try to replace it and searching for the next. This is where the bug is . Cheers
Ok I understand better. Now I don't know if it's a bug or an enhancement (which would be useful!). Dev/QA guys: any idea about this?
It is definitely a bug or at least a big change in function . I have been using LibreOffice for years and used to apply search and replaces te way i am describing above.
Just after applying an opensuse update of LibreOffice this bug appeared. I have a lot of work to finish so please corret things . cheers
Hello is this bug going to be fixed ? I have a lot of work waiting and thousands of search/replaces on a selected column. Cheers
Rainer: What do you think, should it be treated by Kohei, Markus or Eike?
Tested with LO4.000b1, Windows Can confirm this bug: exactly as described by M.S. the column is deselected after first "Search" and further search in the whole document finds no case of search string.
Hi any activity on this bug tracking ? Thanks
Have set 'regression'. Please don't change the LO version - it should be left at the one where the problem was first noticed - have changed it back.
hi What does it mean regression , I hav not changed anything just typed my message ! sorry if I did it unintentionnally.
@Metehyi Regression means that something that used to work no longer does. It's used to identify bugs that have been caused by changes in a newer version.
(In reply to comment #11) > hi > > What does it mean regression , > I hav not changed anything just typed my message ! > > sorry if I did it unintentionnally. I don't think Mike answered to your last comment but to Paulchen. 1) About version You declared this bug with 3.5 but the "version" field was set to "Unspecified" instead of "3.5.0" Then Paulchen tested the bug on LO4.000b1 and confirmed it on this version and set the field to 4.0.0.0.beta1. (Perhaps he had just noticed "unspecified" but not your description indicated 3.5.0, I don't know) Then I suppose Mike noticed your description, set "version field" to 3.5.0 and reminded Paulchen to let first version where this bug appeared (see https://wiki.documentfoundation.org/BugReport_Details#Version) 2) About regression Mike has already answer but again, you can take a look here: https://wiki.documentfoundation.org/BugReport_Details#Version So the only slight "mistake" you made is perhaps not having specified "version" field at the beginning. But don't worry, nobody bites here (at least, never heard about this :-))
This has nothing to do with column selection, it's a general problem for find & replace in selected ranges. That never worked in a different way, I can't find any hint that the current way how it works might not be as intended, so this one is an enhancement request. Without this one fixed it will be impossible to fix "Bug 42410 - Replace & Find Next button" also for "only selection"
(In reply to comment #14) > This has nothing to do with column selection, it's a general problem for > find & replace in selected ranges. > > That never worked in a different way, I can't find any hint that the current > way how it works might not be as intended, so this one is an enhancement > request. > > Without this one fixed it will be impossible to fix "Bug 42410 - Replace & > Find Next button" also for "only selection" Hi Rainer , It is definitely a bug or at least a regression. I have been using Open/LibreOffice for years and used to apply conditional searches and replaces on a selected column the way i am describing it above. I have done it 100 thousands times, I am 100% sure.
Hi Here is a snapshot of my libreoffice installation http://simplest-image-hosting.net/jpeg-0-libreoffversion. I had a fresh opensuse 12.2 install a few monthes ago , then I worked daily as I was doing since many years with this find and replace then find next on a selected column in calc. I am 100% sure , then sometime an update for libreoffice was offered on opensuse repo and I did the Update , immediatly after that was this problem to see . What more infos do you need ? Cheers,
(In reply to comment #13) > But don't worry, nobody bites here (at least, never heard about this :-)) I know that nobody bites here , but I am not sure that I am at the right place to submit a bug report here... I know libreoffice is for free and no warranty etc.... I am looking for an other Office suite so as to continue my daily work because I have the feeling I am not taken seriously here since I have submitted my Bug report on 2012-08-03 and after 6 monthes there is no activity here and nobody is caring. Cheers,
Created attachment 74182 [details] Sample Document Steps how to reproduce 'Find & Replace in selected column' how it should work, and how it works with Server Installation of "LibreOffice 3.4.5 English UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit): 1. Open attached sample document "sample.ods" 2. Click on Row Header "A" > First Column "A" becomes selected 3. Menu 'Edit -> Find & Replace' > Dialog opens 4. <More Options>, check 'Selection only' if necessary 5. Type "a" into Find Pane and "XXX" into 'Replace by' 6. <Find> As expected: Finds "a" in A4, column keeps selected 7. <Find> As expected: Finds "a" in A7, ignores "a" in B5, column keeps selected 8. <Replace> As expected: replaces "a" in A7 by "XXX" column keeps selected 9. <Find> As expected: Finds "a" in A10, column keeps selected and so on 10. Close without saving for a different test. 21. Open attached sample document "sample.ods" 22. Click on Row Header "A" > First Column "A" becomes selected 23. Menu 'Edit -> Find & Replace' > Dialog opens 24. <More Options>, check 'Selection only' if necessary, all other unchecked! 25. Type "a" into Find Pane and "XXX" into 'Replace by' 26. <Find All> As expected: Finds "a" in several cells in column A, all hits will be selected, cell cursor around A4 27. <Find> As expected: Finds "a" in A7, ignores "a" in B5, column keeps selected 28. <Replace> As expected: replaces "a" in A7 by "XXX" column keeps selected 29. <Find><Find><Find> As expected: Finds "a" in A14, column keeps selected And so on Now the same test steps with "LibO 4.0.0.3 rc - GERMAN UI / German Locale [Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)]" {tinderbox: @6, pull time 2013-01-31 11:30(?)} on German WIN7 Home Premium (64bit) with User Profile updated from 4.0.0.2 Step 6 Bug ---------- Column A becomes unselected, no more rind steps possible, enxt >Find> will find nothing because no selection Step 27 Bug ----------- Hits become unselected, no more <Find> possible I will check where that started @Metehyi VELLE: Your comment let me think that we were talking about different things, may be I misinterpreted. Your comments were too imprecise, so the danger is big that we (QA) try to find a bug we expect to see and not the bug you saw.I hope my example shows how such a report allows absolutely no interpretation.
(In reply to comment #18) > Created attachment 74182 [details] > Sample Document > > Steps how to reproduce 'Find & Replace in selected column' how it should > work, and how it works with Server Installation of "LibreOffice 3.4.5 > English UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on > German WIN7 Home Premium (64bit): > 1. Open attached sample document "sample.ods" Ok > 2. Click on Row Header "A" > > First Column "A" becomes selected OK > 3. Menu 'Edit -> Find & Replace' > > Dialog opens > 4. <More Options>, check 'Selection only' if necessary OK > 5. Type "a" into Find Pane and "XXX" into 'Replace by' OK > 6. <Find> > As expected: Finds "a" in A4, column keeps selected No from here my column A is unselected clicking find again tells me LOff has reached end of document without finding anything. Do I want to start from beginning on ? I click yes and a pop up window tells me search string not found. > 7. <Find> > As expected: Finds "a" in A7, ignores "a" in B5, column keeps selected > 8. <Replace> > As expected: replaces "a" in A7 by "XXX" column keeps selected > 9. <Find> > As expected: Finds "a" in A10, column keeps selected > > and so on > > 10. Close without saving for a different test. > > 21. Open attached sample document "sample.ods" > 22. Click on Row Header "A" > > First Column "A" becomes selected > 23. Menu 'Edit -> Find & Replace' > > Dialog opens > 24. <More Options>, check 'Selection only' if necessary, all other unchecked! > 25. Type "a" into Find Pane and "XXX" into 'Replace by' > 26. <Find All> > As expected: Finds "a" in several cells in column A, all hits will be > selected, cell cursor around A4 > 27. <Find> > As expected: Finds "a" in A7, ignores "a" in B5, column keeps selected > 28. <Replace> > As expected: replaces "a" in A7 by "XXX" column keeps selected > 29. <Find><Find><Find> > As expected: Finds "a" in A14, column keeps selected > > And so on > I have a German UI, > Now the same test steps with "LibO 4.0.0.3 rc - GERMAN UI / German > Locale [Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)]" {tinderbox: > @6, pull time 2013-01-31 11:30(?)} on German WIN7 Home Premium (64bit) with > User Profile updated from 4.0.0.2 > > Step 6 Bug > ---------- > Column A becomes unselected, no more rind steps possible, enxt >Find> will > find nothing because no selection exactly this is what I am telling you . I only want to find replace in a column selection , I want to find next item and decide wether or not to replace it then search for next in the same selection in the same column. > > Step 27 Bug > ----------- > Hits become unselected, no more <Find> possible > > I will check where that started I think now you got it now . > > @Metehyi VELLE: > Your comment let me think that we were talking about different things, may > be I misinterpreted. > > Your comments were too imprecise, so the danger is big that we (QA) try to > find a bug we expect to see and not the bug you saw.I hope my example shows > how such a report allows absolutely no interpretation.
Both Bugs from comment above already [Reproducible] with * server installation of "LibreOffice 3.5.7.2 rc German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit) * Server Installation of "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) So it seems problem started with 3.5 Same with Simple Find, selection lost after first hit. Strange that nobody reported that before ... And yes, it's a regression. @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)
(In reply to comment #20) > Strange that nobody reported that before ... Normal , I know many people in my surrounding who tells me about bugs in LO , usually people switch to another vendor because the don't have time to report a bug...or simply they don't want...or whatever.... Ok I myself am an intensive user of LO in many languages add me to your pre-release testers if you want. Cheers > > And yes, it's a regression. > > @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)
(In reply to comment #19) <https://wiki.documentfoundation.org/QA-FAQ#How_to_cite_other_comments>, please stop this useless citing! A single line "@rainer: Yes, that's the bug I reported" would have been enough.
Some additional actions for Comment 20 necessary because of Mid air collision.
(In reply to comment #18) > Step 6 Bug > ---------- > Column A becomes unselected, no more rind steps possible, enxt >Find> will > find nothing because no selection > > Step 27 Bug > ----------- > Hits become unselected, no more <Find> possible I did a bibisect and bumped upon this commit of Kohei http://cgit.freedesktop.org/libreoffice/core/commit/?id=0783e78de2ce265e19b739effbff80c37ee98576 As far I understand the commit message, the reported behavior is done by purpose? @Kohei: am I right? Kind regards, Joren
(In reply to comment #24) > (In reply to comment #18) > > Step 6 Bug > > ---------- > > Column A becomes unselected, no more rind steps possible, enxt >Find> will > > find nothing because no selection > > > > Step 27 Bug > > ----------- > > Hits become unselected, no more <Find> possible > > I did a bibisect and bumped upon this commit of Kohei > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=0783e78de2ce265e19b739effbff80c37ee98576 > > As far I understand the commit message, the reported behavior is done by > purpose? > > @Kohei: am I right? Nope. This is a bug. When doing an individual search or replace, the selection should be retained. When doing search all or replace all, OTOH, the selection resets to the matching cells only.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d28bb70875e9191ff20b6b5751695f583b73a4f0&h=libreoffice-4-1 only reset marked area when using find/replace all, fdo#53106 It will be available in LibreOffice 4.1. 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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=62d85cfc679f90cd2c65d1ea5493026324875f46 only reset marked area when using find/replace all, fdo#53106 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.
Pending review for 4-0.
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=728d6cea85e68a563822b6017707a98085a7058c&h=libreoffice-4-0 only reset marked area when using find/replace all, fdo#53106 It will be available in LibreOffice 4.0.5. 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.
Migrating Whiteboard tags to Keywords: (bibisectrequest) [NinjaEdit]