#15162 closed defect (fixed)

wxGrid multiline problems with wxTE_RICH2 style

Reported by: Tiron Owned by:
Priority: normal Milestone:
Component: wxGrid Version: stable-latest
Keywords: Cc: Tiron
Blocked By: Blocking:
Patch: no

Description

Revision 64646 added wxTE_RICH2 to the grid text editor, this breaks editing multiline text under Windows. If a grid cell contains multiline text and you use a grid cell editor having the wxTE_RICH2 style, it truncates the text to a single line, losing everything else. Before this style, the newlines would show up within the single line of text as "block" characters (but it would not destroy the multiline string).

In my application, a single click in the selected cell will bring up the default inline editor and on a double click we bring up a special dialog intended to edit multiline text. The problem is that many times the double click is interpreted as one click to select the cell and a second click to inline edit the text. Before this wxTE_RICH2 change, the inline editor would handle it, but show boxes for the newline characters. With the wxTE_RICH2 style, it truncates the text at the first newline, destroying any multiline text that was there. More than that, you cannot seem to hit ESC to cancel it. So in the case of a misclick on a multiline cell, the wxTE_RICH2 style causes actual data loss.

I think being able to edit multiline text in the single line editor is nice to have, but the critical fix is to not destroy the multiline data.

Change History (2)

comment:1 Changed 19 months ago by Tiron

  • Cc Tiron added

comment:2 Changed 18 months ago by VZ

  • Resolution set to fixed
  • Status changed from new to closed

(In [73876]) Really fix the problem with caret in wxGrid text editor under MSW.

The problem (see #11681) was due to not allowing the native control handle the
focus loss event. This, in turn, was due to the changes of r58969 which tried
to work around a crash which happened if the grid was destroyed from the code
of one of the user-defined event handlers called during the editor dismissal.

Fix both problems at once by calling event.Skip() in OnKillFocus() to let the
native handler have the event too and postponing the editor dismissal a little
by calling DisableCellEditControl() indirectly from a posted event handler
instead of immediately.

As this reverts the now unnecessary changes of r64646, it closes #15162.

Note: See TracTickets for help on using tickets.