Issue 6028 - Autofill defect in 641d, 1.0
Summary: Autofill defect in 641d, 1.0
Status: CLOSED DUPLICATE of issue 5550
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: 641
Hardware: Other Windows 98
: P3 Trivial (vote)
Target Milestone: ---
Assignee: falko.tesch
QA Contact: issues@sc
URL:
Keywords: oooqa
Depends on:
Blocks:
 
Reported: 2002-06-21 12:17 UTC by bernardmoreton
Modified: 2006-01-11 18:02 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description bernardmoreton 2002-06-21 12:17:51 UTC 
If the entry in the cell is 2 numbers separated by a slash, autofill increments 
the first, eg 25/047 becomes 26/047, then 27/047 etc.  

It will be more natural to increment the last component, so that 25/047 should 
become 25/048, then 25/049, etc.
Comment 1 oc 2002-06-26 14:01:00 UTC 
Hi Falko,
one4you
Comment 2 bernardmoreton 2002-11-14 12:47:54 UTC 
The problem is still o/s in 643.
The current rule seems to be, if leading number, increment that, else 
increment trailing number.
There is an oddity in that entries of the type A40-025 are 
DECREMENTED not incremented.

For normal use (considering schedules, catalogues etc), I suggest 
that the rule should be always to INCREMENT the TRAILING number.  

Could exceptions be introduced, perhaps by right-click on the drag 
handle, to enable (a) action on leading number (default no), and (b) 
decrement (default increment) ?
Comment 3 falko.tesch 2003-10-06 12:52:45 UTC 
This issue is covered by #5550

*** This issue has been marked as a duplicate of 5550 ***
Comment 4 lohmaier 2006-01-11 18:02:44 UTC 
closing duplicate.