AD
Administrator
Syncfusion Team
February 4, 2005 10:00 AM
Jason,
In your form call
this.groupingGrid1.TableControl.WantEnterKey = false;
and then override
protected override bool ProcessDialogKey(Keys keyData)
{
if (keyData == Keys.Enter)
{
GridCurrentCell cc = this.groupingGrid1.TableControl.CurrentCell;
cc = cc.Renderer.GetNestedCurrentCell();
cc.ConfirmChanges();
cc.Lock();
((GridTableControl) cc.Grid).Table.CurrentRecordManager.EndEdit();
cc.Unlock();
}
return base.ProcessDialogKey (keyData);
}
Stefan
JH
Jason Hales
February 7, 2005 06:04 AM
Hi Stefan, thanks for that. It now works exactly as I need; :-)
JH
Jason Hales
February 8, 2005 07:23 AM
...well it kind of works, except that in my RecordValueChanging event handler I actually alter the entered value a little (some internal rounding rules) - setting e.NewValue(RecordValueChangingEventArgs)
The trouble is my NewValue is not being shown - the entered value is still being shown and highlighted
TIA
Jason
AD
Administrator
Syncfusion Team
February 8, 2005 11:42 AM
Try calling cc.Refresh() after cc.Unlock().
The Lock / Unlock blocks any changes to the active current cell.
Stefan
JH
Jason Hales
February 9, 2005 05:00 AM
I''ll just requoute myself "It now works exactly as I need; :-)".
Excellent support. Thanks for that
Jason
>Try calling cc.Refresh() after cc.Unlock().
>
>The Lock / Unlock blocks any changes to the active current cell.
>
>Stefan
>
JH
Jason Hales
February 9, 2005 09:17 AM
Oops, I forgot to return true for ENTER key and was getting a Beep due to the TextBox being single line. All working now though
AD
Administrator
Syncfusion Team
February 11, 2005 12:45 PM
I tried this, and realized there is a small glitch... I type a value into a cell, and press enter. The value updates and is selected. However, when I click on a column header to resort, the value that I just entered appears in the same position on the screen, but in the wrong cell... it is in the cell that has resorted to that position. Navigating out of the cell removes the stray value, but this certainly looks strange.
the cell that should have gotten the value does, that is unaffected. seems like this is some sort of a refresh issue.
Any ideas?
Thanks,
Brian
AD
Administrator
Syncfusion Team
February 11, 2005 03:50 PM
If you use Lock / Unlock this will block any changes to the active current cell - even sorting. That''s why you have to manually navigate out of the cell in such case.
Stefan
>I tried this, and realized there is a small glitch... I type a value into a cell, and press enter. The value updates and is selected. However, when I click on a column header to resort, the value that I just entered appears in the same position on the screen, but in the wrong cell... it is in the cell that has resorted to that position. Navigating out of the cell removes the stray value, but this certainly looks strange.
>
>the cell that should have gotten the value does, that is unaffected. seems like this is some sort of a refresh issue.
>
>Any ideas?
>Thanks,
>Brian
JH
Jason Hales
February 15, 2005 09:21 AM
Brian and I are working on the same thing but it doesn''t seem to be related to the ProcessDialogKey changes detailed here (as I commented out the code and it''s still the same)
I''ll just repeat the behaviour we are seeing - although this doesn''t happen to the standard grouping grid - we are very heavily cusotmisng the gird and imagine it''s an option we''ve set somewere
1. Select a cell, say Row/Col 2,3.
2 Enter a value into a cell. Press enter. The current cell is still higlighted -at 2/3
2. Click on a header cell
3. The grid re-sorts, yet the cell (2/3) is shown with the value just entered, and has focus The the cell in the new row postion is also highlighted
Any ideas?
>
>If you use Lock / Unlock this will block any changes to the active current cell - even sorting. That''s why you have to manually navigate out of the cell in such case.
>
>Stefan
>
>
>>I tried this, and realized there is a small glitch... I type a value into a cell, and press enter. The value updates and is selected. However, when I click on a column header to resort, the value that I just entered appears in the same position on the screen, but in the wrong cell... it is in the cell that has resorted to that position. Navigating out of the cell removes the stray value, but this certainly looks strange.
>>
>>the cell that should have gotten the value does, that is unaffected. seems like this is some sort of a refresh issue.
>>
>>Any ideas?
>>Thanks,
>>Brian
AD
Administrator
Syncfusion Team
February 15, 2005 11:48 AM
When the user clicks on a header a cell a QueryAllowSortColumn event is raised. In that event you could try and deactivate the current cell (or end edit mode) with
groupingGrid.TableControl.CurrentCell.Deactivate()
Stefan
>Brian and I are working on the same thing but it doesn''t seem to be related to the ProcessDialogKey changes detailed here (as I commented out the code and it''s still the same)
>
>I''ll just repeat the behaviour we are seeing - although this doesn''t happen to the standard grouping grid - we are very heavily cusotmisng the gird and imagine it''s an option we''ve set somewere
>
>1. Select a cell, say Row/Col 2,3.
>
>2 Enter a value into a cell. Press enter. The current cell is still higlighted -at 2/3
>
>2. Click on a header cell
>
>3. The grid re-sorts, yet the cell (2/3) is shown with the value just entered, and has focus The the cell in the new row postion is also highlighted
>
>Any ideas?
>>
>>If you use Lock / Unlock this will block any changes to the active current cell - even sorting. That''s why you have to manually navigate out of the cell in such case.
>>
>>Stefan
>>
>>
>>>I tried this, and realized there is a small glitch... I type a value into a cell, and press enter. The value updates and is selected. However, when I click on a column header to resort, the value that I just entered appears in the same position on the screen, but in the wrong cell... it is in the cell that has resorted to that position. Navigating out of the cell removes the stray value, but this certainly looks strange.
>>>
>>>the cell that should have gotten the value does, that is unaffected. seems like this is some sort of a refresh issue.
>>>
>>>Any ideas?
>>>Thanks,
>>>Brian
JH
Jason Hales
February 16, 2005 05:29 AM
Thanks Stefan. That''s fixed it but the user now has to click on the new cell to make it current - I think that''ll be OK for the time being though
Jason