Fixed a bug where the incorrect record number was displayed.  I had missed an important place where the manual code set the rowfilter rather than informing filter/find of the change.
The wrong control got the focus after creating a new record.  This is because the code we use to find the focus control does not cope well with details panels that have panels on them.  It is due to the order in which the generator adds controls to the details panel.  It might be hard to cretae boiler plate code that mimics the behaviour of the generator, so in the case swhere we fail to get it right (like this screen) it is simpler/quicker just to do it manually.
A request was made to set the TabStop property to false for all the 'clear' buttons.  This means that tabbing through the filter/find panel we only tab from editable control to editable control.  The thinkiing is that keyboard users will use CTRL+A and delete rather than TAB and then space.  I think this is debatable but its only a one line change to put it back if we want to.
Added new functionality to allow for the possibility of specifying a different 'find criterion' from the 'filter criterion'  So, for example in filter it is nice to select a range of batch numbers but on Find it makes more sense to find a specific batch number.  So the filter panel gets two instances of BatchNumber with a gte and lte comparison, whereas we clone BatchNumber for Find to be a 'StartsWith' comparison.

This FindComparison now gets all the same ones as Comparison (for filter) but also StartsWith, EndsWith and Contains.  This new functionality has been implemented on several GL and Gift screens.
Two things about this checkin:
1.  Some of these screens get the new FindComparison feature
2.  All screens (except the Journal ones) were found to be slow to display the grid.  This was traced to the time taken to autosize the rows/columns when using a database with a few thousand rows.  The screen would take up to 10 seconds to repaint after maximizing the window (for example) - or when showing/hiding the filter panel.  The fix that I am checking in may not be the permanent solution.  We will need to evaluate the best permanent solution in due course.  For now the autosize behaviour has been over-ridden in manual code so that most of the columns are a specified width with only description columns being autosized.  Further all rows are set to non-autosize (which probably makes a big difference).  We are checking this in now prior to a release because it is a noticable issue now that we have the filter/find panel (but also when loading the screen).
2a.  As a consequence of this it became apparent that the DoubleClick event that we use to switch tabs needs to be the DoubleClickCell event because we do not want to fire it off when we double click the header row in order to resize a column.
2b.  Having fixed that issue so the we can autosize any column based on its data by double clicking the divider between two columns, it is now apparent that the grid still takes the first of the double clicks as a request to sort that column!  I need to see if that can be fixed - but it won't get fixed for this release.  However, double clicking the header to autosize these screens does now work.

Note there are other screens that have a grid that use the DoubleClick event...  I have not investigated those.
Merge from trunk
Uncrustify
merge from Branch 'lp:~alan-paterson/openpetraorg/dev0001853_dec2013_release'.