Issue 17239

Summary:

Selecting cells in table

Product:

Writer

Reporter:

sq <squan>

Component:

Assignee:

openoffice

Status:

CLOSED OBSOLETE

QA Contact:

Severity:

Trivial

Priority:

CC:

issues, rainerbielefeld_ooo_qa

Version:

OOo 1.1

Target Milestone:

---

Hardware:

OS:

All

Issue Type:

DEFECT

Latest Confirmation in:

---

Developer Difficulty:

---

Issue Depends on:

Issue Blocks:

17245

Attachments:

Description	Flags
SXW with table for demonstration (self explanatory)	none
SXW with table for demonstration (self explanatory)	none
SXW with table for demonstration (self explanating)	none
SXW with table for demonstration (self explanating)	none
SXW with table for demonstration (self explanating)	none
Selection is ok	none

Description sq 2003-07-22 13:58:17 UTC

The attempt to vertically select multiple cells of one column (with either
keybord or mouse) in a table having merged cells is not possible in some cases.
Instead, cells of an adjacing column are selected as well.

If a column heading cell is part of the selection the occurance of the problem
occurs will be more probable.

Comment 1 rblackeagle 2003-07-23 01:03:40 UTC

To me this sounds like it is expected.  If you merge cells overlapping
rows (say B12 and C12), then the "new" merged cell replaces B12.  If
the merger is B12 and B13, the new merged cell would replace B12
(again).  In this case, selecting Column B would select the merged
cell, while selecting Column C should skip it.

In the case of B12 and B13, selecting row 12 would select both B12 and
B13 (as they are now a single cell), while selecting row 13 should
skip it.

This expected behavior occurs in 1.1RC1.

Comment 2 sq 2003-09-22 15:05:57 UTC

Created attachment 9567 [details]
SXW with table for demonstration (self explanatory)

Comment 3 sq 2003-09-22 15:08:13 UTC

Ok, my description was not precise enough.
I send you a table in an example document to illustrate undesired
selection behaviour.
 - Cells E2 and E3 are merged.
 - Start selection in D0 and stop in the merged cell (or anywhere below)
 - You will see that cell F0 of adjacent column on the right will be
selected too.

That's an example of what I meant.

Thank you
  Stefan Q.

Comment 4 sq 2003-10-29 15:14:09 UTC

Created attachment 10753 [details]
SXW with table for demonstration (self explanatory)

Comment 5 sq 2003-10-29 15:14:28 UTC

Created attachment 10754 [details]
SXW with table for demonstration (self explanating)

Comment 6 jack.warchold 2003-11-13 17:12:35 UTC

reassigend to jw

will try to reproduce and find out if this is an expected behaviour

Comment 7 sq 2003-11-14 09:23:34 UTC

Created attachment 11255 [details]
SXW with table for demonstration (self explanating)

Comment 8 sq 2003-11-14 09:30:38 UTC

Created attachment 11256 [details]
SXW with table for demonstration (self explanating)

Comment 9 jack.warchold 2003-11-14 10:37:18 UTC

confirmed on OOo 1.1

just dl the last attached file to see this behaviour

set target to OOo later
set status to new

Comment 10 michael.ruess 2005-10-04 11:41:02 UTC

*** Issue 55379 has been marked as a duplicate of this issue. ***

Comment 11 mathiasm 2010-07-02 21:44:54 UTC

Created attachment 70375 [details]
Selection is ok

Comment 12 mathiasm 2010-07-02 21:51:36 UTC

I can reproduce it with provided sxw, but not with my odt Test_Case_17239.odt

Copying the sxw's array in a .doc or .odt reproduces it. It seems the bug is in 
the cell because the issue persists even if you unmerge the cell.

Comment 13 mroe 2014-04-29 08:40:12 UTC

I think with the redesign of text tables in WRITER this issue becomes OBSOLETE.

Look into the tables of the *.sxw and look at the (sub-)numbering (4.1, .4.2, …) of rows. Such a subnumbering can't be created furthermore, or can?

Comment 14 Rainer Bielefeld 2014-05-06 06:30:38 UTC

Closing this one, indeed problems are solved with new Table design. For new (or remaining) issues please submit new reports.