DataViewGrid Event Handling

ctopenpetra

I have downloaded the source code and example code for the DevAge SourceGrid.

I have tested the Row Enter and the Row Leave events and they work perfectly as expected, so there appears to be no error within the grid itself, which would imply the problem is with our wrapper in OpenPetra.

pokorra

that is good news!

Probably with all our positioning etc, we change the focus too often.

Please create a simple application, that just uses our wrapper TSgrdDataGrid of the SourceGrid.DataGrid.
Similar to bazaar.launchpad.net/_openpetrac ... llapsible/

I have already some NUnit tests for our controls:
bazaar.launchpad.net/_openpetrac ... /Controls/
but I guess it will require some work to do your event tests.

alanjfpaterson

I have done a fix in the sgrdDataGrid.cs code for the problem I encountered with sorting. The sgrdDataGrid has code in the Sorted (sorting completed) event that then makes sure that the row that was selected before sorting is re-selected after sorting. This causes a cascade of RowChanged events which then cause us to make transfers of data to and fro between the panel and the grid - resulting in the grid getting wrong data in some rows.

I have not yet checked this code in to trunk.

I created a new Grid property "Sorting" that is True while the code to reset the highlighted row is running. Then I use the property in our standard auto-generated code in GegtDetailsFromControls() and ShowDetails(), so they only do anything when the grid is not "Sorting". This seems ok to me because the whole basis of the sgrdDataGrid sorting code is that all rows get sorted and the selection does not change.

So if anyone in this thread is looking at changing the grid wrapper, please bear in mind that I will be checking in these changes to the wrapper from my branch (0000747).

Thanks

Alan

Here is a summary of my code changes:

In sgrdDataGrid.cs

        /// <summary>
        /// Returns true when the grid is re-ordering rows after a sort operation.  Can be used to ignore updates from a panel to the grid
        /// because the sort operation never changes the selected row.
        /// </summary>
        public Boolean Sorting
        {
            get
            {
                return FSorting;
            }
        }

In auto-generated form code:

    private void GetDetailsFromControls(ADailyExchangeRateRow ARow)
    {
        if (ARow != null && !grdDetails.Sorting)
        {
            ARow.BeginEdit();
      ........ and so on as before


private void FocusedRowChanged(System.Object sender, SourceGrid.RowEventArgs e)
{
    if(e.Row != FCurrentRow && !grdDetails.Sorting)
    {
        // Transfer data from Controls into the DataTable
        if (FPreviouslySelectedDetailRow != null)
        {
            GetDetailsFromControls(FPreviouslySelectedDetailRow);
        }

ctopenpetra

One aspect of the grid that we need to be aware of: if you tab away from the grid to another control you get a FocusRowLeaving event, and when you tab from a control onto the grid you get a FocusRowEntered event. This happens on the grid in a test environment as well as OpenPetra and is incorrect. The row has not been left or entered but the Grid control has lost and gained focus but nothing has changed in terms of the active row.

This also means that code is going to be executed multiple times if the user simply tabs around an OpenPetra form.

alanjfpaterson

Chris - what you say is true, but that is the event that drives the update of your changes in the edit panel into the grid, so on a typical keyboard driven data entry you would do this.... Tab to the New button and hit the spacebar to activate New; then tab once to the first control in the edit panel and type the value you want.... keep tabbing and typing until you reach the grid again, then on the next tab the details go into the grid and you are back at the New button, ready to press space again for the next new row. So that is the one single event that you need in that sequence to drive the whole process!!

But you are right - if you just keep tabbing round on the same row. you will get these updates every cycle.

I am interested to know what is driving your interest in this - is it that you need to keep the number of events down to a minimum because the grids have so much data in them in a real-life scenario that it is important for us not to 'waste' time - and you notice significant lags in screen updates??? Or is it that you notice bugs because events are sometimes being called in the wrong circumstance and therefore resulting in corrupt data?? By the way, my interest recently has been the latter - badly sequenced events leading to corruption; but I am guessing your interest might be speed???

openpetract

By way of conclusion:

I have discovered that the SourceGrid does not have expected event handling for a grid, especially when it comes to handling focus. In addition to this fact, our code wrapper calls grid methods that reinvoke the focus events causing duplication.

What I have done, is added code to our wrapper to manage focus events properly. One other change I have made is to control the situation where the grid loses focus and causes a rowleave and rowchange event. To do this, I have resorted to disabling two lines of code in the SourceGrid.dll

The DataGridView is based upon the GridVirtual. In line 1849 of GridVirtual.cs I have made the following changes:

protected override void OnValidated(EventArgs e)
{
base.OnValidated(e);

//NOTE: I use OnValidated and not OnLostFocus because is not called when the focus is on another child control (for example an editor control) or OnLeave because before Validating event and so the validation can still be stopped

if ((Selection.FocusStyle & FocusStyle.RemoveFocusCellOnLeave) == FocusStyle.RemoveFocusCellOnLeave)
{
	//Changed by CT - 2012-07-03
	//Selection.Focus(Position.Empty, false);
}

if ((Selection.FocusStyle & FocusStyle.RemoveSelectionOnLeave) == FocusStyle.RemoveSelectionOnLeave)
{
	//Changed by CT - 2012-07-03
	//Selection.ResetSelection(true);
}

}

This basically means that when someone tabs or clicks away from the grid, no events are fired for the grid.

Ideally, it would be better to simply add code to our wrapper:

e.g. this.Selection.FocusStyle = FocusStyle.None;

and later switch back on with:
this.Selection.FocusStyle = FocusStyle.Default;

but it may be difficult to intercept the OnValidated event unless we use the grid.LostFocus event.

Comments, please?

openpetract

alanjfpaterson wrote
Chris - what you say is true, but that is the event that drives the update of your changes in the edit panel into the grid, so on a typical keyboard driven data entry you would do this.... Tab to the New button and hit the spacebar to activate New; then tab once to the first control in the edit panel and type the value you want.... keep tabbing and typing until you reach the grid again, then on the next tab the details go into the grid and you are back at the New button, ready to press space again for the next new row. So that is the one single event that you need in that sequence to drive the whole process!!

But you are right - if you just keep tabbing round on the same row. you will get these updates every cycle.

I am interested to know what is driving your interest in this - is it that you need to keep the number of events down to a minimum because the grids have so much data in them in a real-life scenario that it is important for us not to 'waste' time - and you notice significant lags in screen updates??? Or is it that you notice bugs because events are sometimes being called in the wrong circumstance and therefore resulting in corrupt data?? By the way, my interest recently has been the latter - badly sequenced events leading to corruption; but I am guessing your interest might be speed???

Hi Alan, only just noticed this.

The reason for this whole exercise was repeated events and incorrect events, especially the two that call code to redisplay the record or validate the current record. The whole exercise has been to make the events predictable and uniform