Version: 1.42 (using KDE KDE 3.5.0) Installed from: SuSE RPMs OS: Linux I'm using KOffice 1.42 on KDE 3.5RC1 on SUSE Linux 10.0. How to reproduce the bug: 1. Enter the date 2005-11-26 (ISO) in a new empty spreadsheet in KSpread. 2. Select that cell with a single-left-click. 3. Click and drag down the handle at the bottom-right corner of the cell. Actual Result: 2005-11-26 2006-2006-2006 2007-2007-2007 2008-2008-2008 2009-2009-2009 2010-2010-2010 A similar experiment gave me: 10-05-2005 38,483 38,484 38,485 38,486 38,487 Expected Result: Doing the same with OOo Calc would give me a list of dates like so: 2005-11-26 2005-11-27 2005-11-28 2005-11-29 2005-11-30 2005-12-01 2005-12-02 Comment: The (not-entirely) similar bug 57899 was marked as fixed two years ago in KOffice 1.29.
As far as I remember this actually worked in KSpread 1.3. So it probably reappeared during the 1.4 development. I can confirm the odd behaviour and I agree it should be different. Technical background: Dates are treated as numbers. The internal number is (basically) the days from 1900, so this is treated as a "list" and expanded accordingly. The fact that it is a date and should be handled differently is (as it seems) ignored.
SVN commit 485310 by raphael: BUG: 117252 KSpread::Cell::isDate() did not work correctly. Thus the increment for dates was wrongly determined for autofill. This is now fixed. M +1 -1 kspread_cell.cc --- trunk/koffice/kspread/kspread_cell.cc #485309:485310 @@ -4789,7 +4789,7 @@ { FormatType ft = formatType(); - return (formatIsTime (ft) || ((ft == Generic_format) && + return (formatIsDate (ft) || ((ft == Generic_format) && (value().format() == Value::fmt_Date))); }
SVN commit 485336 by raphael: Time is now incremented by one hour by default (1/24) KSpread::Cell::copyFormat now also copies the value format (!!!) This is necessary to correctly display "dragged down" values that actually use the Generic format instead of a determined format. update CHANGES As far as I can see, autofill now works correctly EXCEPT for bottom-up dragging. CCBUG: 117252 CCBUG: 117619 M +6 -0 CHANGES M +22 -8 kspread_autofill.cc M +5 -0 kspread_cell.cc --- trunk/koffice/kspread/CHANGES #485335:485336 @@ -7,7 +7,13 @@ - Prevent hiding all rows/columns (#483630) - Add a lot of QWhatsThis help to various dialogs - Handbook update for some dialogs +- Implement move sheets +- Fix date increment for autofill (#117252) +Some important developer visible changes: +- Decouple KSpread::Cell and KSpread::Format (association instead of inheritance) +- Provide setter and getter methods for KSpread::Point + since 1.4.1 =========== - Fix slow scrolling left/right (#110551, #101234) --- trunk/koffice/kspread/kspread_autofill.cc #485335:485336 @@ -1,5 +1,6 @@ /* This file is part of the KDE project + Copyright 2005 Raphael Langerhorst <raphael.langerhorst@kdemail.net> Copyright 2002-2004 Ariya Hidayat <ariya@kde.org> Copyright 2002-2003 Norbert Andres <nandres@web.de> Copyright 2002 John Dailey <dailey@vt.edu> @@ -1057,21 +1058,34 @@ { if ( _srcList.at( s )->isFormula() ) { - QString d = _srcList.at( s )->encodeFormula(); - cell->setCellText( cell->decodeFormula( d ) ); + QString d = _srcList.at( s )->encodeFormula(); + cell->setCellText( cell->decodeFormula( d ) ); } else if(_srcList.at( s )->value().isNumber() && _srcList.count()==1) { - double val; - if ( _srcList.at( s )->formatType() == Percentage_format ) - factor = 0.01; + double val; + int format_type = _srcList.at( s )->formatType(); + if ( format_type == Percentage_format ) + { + factor = 0.01; // one percent + } + else if ( _srcList.at( s )->isTime() ) + { + // FIXME this is a workaround to avoid those nasty one minute off + // "dragging down" time is inaccurate overa large lists! + // This is the best approximation I could find (raphael) +// factor = 1.000002/24. + 0.000000001; + factor = 0.041666751; + } + if (!down) val = (_srcList.at( s )->value().asFloat() - (incr * factor)); else val = (_srcList.at( s )->value().asFloat() + (incr * factor)); - QString tmp; - tmp = tmp.setNum(val); - cell->setCellText( tmp ); + + QString tmp; + tmp = tmp.setNum(val); + cell->setCellText( tmp ); ++incr; } else if((AutoFillSequenceItem::month != 0L) --- trunk/koffice/kspread/kspread_cell.cc #485335:485336 @@ -1,5 +1,6 @@ /* This file is part of the KDE project + Copyright 2005 Raphael Langerhorst <raphael.langerhorst@kdemail.net> Copyright 2004-2005 Tomas Mecir <mecirt@gmail.com> Copyright 1999-2002,2004,2005 Laurent Montel <montel@kde.org> Copyright 2002-2005 Ariya Hidayat <ariya@kde.org> @@ -555,6 +556,10 @@ void Cell::copyFormat( int _column, int _row ) { const Cell * cell = format()->sheet()->cellAt( _column, _row ); + + Q_ASSERT(cell); + + d->value.setFormat(cell->d->value.format()); format()->setAlign( cell->format()->align( _column, _row ) ); format()->setAlignY( cell->format()->alignY( _column, _row ) );
Raphael Langerhorst wrote: Technical background: Dates are treated as numbers. The internal number is (basically) the days from 1900, so this is treated as a "list" and expanded accordingly. The fact that it is a date and should be handled differently is (as it seems) ignored. Question: This explains experiment two, where 10-05-2005 was followed by 38,483. But how does this explain my experiment one? That is, 2005-11-26 being followed by 2006-2006-2006 etc? Thanks for fixing the bug. I have added myself to bug 117619's CC too.
The explaination for experiment one is that the entered date is not recognized as date. According to the KSpread handbook ( http://docs.kde.org/stable/en/koffice/kspread/entering.html ) numbers, dates and times are by default right justified. Thus when you enter a value, you can already tell whether KSpread recognized your input. If you enter a date in YYYY-MM-DD but you have a different setting in the Control Center (see handbook link above) then this is acutally interpreted as text (left justified) and not as number (which would be right justified). Thus when you use this text as the basis for your list it is handled differently than with numbers, thus the unexpected result. A possible solution to this is to extend the actual date recognition code, so that entering a date is not limited to the way specified in the Control Center. Please submit a whishlist if you think this is a good idea. Thank you! Raphael
Added comments to already existing (old) bug 50192. It's name is not clearly descriptive of the nature of the wishlist, so I requested a name change to "entering a date should not be limited to the way specified in the Control Center". Please take a look and help out. Thanks.