Subject: Restoring per-cell Enter handling in AdvStringGrid after event-timing change (migrating XE5 → 13.5.6)

VCL TMS VCL UI Pack
1

Environment: TMS VCL UI Pack 13.5.6, Delphi 13 (Florence), Windows 11, Win32.

We are migrating a large application from Delphi XE5 (older TMS VCL UI Pack) to Delphi 13 with TMS VCL UI Pack 13.5.6. We have many data-entry AdvStringGrids where the user types a value and presses Enter to move through the columns. Our application performs per-column logic in code and moves the cursor itself (grid.Col := grid.Col + 1).

In the previous version, on Enter our OnKeyPress handler read grid.Col / grid.Row as the cell that was just edited, ran the per-column logic, and advanced the cursor.

In 13.5.6 we observe (consistent with this thread: AdvStringGrid issue with OnKeyPress event and AdvanceOnEnter ) that on Enter, OnKeyDown moves to the next cell first, then OnKeyPress fires with grid.Col / grid.Row already pointing to the next cell. So our handler now reads the wrong column. In addition, for single-line cells, Enter does not end the edit on the first keypress when AdvanceOnEnter is False (the edit only commits on a second Enter); when AdvanceOnEnter is True, the grid advances one cell and our code advances another, skipping a column.

Questions:

  1. Is there a supported property/option to make a single-line cell commit and end its edit on a single Enter WITHOUT auto-advancing to the next cell? We need commit-only; our application controls the navigation.
  2. With the current event ordering, what is the recommended/supported way to obtain the just-edited cell (ACol/ARow) and run custom per-cell logic on Enter? Should we move our logic to OnEditCellDone or OnCellValidate, and is there a way to restrict that to the Enter key only?
  3. Given that we have many such grids, is there any global setting to restore the previous Enter commit / event-timing behavior?

Minimal repro: a grid with goEditing and one editable single-line column. Type a value, press Enter, and log grid.Col in OnKeyPress — it reports the next cell, not the edited one (matching the referenced thread).

Thank you.

2

  1. We could reproduce this from OnKeyPress. We have not found a reliable solution yet that will not cause other regressions.
    We recommend to use OnKeyDown if you need to detect this meanwhile.

  2. I could not reproduce that OnKeyPress is not triggered when AdvanceOnEnter := false;

Test code was:

procedure TForm1.AdvStringGrid1KeyPress(Sender: TObject; var Key: Char);
begin
  outputdebugstring(pchar(ord(key).ToString+':'+advstringgrid1.Col.ToString+':'+advstringgrid1.Row.ToString));
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  advstringgrid1.Options := advstringgrid1.Options + [goEditing];
  advstringgrid1.Navigation.AdvanceOnEnter := true;
end;
3

We could implement a fix now. Next TMS VCL UI Pack release will have this fix.

4

Thank you, Bruno, and thanks for confirming that the fix will be included in the next release.

I truly appreciate that, but I have to be honest about my situation: this regression in the per-cell Enter handling is blocking active production work and is causing a serious disruption to my current project. I had naturally expected the Enter behavior to keep working as it did before the event-timing change, so this has come as an unexpected and pressing problem during my XE5 → 13.x migration.

As an existing, licensed customer, would it be possible to get a patch or an interim build containing this fix now, rather than waiting for the next official release? Even a quick, unofficial patch would be an enormous help and would let me keep my project on schedule.

The timing is genuinely critical for me right now – I am working against a very tight deadline, and every day counts – so I would be very grateful for any way to receive this fix sooner. Thank you very much for your understanding and support.

5

We aim to have this release this week.