Bug #63

Peculiar behaviour of RichEdit when text begins with a table

Added by Tomas Rylek over 12 years ago. Updated over 12 years ago.

Status:RejectedStart date:06/27/2011
Priority:NormalDue date:
Assignee:Miroslav Fidler% Done:


Category:-Spent time:-
Target version:-


RichEdit exhibits strange behaviour when the text begins with a table. It is impossible to select the whole text, the table cannot be deleted using clipboard operations (select & delete / cut).

Apparent reasons: 1) in RichEdit, the internal mechanism switching between "in-table" selection and "cross-table" selection fails for an initial table; cursor position 0 (beginning of text) has a non-zero table nesting level and RichEdit::FinishNF automatically switches to "in-table" selection where the selection is naturally limited to a single table.

2) In RichText, RichTxt::Paint switches between "in-table" and "cross-table" selection display by comparing text position range within the table with active selection range; cross-table selection display is activated only when selection begins before start text position for the table. Naturally, when a table starts at position 0, there are no text positions before the table.

Recommended action: 1) I believe the current selection mechanism using linear text positions can be kept intact with only slight extensions of its semantics. Selection manipulation functions should always operate on the "table level" corresponding to the lowest nesting level over all characters within the selection; to make things simple, such a selection should not start or end in the middle of a nested table - within the RichTxt object corresponding to the lowest nesting level within the selection, initial and final selection positions must correspond either to beginnings of individual parts or they must point into a RichPara-part of the RichTxt object. In fact it shouldn't be very difficult to relax even this rule, i.e. to allow selection to contain portions of initial and final tables, but implementation of the selection operations would have to be a little more tricky.

2) With this extension, it should be easy to patch RichTxt::Paint to correctly highlight a cross-table selection starting at first position in the table.

3) RichEdit::FinishNF must be patched to detect cross-table selection (currently the selection is automatically marked as in-table whenever the anchor position corresponds to a table, except the peculiar case when cursor text position corresponds to a deeper table nesting than the anchor, btw. I don't get this) and to adjust selection boundaries in correspondence with the above rule.

4) RichEdit cursor movement functions should be extended to allow switching from the "in-table" to "cross-table" selection when the whole table is selected and the user moves the cursor right or down from the rightmost cell while holding the Shift key (RichEdit::SelCell). The opposite direction should be also allowed (cross-table selection beginning at the start of a table should change to "in-table" when the selection span gets limited to the initial table object).

5) It is questionable whether the situation couldn't be improved by introducing another special pseudo-character which would correspond to the beginning of a table. This would allow to distinguish between the position just before the table and at the beginning of its first cell and could remove some of the current irregularities like inserting a paragraph before the table at text beginning. Also, in-table and cross-table selection would be easy to distinguish (cross-table selection would start before the "table beginning" character whereas in-table selection starting with first cell would start after it) and RichTxt::Paint wouldn't have to be patched at all.


#1 Updated by Miroslav Fidler over 12 years ago

  • Priority changed from Normal to Immediate

#2 Updated by Miroslav Fidler over 12 years ago

  • Status changed from New to Ready for QA
  • Assignee changed from Miroslav Fidler to Tomas Rylek

#3 Updated by Tomas Rylek over 12 years ago

  • Status changed from Ready for QA to Rejected
  • Assignee changed from Tomas Rylek to Miroslav Fidler
  • Priority changed from Immediate to Normal

The RichEdit behaviour has definitely improved but some issues remain.

1) Improvement: it is now possible to start selection at topleft cell of table at the beginning of text (part #0) and to continue beyond the table to select additional text and such selection seems to create a correct clipboard image.

2) Bug: when this clipboard content is pasted back into the text, an additional empty line is inserted before the (originally initial) table. When pasting into Word, no initial empty line is inserted so at least the RTF image of the selection seems to be right.

3) Bug: when selecting text backwards (starting at the end of selection and moving up / left) it is impossible to get into the initial table.

4) Unintuitive behaviour: starting selection at the beginning of an initial table and continuing beyond it seems to suggest that it is possible to switch from in-table selection to text-wide selection by passing the table and continuing downwards (in fact, the other direction is also quite natural). However other tables don't support this - it is impossible to start selection at the beginning of a table (except the initial one) and extend the selection beynond the table, neither with Shift+cursors nor with mouse.

Summary: it is now much easier than before to cope with texts containing initial tables; however the behaviour of table selection is still very irregular and hard to explain to a normal user. I'm not calling for advanced issues like merging tables or marking an imcomplete table together with some surrounding text on one side because I can imagine the amount of work required, but I believe the described issues 2) through 4) are vital if the RichEdit is to be perceived as a "normally functioning formatted text editor" by an ordinary user.

Also available in: Atom PDF