Issue 65041 - Setting table separators leads to arbitrary behaviour
Summary: Setting table separators leads to arbitrary behaviour
Status: CLOSED FIXED
Alias: None
Product: App Dev
Classification: Unclassified
Component: api (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: stefan.baltzer
QA Contact: issues@api
URL:
Keywords:
Depends on:
Blocks: 72764
  Show dependency tree
 
Reported: 2006-05-03 14:01 UTC by steffen.grund
Modified: 2013-02-24 21:09 UTC (History)
5 users (show)

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

Attachments
document with a test case (7.84 KB, application/vnd.oasis.opendocument.text)
2006-05-03 14:05 UTC, steffen.grund 		no flags Details
Patch for fix i65041 (1008 bytes, patch)
2007-06-22 06:52 UTC, zhanghj 		no flags Details | Diff
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 steffen.grund 2006-05-03 14:01:48 UTC 
If the table separators in different rows of a table are set to different
values, the values are changed and the table is not set correctly.

To reproduce, execute the macro in the attached document.
Comment 1 steffen.grund 2006-05-03 14:05:55 UTC 
Created attachment 36235 [details]
document with a test case
Comment 2 thomas.lange 2006-05-12 09:06:17 UTC 
.
Comment 3 thomas.lange 2006-05-17 13:54:21 UTC 
TL->FME: The problem seems to be SwDoc::SetTabCols

There are two problems:
a) when the second row is changed the right border of the last cell should have
remained unchanged that is it still should have been the right border of the table.
b) when the first row is changed to the values it should already have the
distances between the separators double instead of remaining unchanged.
Comment 4 frank.meies 2006-07-04 15:33:58 UTC 
.
Comment 5 frank.meies 2007-05-31 12:06:50 UTC 
fme->zhanghj: Looks like this is more a notification related problem. If you
force the 2nd row to reformat, e.g., by typing 'enter' in one of its cells,
you'll see that the cell widths are set correctly.
Comment 6 frank.meies 2007-05-31 12:48:44 UTC 
fme->zhanghj: Maybe it's just the UnoActionContext that is missing around the
API call? The UnoActionContext object triggeres the reformatting in its
destructor via an EndAction call.
Comment 7 zhanghj 2007-06-22 06:52:34 UTC 
Created attachment 46164 [details]
Patch for fix i65041
Comment 8 frank.meies 2007-06-22 08:32:48 UTC 
FME: Patch integrated in cws swqbf99, unotbl.cxx rev. 1.103.2.1.
Comment 9 frank.meies 2007-06-28 07:50:48 UTC 
.
Comment 10 frank.meies 2007-07-04 11:56:30 UTC 
Ready for QA.
Comment 11 stefan.baltzer 2007-07-09 15:21:40 UTC 
SBA: Verified in CWS swqbf99.
Note: The problem (run the macro and look at the table...) is reproducible with
OOo 2.2.1 / SO8U7, but not in SRC680m217. According to FME the table format
update gets triggered "somwhere else", neverthless the implementation of this
fix was needed.
Comment 12 stefan.baltzer 2007-08-31 15:08:06 UTC 
SBA: OK in OOG680m3. Closed.