Just a change to the order of the toolbar buttons so as to be consistent between Gift and GL.  The new import buttons are now to the left of the Export button.
Modified the code that runs for a new batch as well as importing batches.  Up to now we always set the filter to be status=Editing and current year and current and forwarding periods before taking the action.  This was a bit heavy handed and not consistent with the rest of OP where we only change the filter if we cannot find the new record.  So this change makes the change so we are consistent throughout.  The sequence now is:  1. Validate current data and, if ok, save outstanding changes.  2. If that worked perform the task requested and look for the new row. If we find it leave all filter settings as they are.  3. If we did not find it, put up a message box to tell the client we are going to reset the filter.  4. All being well, show the new row with our new filter.
This change is in response to Mantis case 2880.  At the same time I have removed the Apply Now button from Gift nand GL Transactions because we have already removed it from the batches screens.  I don't think we use the Apply Now button anywhere now.  Regarding Bug #2880...  There have been a few changes to the way that the filter code message works so I could not actually replicate what the case described but I did get some other incorrect behaviour (I think).  I have made a small change to the code that adds a new row by removing some unnecessary lines. The result is that this code seems to work fine.
uncrustify
Merge from trunk - no conflicts
This commit was necessary to fix a strange issue with one of the tests.  The problem was intermittent but usually happened on my laptop (though not on Jenkins).  The fix was to prevent the UpdateBatchTotal method from running when the effective date was initialised for a new batch.  Another manifestation was that I could get both the description AND the date boxes highlighted when creating a new batch (nothing to do with a test).  Anyway - it is quite reasonable to suppress change detection in this circumstance because all the data is known to be valid, so I am not bothered at having to do it.
merge from trunk - no conflicts
Get rid of Jenkins warnings about unused variables introduced from trunk.
merge from lp:~alan-paterson/openpetraorg/2014_swiss_testing_3