[libreoffice-users] Re: Calc bug?

2013-07-13 Thread Tom
Hi :) I think it's the same with all spreadsheet programs. if the column width is large enough then it starts creating problems. I'm a bit hazy about the problem in this thread tbh but wide columns seem to have all sorts of problems Regards from Tom :) Mark Stanton wrote > I'm not a freq

[libreoffice-users] Re: Calc bug - when sheet is deleted, named ranges are un-defined

2012-11-22 Thread bblackmoor
>> From: bblackmoor >>To: users@global.libreoffice.org >>Sent: Wednesday, 21 November 2012, 16:13 >>Subject: [libreoffice-users] Re: Calc bug - when sheet is deleted, >named ranges are un-defined >> >>The procedure below will also

Re: [libreoffice-users] Re: Calc bug - when sheet is deleted, named ranges are un-defined

2012-11-22 Thread Tom Davies
://wiki.documentfoundation.org/Bug_Report Regards from Tom :)  > > From: bblackmoor >To: users@global.libreoffice.org >Sent: Wednesday, 21 November 2012, 16:13 >Subject: [libreoffice-users] Re: Calc bug - when sheet is deleted, named >ranges are un-defined >

[libreoffice-users] Re: Calc bug - when sheet is deleted, named ranges are un-defined

2012-11-21 Thread bblackmoor
The procedure below will also reproduce the bug. (I did this to see if moving the named ranges to a different tab would make any difference. It did not.) 1) Open Bulletproof_Blues_CSH_b0.11.ods in LibreOffice calc. Note that on sheet "Attributes", in the column "Benchmark", it says "Lift:

[libreoffice-users] Re: Calc bug - when sheet is deleted, named ranges are un-defined

2012-11-21 Thread bblackmoor
On Wed, Nov 21, 2012, at 10:20, Jay Lozier [via Document Foundation Mail Archive] wrote: > > I am not able to reproduce the problem with 3.6.3.2 on Linux Mint 13. > Can you post either the actual before/after files on Nabble or an > example set? I have reproduced this on two different computer

[libreoffice-users] Re: Calc bug - when sheet is deleted, named ranges are un-defined

2012-11-21 Thread bblackmoor
On Wed, Nov 21, 2012, at 10:20, Jay Lozier [via Document Foundation Mail Archive] wrote: > > I am not able to reproduce the problem with 3.6.3.2 on Linux Mint 13. > Can you post either the actual before/after files on Nabble or an > example set? I have reproduced this on two different computer

Re: [libreoffice-users] Re: Calc bug - when sheet is deleted, named ranges are un-defined

2012-11-21 Thread Jay Lozier
On 11/21/2012 01:13 AM, bblackmoor wrote: On Wed, Nov 21, 2012, at 1:08, Jay Lozier [via Document Foundation Mail Archive] wrote: On 11/21/2012 12:43 AM, bblackmoor wrote: I've found a bug in LibreOffice Calc. If I have named ranges in a sheet (let's call it Sheet 7), and I delete a sheet to th

[libreoffice-users] Re: Calc bug - when sheet is deleted, named ranges are un-defined

2012-11-20 Thread bblackmoor
On Wed, Nov 21, 2012, at 1:08, Jay Lozier [via Document Foundation Mail Archive] wrote: > > On 11/21/2012 12:43 AM, bblackmoor wrote: >> I've found a bug in LibreOffice Calc. If I have named ranges in a sheet >> (let's call it Sheet 7), and I delete a sheet to the left of that sheet >> (let's call

[libreoffice-users] Re: [Calc] Bug in Search/replace with regexp

2012-03-21 Thread Ninj
Hi Mario, I'm sure it's not working properly. If i take a simple example: 1. Fill a cell with: 123_456 2. Use the search&replace with: search: ([:digit:]{3}) replace: $1 3. Hit "replace all" What should happen is that the regexp is matched against "123_456", it matches once when it finds "123" s

Re: [libreoffice-users] Re: [Calc] Bug in Search/replace with regexp

2012-03-21 Thread MiguelAngel
El 21/03/12 15:23, Ninj escribió: Indeed, the replacement seems to take place after re-reading the cell content but from the beginning. It starts at the 3rd char, like it should (after "=T3") but from the beginning, not the next position in string (after finding the first match). I'll file a bug

[libreoffice-users] Re: [Calc] Bug in Search/replace with regexp

2012-03-21 Thread Ninj
Indeed, the replacement seems to take place after re-reading the cell content but from the beginning. It starts at the 3rd char, like it should (after "=T3") but from the beginning, not the next position in string (after finding the first match). I'll file a bug indeed, thank you for the links! B