SourceGrid specification and testing: Difference between revisions
No edit summary |
|||
Line 94: | Line 94: | ||
</pre> | </pre> | ||
== Handling Grid Events in OpenPetra Code == | |||
===Event - FocusRowLeaving=== | ===Event - FocusRowLeaving=== | ||
This is the even that fires most often and needs to be curtailed and checked for repeats. Here's the code from the template with supporting methods etc.: | This is the even that fires most often and needs to be curtailed and checked for repeats. Here's the code from the template with supporting methods etc.: | ||
=== Event - FocusedRowChanged === | |||
Basically, the supporting code needs to identify the user action and behave accordingly, this includes selecting, sorting, adding and deleting rows. The InvokeFocusedRowChanged() method allows the calling of the FocusedRowChanged event code when it needs to be called manually. | Basically, the supporting code needs to identify the user action and behave accordingly, this includes selecting, sorting, adding and deleting rows. The InvokeFocusedRowChanged() method allows the calling of the FocusedRowChanged event code when it needs to be called manually. | ||
== Common Code Tasks == | |||
The above event ensures the correlation between the FCurrentRow variable and the current row, especially during sorting etc., and it also ensures, on a delete, that the record at the same index position (as determined by sort order) or 1 above is always chosen. | |||
=== Selecting a Row === | |||
=== Discovering the Current Row === | |||
=== Adding Rows === | |||
==Adding Rows== | |||
Where the form templates contain code for adding records to the grid, changes have had to be made to control event firing. Here is an example: | Where the form templates contain code for adding records to the grid, changes have had to be made to control event firing. Here is an example: | ||
=== Deleting Rows === | |||
==Deleting Rows== | |||
The code for deleting rows is now in the templates: | The code for deleting rows is now in the templates: | ||
The autogenerated Delete{#DETAILTABLE} procedure can call up to 3 optional manual code methods that control the deletion process (see code below for example with description of arguments etc.): | The autogenerated Delete{#DETAILTABLE} procedure can call up to 3 optional manual code methods that control the deletion process (see code below for example with description of arguments etc.): | ||
Line 523: | Line 198: | ||
The DeleteRowManual()'s second argument, out string ACompletionMessage (which is passed local variable completionMessage), is always sent in empty. If it is populated in the method after a successful delete and there is no PostDeleteManual() method present, then a MessageBox displaying completionMessage string will appear. If you create a PostDeleteManual() method, completionMessage is passed in as an argument. | The DeleteRowManual()'s second argument, out string ACompletionMessage (which is passed local variable completionMessage), is always sent in empty. If it is populated in the method after a successful delete and there is no PostDeleteManual() method present, then a MessageBox displaying completionMessage string will appear. If you create a PostDeleteManual() method, completionMessage is passed in as an argument. | ||
== | === Adding and Deleting Rows Using the Keyboard === | ||
The grid now responds to the INS and DEL key presses on the keyboard and attempts a row insert and delete respectively. To do this, it looks for the existence on the form of buttons called btnNew and btnDelete and executes their click event accordingly. To access this functionality, you obviously need the buttons named correctly, but this doesn't stop you changing the label of the button if New or Delete do not best fit the form's context, e.g. the GL Batch form uses buttons with labels Add and Cancel. | |||
Here is a typical yaml file section for the two buttons: | |||
<pre> | <pre> | ||
// | Actions: | ||
actNew: {Label=&New, ActionClick=NewRecord} | |||
actDelete: {Label=&Delete, ActionClick=DeleteRecord} | |||
Controls: | |||
pnlContent: | |||
Controls: [pnlGrid, pnlDetails] | |||
Dock: Fill | |||
pnlGrid: | |||
Dock: Fill | |||
Controls: [grdDetails, pnlButtons] | |||
pnlButtons: | |||
Dock: Right | |||
Controls: [btnNew, btnDelete] | |||
btnNew: | |||
Action: actNew | |||
btnDelete: | |||
Action: actDelete | |||
</pre> | |||
And then in the manual code, you call the generated code to create/delete a record: | |||
<pre> | |||
private void NewRecord(Object sender, EventArgs e) | |||
{ | { | ||
CreateNewPInternationalPostalType(); | |||
} | |||
private void DeleteRecord(Object sender, EventArgs e) | |||
{ | |||
DeletePInternationalPostalType(); | |||
} | } | ||
</pre> | </pre> | ||
==Grid Testing== | ==Grid Testing== |
Revision as of 15:25, 25 October 2012
OpenPetra makes extensive use of the SourceGrid control available from http://sourcegrid.codeplex.com/. This open source control has many desirable features and is a fairly complex piece of code written by David Icardi. We currently use version 4.40 published on 16 July 2012.
With the exception of the two bugs described below, we are able to use this control 'out-of-the-box'. However, using the control successfully requires some careful programming and some knowledge of how the events that are fired by the control can best be used by OpenPetra.
First we will explain the two bug fixes, then we will examine how to code for the events that we use. In the final section we will describe how to test that any changes that are made to the grid or to validation have not caused new bugs to appear.
Bug Fixes
Unfortunately the grid contains two bugs that we have discovered and corrected.
The first relates to auto-sizing the grid columns and the second relates to the code that makes the horizontal and vertical scrollbars visible.
Auto-Sizing the Grid Columns
When the screen is resized, the grid also resizes and the column widths change to try and show as much useful information as possible. Earlier versions of the grid had a behaviour in this respect that we prefer to the later implementation, so we make a small change to preserve the previous behaviour. If a column has no data, we prefer that the column never shrinks to a size less than the text in the header for that column. So we make the following change to AutoSizeView() inside ColumnInfoCollection.cs.
List<int> list = Grid.Rows.RowsInsideRegion(Grid.DisplayRectangle.Y, Grid.DisplayRectangle.Height, true, false);
becomes
List<int> list = Grid.Rows.RowsInsideRegion(Grid.DisplayRectangle.Y, Grid.DisplayRectangle.Height);
This has the effect of including the header row in the list of visible rows, whose text widths need consideration.
Automatic positioning of the Two ScrollBars
Particularly when a horizontal scrollbar is already present on the grid, the standard code does not make a good job of displaying the vertical scrollbar correctly. It is also possible for the horizontal scrollbar not to be displayed when it should be.
In order to correct this we have the following code for the RecalcCustomScrollBars() method in CustomScrollControl.cs.
/// <summary> /// Recalculate the scrollbars position and size. /// Use this to refresh scroll bars /// </summary> public void RecalcCustomScrollBars() { SuspendLayout(); ///////////////////////////////////////////////////////////////////// //ALAN if (GetScrollColumns(base.DisplayRectangle.Width) > 0) { // we definitely need a HScroll based on the base display rectangle PrepareScrollBars(true, false); if (GetScrollRows(DisplayRectangle.Height) > 0) { // we need a VScroll too PrepareScrollBars(true, true); } } else { // we don't need an HScroll (yet) if (GetScrollRows(base.DisplayRectangle.Height) > 0) { // we definitely need a VScroll based on the base display rectangle PrepareScrollBars(false, true); if (GetScrollColumns(DisplayRectangle.Width) > 0) { // actually now we need an HScroll after all, because the VScroll has taken up space PrepareScrollBars(true, true); } } else { // No scrolls needed - everything fits in the base display rectangle PrepareScrollBars(false, false); } } //Finally I read the actual values to use (that can be changed because I have called PrepareScrollBars) if (VScrollBarVisible) { int scrollRows = GetScrollRows(DisplayRectangle.Height); scrollRows = scrollRows - GetActualFixedRows(); RecalcVScrollBar(scrollRows); } if (HScrollBarVisible) { int scrollCols = GetScrollColumns(DisplayRectangle.Width); RecalcHScrollBar(scrollCols); } //forzo un ridisegno InvalidateScrollableArea(); ResumeLayout(true); }
Handling Grid Events in OpenPetra Code
Event - FocusRowLeaving
This is the even that fires most often and needs to be curtailed and checked for repeats. Here's the code from the template with supporting methods etc.:
Event - FocusedRowChanged
Basically, the supporting code needs to identify the user action and behave accordingly, this includes selecting, sorting, adding and deleting rows. The InvokeFocusedRowChanged() method allows the calling of the FocusedRowChanged event code when it needs to be called manually.
Common Code Tasks
The above event ensures the correlation between the FCurrentRow variable and the current row, especially during sorting etc., and it also ensures, on a delete, that the record at the same index position (as determined by sort order) or 1 above is always chosen.
Selecting a Row
Discovering the Current Row
Adding Rows
Where the form templates contain code for adding records to the grid, changes have had to be made to control event firing. Here is an example:
Deleting Rows
The code for deleting rows is now in the templates:
The autogenerated Delete{#DETAILTABLE} procedure can call up to 3 optional manual code methods that control the deletion process (see code below for example with description of arguments etc.):
/// <summary> /// Performs checks to determine whether a deletion of the current /// row is permissable /// </summary> /// <param name="ARowToDelete">the currently selected row to be deleted</param> /// <param name="ADeletionQuestion">can be changed to a context-sensitive deletion confirmation question</param> /// <returns>true if user is permitted and able to delete the current row</returns> private bool PreDeleteManual(ref PInternationalPostalTypeRow ARowToDelete, ref string ADeletionQuestion) { /*Code to execute before the delete can take place*/ ADeletionQuestion = String.Format(Catalog.GetString("Are you sure you want to delete Postal Type Code: '{0}'?"), ARowToDelete.InternatPostalTypeCode); return true; } /// <summary> /// Deletes the current row and optionally populates a completion message /// </summary> /// <param name="ARowToDelete">the currently selected row to delete</param> /// <param name="ACompletionMessage">if specified, is the deletion completion message</param> /// <returns>true if row deletion is successful</returns> private bool DeleteRowManual(ref PInternationalPostalTypeRow ARowToDelete, out string ACompletionMessage) { bool deletionSuccessful = false; try { //Must set the message parameters before the delete is performed if requiring any of the row values ACompletionMessage = String.Format(Catalog.GetString("Postal Type Code: '{0}' deleted successfully."), ARowToDelete.InternatPostalTypeCode); ARowToDelete.Delete(); deletionSuccessful = true; } catch (Exception ex) { ACompletionMessage = ex.Message; MessageBox.Show(ex.Message, "Deletion Error", MessageBoxButtons.OK, MessageBoxIcon.Error); } return deletionSuccessful; } /// <summary> /// Code to be run after the deletion process /// </summary> /// <param name="ARowToDelete">the row that was/was to be deleted</param> /// <param name="AAllowDeletion">whether or not the user was permitted to delete</param> /// <param name="ADeletionPerformed">whether or not the deletion was performed successfully</param> /// <param name="ACompletionMessage">if specified, is the deletion completion message</param> private void PostDeleteManual(ref PInternationalPostalTypeRow ARowToDelete, bool AAllowDeletion, bool ADeletionPerformed, string ACompletionMessage) { /*Code to execute after the delete has occurred*/ if (ADeletionPerformed && ACompletionMessage.Length > 0) { MessageBox.Show(ACompletionMessage, "Deletion Completed", MessageBoxButtons.OK, MessageBoxIcon.Information); if (!pnlDetails.Enabled) //set by FocusedRowChanged if grdDetails.Rows.Count < 2 { ClearControls(); } } else if (!AAllowDeletion) { //message to user } else if (!ADeletionPerformed) { //message to user } }
The DeleteRowManual()'s second argument, out string ACompletionMessage (which is passed local variable completionMessage), is always sent in empty. If it is populated in the method after a successful delete and there is no PostDeleteManual() method present, then a MessageBox displaying completionMessage string will appear. If you create a PostDeleteManual() method, completionMessage is passed in as an argument.
Adding and Deleting Rows Using the Keyboard
The grid now responds to the INS and DEL key presses on the keyboard and attempts a row insert and delete respectively. To do this, it looks for the existence on the form of buttons called btnNew and btnDelete and executes their click event accordingly. To access this functionality, you obviously need the buttons named correctly, but this doesn't stop you changing the label of the button if New or Delete do not best fit the form's context, e.g. the GL Batch form uses buttons with labels Add and Cancel.
Here is a typical yaml file section for the two buttons:
Actions: actNew: {Label=&New, ActionClick=NewRecord} actDelete: {Label=&Delete, ActionClick=DeleteRecord} Controls: pnlContent: Controls: [pnlGrid, pnlDetails] Dock: Fill pnlGrid: Dock: Fill Controls: [grdDetails, pnlButtons] pnlButtons: Dock: Right Controls: [btnNew, btnDelete] btnNew: Action: actNew btnDelete: Action: actDelete
And then in the manual code, you call the generated code to create/delete a record:
private void NewRecord(Object sender, EventArgs e) { CreateNewPInternationalPostalType(); } private void DeleteRecord(Object sender, EventArgs e) { DeletePInternationalPostalType(); }
Grid Testing
Testing needs to be setup where we can test the grid on all its basic functions in forms derived from each of the templates.
Currently, all code generated from the templates compiles and a number of basic maintain screens have been tested for correct behaviour, but a smaller stand-alone application will also be needed to test the behaviour in isolation.