Attached is a project that demonstrates my problem. Please tell me whether I am simply using it the wrong way or whether this is a bug (would be actually a whole bunch of bugs).

The problems I am observing are:

GTK2:
* the grid is eating and ignoring keystrokes when trying to move around the grid with arrow keys and editing cells and/or appending new rows. Navigating the grid and editing Data in any acceptable way seems effectively impossible.

* the grid is sometimes spontaneously losing focus after editing a cell

win32:
* when dgAlwaysShowEditor is in the options then appending new rows does not show the in-place editor in the correct place, it appears one row above, although it is editing the correct row.

Are these problems due to some wrong usage by me (It makes me wonder why nobody else has discovered them yet since they render the TDBGrid on GTK2 almost completely unusable and to me this looks like a real show-stopper, so I suppose I (intuitively) did something fundamentally wrong), or are they real bugs? If they are bugs I will file some bug reports.

Bernd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TDBGrid_not_working.tar.bz2
Type: application/x-bzip
Size: 2323 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100821/5c8aa18e/attachment.bin>

Bernd Kreuss wrote

* the grid is eating and ignoring keystrokes

This seems to be related to the losing of the focus. If i call setfocus everytime the datasource OnDataChange event fires then the problem goes away but I'm not sure whether this is the optimal workaround.

There is a protected property

OnEditingDone

somewhere upwards in the hierarchy of the TDBGrid. Is there a reason this is protected and not available for TDBGrid?

Not that it would help me (didn't find a way yet) with my specific problem but if I make this property published and recompile the LCL then this will perfectly work and fire an event after the editing of a cell is done. I don't see why such an event should not be available for TDBGrid. Intuitively I even would have expected it to exist. Thats why I searched for it.

Bernd

(after patching the LCL to have the OnEditingDone event in the DBGrid)

procedure TForm1.DBGrid1EditingDone(Sender: TObject);
begin
  writeln('editing done ', DBGrid1.Focused);
  //DBGrid1.SetFocus;
end;
procedure TForm1.Datasource1UpdateData(Sender: TObject);
begin
  writeln('data update ', DBGrid1.Focused);
  //DBGrid1.SetFocus;
end;

it shows that whenever I have entered data and press enter or move away from that cell using the arrow keys the DBGrid is in a state where it does not have the focus anymore. But it also *wont* trigger the OnExit event! Using the arrow up/down some more times will eventually give it focus again so I can continue.

Forcing the focus back with SetFocus seems to work but I don't like this workaround. Also in unpatched LCL there is no OnEditingDone for the TDBGrid for some reason and also no other event that would let me track selection changes or anything that is going on while working with the grid in any way [hint! hint! hint!].

data update FALSE
data update FALSE
editing done FALSE
editing done FALSE
data update FALSE
data update FALSE
editing done FALSE

I will file some bugs tomorrow.

--- El s?b 21-ago-10, Bernd Kreuss escribi?:

[snip]

The dbgrid focus problems should be now fixed, please test.

The problem with OnEditingDone is (or at least it was) that it was triggered even if you have not made changes to it (for example simply moving focus to another control), which is misleading because you didn't really edited anything. So Although the name On-Editing-Done is straightforward it may or not mean what you think.

It then reduces to want you want to do in OnEditingDone?

For stringgrid an event, OnValidateEntry, was introduced because of the ambiguity of OnEditingDone. But for dbgrid the underlaying dataset should have validation features (I have not really checked).

OnEditingDone is however available to be published if needed, just it needs to be defined exactly what it should do to avoid misunderstandings.

Jesus Reyes A.

2010/8/24 Jesus Reyes :

The problem with OnEditingDone is (or at least it was) that it was triggered even if you have not made changes to it (for example simply moving focus to another control), which is misleading because you didn't really edited anything. So Although the name On-Editing-Done is straightforward it may or not mean what you think. It then reduces to want you want to do in OnEditingDone?

Thanks for fixing the focus problem so quickly!

The OnEditingDone is not so important. I started searching for this (or a similar)
event while trying to work around the focus problem. I noticed that the grid itself
provides no events to directly react to editing done or even selection change and so
(and after seeing it there implemented already) thought it was only forgotten to make it accessible through the Object Inspector.

But now after thinking about it for a while there are indeed not many possible use cases that could not be addressed by using the datasource instead.

If you mark this bug as "wontfix" I would not protest ;-)

Bernd