Fixed a bug when loading Recurring GL Transactions and then selecting rows.  The issue is like the non-recurring screen where there is a call to UpdateTransactionTotals().  I have added code to suppress change detection when recalculating the totals and we now save the changes behind the scenes if there were no changes before the update.  While working on this bug I noticed that there was an issue again with the Batches tab where the Save button would get enabled whenever the batch hash total display changed.  That is now also fixed.  So I have tried a lot of fidlding with recurring GL both batches tab and transactions tab and I don't seem to get the save button or the 'Do you want to save?' dialog at all if I don't actually change anything.
This is the checkin of the place I noticed where there is still code that resets the filter (importing from clipboard).  I can commit this now and complete the Mantis case.
This is an initial check-in for the work on daily exchange rates and doing all the work on the server.  I have created a ExchangeRateTDS typed data set which is what the screen now uses to access all the data it needs.  This data set contains three tables: the corporate rate and two daily rate tables.  The first is the one that is displayed but it has extended columns that include how many times the rate is used by Gift or GL.  The second contains details about the places where a rate is used.  As a result there is much less traffic between the server and the client and all the information is loaded into the screen at the start.  The screen will become much simpler to code.  An interesting thing is that the server sends ADailyExchangerate table to the client that contains not only the rates that are in the table but also contains all the rates that are NOT in the table but are used in Gift and GL.  So it means that, even if the Dail Rate table is completely empty, the screen will still contain all the places where foreign currency daily rates have been used!!

This check-in contains all the server code and the fancy SQL queries.  It contains enough of the manual code file changes to get the screen to display and show the usage counts and details.  

As this is the first WindowMaintainTable template screen to use a TDS I discovered that the template was wrong in a number of places (where #DETAILTABLE had been used instead of #DETAILTABLTYPE), so this fixes those issues too.
Merge from trunk.  No conflicts.
Fixes two compiler warnings about XML comments and varaibale names.
A small change to all the templates so that the declaration of the FFilterFindObject (and hence the Filter panel user control) moves from the screen template to the designer file.  This way all the controls are declared in the designer file where Windows can dispose of them using the designer file Dispose code.  This makes the 'Preview' nant task succeed!
Added code to provide standard status bar text for the two Filter/Find tabs on the Filter/Find panel and also for any instance of a splitter bar on a screen.
In order to get the tests to work for Daily Exchange Rate I had to revert the server DataReader code to what it was originally.  This now calls LoadAll on the DailyExchangeRate table.  To compensate for that I have modified the WindowMaintainTable template so that if there is a DataSet defined it does not do an initail load and Merge, but expects the manual code to do this using an appropriate call.  This is fair enough since this is the only screen that has a dataSet defined in a WindowmaintainTable.

I then had to make a few changes to the test suite.  The main thing I have done in that regard though is to disable the tests that deal with exchange rate usage because the screen works a bit differently.  I will need to do more work on that as well as create some new tests to run on the server side.  However I want to check the code in and start a new branch for that.
This check-in extends the work done previously on Daily Exchange rate typed data sets.  It contains the code that glues together the three GUI screens (Daily Exchange rate, Gift Batch and GL Batch.  So the code now works that if you select a used ro in the DEX screen you can load the Gift or GL screen at that item.  And if you save a row in one of those screens AND it is a Forex row, the DEX screen will re-load its data.  Very neat!!
Merge from trunk - no conflicts
This should get rid of 4 Jenkins warnings
This commit fixes the issues with the test suite, so all the tests can run again.  None have the Ignore attribute set now.  I possibly need to have a look at an issue where the current code displays gift batches and GL Batches at different times on the same date when the rates match.  It would be nicer if they were together.  But I will do that in the next branch.
Just a change to the text that applies to the Import buttons so that it is clear if we are working with batches or transactions.
Just a change to the text that applies to the Import buttons so that it is clear if we are working with batches or transactions.
There are two changes.  The simple one is that the Account code and cost centre code are now always converted to upper case when importing.  The second concerns the message that gets displayed when there is an exception generated by saving data.  Since data is saved per batch or set of transactions there is no sense in referring to a line number.  So if the catch block catches one of these errors the message is different from when the catch block catches a row based exception.  The former refers to the batch description in the message so that is the lowest level of granularity you can get, but you do get told whether the issue relates to saving transactions,, journals or batches within the batch.
Uncrustify
merge from lp:~alan-paterson/openpetraorg/2014_11_20_bugs