Re: [sc-dev] About Issue 66028's correct behavior.
Hi Niklas, Niklas Nebel schrieb: > On 05/25/09 05:33, maoyg wrote: >>> I suggest the following behavior: >>> For calculating the continuing interval, not-empty hidden cells are >>> treated as if they were not hidden, and empty hidden cell are treated as >>> if they do not exist. >>> The hidden cell are only considered in drag direction. >>> The target area gets the same merge pattern than the source range. >>> Dragfilling overwrites all existing values. >> My idea is all hidden cells are treated as if they do not exist, but I need >> still to ask ux-discuss's and Niklas's advice. > > Non-empty overlapped cells are quite rare, but if they occur, we > shouldn't ignore them. But perhaps we should extend Regina's suggestion > to all empty cells, even if not overlapped (hidden) by merged cells, so > any sequence of 10,empty,20,empty would be continued with 30,empty,40,empty. That is a great idea and will be a good extension. User would still get the current behavior, if he only marks the sequence '20 empty' and he gets the extended behavior, when he marks a longer sequence. And besides the fact, that merging is copied to source area, dragfill for merged and unmerged cells would behave the same, which is more friendly in using. Such changes in dragfill will need a full spec, which mentioned all this cases. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] About Issue 66028's correct behavior.
On 05/25/09 05:33, maoyg wrote: >> I suggest the following behavior: > >> For calculating the continuing interval, not-empty hidden cells are >> treated as if they were not hidden, and empty hidden cell are treated as >> if they do not exist. >> The hidden cell are only considered in drag direction. >> The target area gets the same merge pattern than the source range. >> Dragfilling overwrites all existing values. > > My idea is all hidden cells are treated as if they do not exist, but I need > still to ask ux-discuss's and Niklas's advice. Non-empty overlapped cells are quite rare, but if they occur, we shouldn't ignore them. But perhaps we should extend Regina's suggestion to all empty cells, even if not overlapped (hidden) by merged cells, so any sequence of 10,empty,20,empty would be continued with 30,empty,40,empty. Niklas - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: Re: [sc-dev] About Issue 66028's correct behavior.
Hi Regina,
Thanks for your reply, I think the users can't completely understand it for the
following suggestion.
>The hidden cells can still contain values and can still be used in
>references in OOo. You need to say, what happens with the hidden cells:
>How their value is considered for the continuing interval of the shown
>value, and how the hidden values are continued.
>I suggest the following behavior:
>For calculating the continuing interval, not-empty hidden cells are
>treated as if they were not hidden, and empty hidden cell are treated as
>if they do not exist.
>The hidden cell are only considered in drag direction.
>The target area gets the same merge pattern than the source range.
>Dragfilling overwrites all existing values.
My idea is all hidden cells are treated as if they do not exist, but I need
still to ask ux-discuss's and Niklas's advice.
>{ } indicates merging
>Expample A with varying intervals because of hidden cells
>{ 10
> hidden 6}
>{ 20
> hidden 8}
>is continued to
>{ 11
> hidden 7}
>{ 21
> hidden 9}
the result is
{ 10
hidden 6}
{ 20
hidden 8}
is continued to
{ 30
empty }
{ 40
empty }
>Example B with consistent intervals including hidden cells
>{ 10
> hidden 12}
>{ 14
> hidden 16}
>is continued to
>{ 18
> hidden 20}
>{ 22
> hidden 24}
{ 10
hidden 12}
{ 14
hidden 16}
is continued to
{ 18
empty }
{ 22
empty }
>Example C with empty hidden cells
>{ 10
> empty }
>{ 20
> empty}
>is continued to
>{ 30
> empty}
>{ 40
> empty}
+1
>Example D with merged cells and single cells mixed
>{ 10
> empty}
> 20
>is continued to
>{ 30
> empty}
> 40
+1
>Example E which shows considering in drag direction
>{ 10 empty
> empty hidden 2}
>{ 14 empty
> empty hidden 5}
>is continued to
>{ 18 empty
> empty hidden 8}
>{ 22 empty
> empty hidden 11}
{ 10 empty
empty hidden 2}
{ 14 empty
empty hidden 5}
is continued to
{ 18 empty
empty }
{ 22 empty
empty }
>maoyg schrieb:
>> Hi, all
>> I want to discuss this issue's the specification with your.
>> If you think it is important, I hope you can vote it.
>> As we know, the calc for the merged cell(selection etc) is different from
>> the excel,
>> I have some advice for the spec, I hope you can discuss and help me to
>> finish it. :)
>> I have define a corrent behavior about issue 66028, please review it. thanks.
>> http://www.openoffice.org/issues/show_bug.cgi?id=66028
Best Regards,
maoyg
Re: [sc-dev] About Issue 66028's correct behavior.
Hi Maoyg,
maoyg schrieb:
> Hi, all
> I want to discuss this issue's the specification with your.
> If you think it is important, I hope you can vote it.
> As we know, the calc for the merged cell(selection etc) is different from the
> excel,
> I have some advice for the spec, I hope you can discuss and help me to finish
> it. :)
> I have define a corrent behavior about issue 66028, please review it. thanks.
> http://www.openoffice.org/issues/show_bug.cgi?id=66028
The hidden cells can still contain values and can still be used in
references in OOo. You need to say, what happens with the hidden cells:
How their value is considered for the continuing interval of the shown
value, and how the hidden values are continued.
I suggest the following behavior:
For calculating the continuing interval, not-empty hidden cells are
treated as if they were not hidden, and empty hidden cell are treated as
if they do not exist.
The hidden cell are only considered in drag direction.
The target area gets the same merge pattern than the source range.
Dragfilling overwrites all existing values.
{ } indicates merging
Expample A with varying intervals because of hidden cells
{ 10
hidden 6}
{ 20
hidden 8}
is continued to
{ 11
hidden 7}
{ 21
hidden 9}
Example B with consistent intervals including hidden cells
{ 10
hidden 12}
{ 14
hidden 16}
is continued to
{ 18
hidden 20}
{ 22
hidden 24}
Example C with empty hidden cells
{ 10
empty }
{ 20
empty}
is continued to
{ 30
empty}
{ 40
empty}
Example D with merged cells and single cells mixed
{ 10
empty}
20
is continued to
{ 30
empty}
40
Example E which shows considering in drag direction
{ 10 empty
empty hidden 2}
{ 14 empty
empty hidden 5}
is continued to
{ 18 empty
empty hidden 8}
{ 22 empty
empty hidden 11}
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] About Issue 66028's correct behavior.
Hi, all I want to discuss this issue's the specification with your. If you think it is important, I hope you can vote it. As we know, the calc for the merged cell(selection etc) is different from the excel, I have some advice for the spec, I hope you can discuss and help me to finish it. :) I have define a corrent behavior about issue 66028, please review it. thanks. http://www.openoffice.org/issues/show_bug.cgi?id=66028 Best Regards, maoyg 2009-05-22
