This is the change log taken from the program's source code, it will be replaced as the help files are updated:

  110 REM DRAFT VERSION CHANGE LOG ...
  120 :
  130 REM added functions '+-*/%tr' to input tool
  140 REM changed -day13 switch to -home
  150 REM added -home result reporting facilities
  160 REM added 'Days' (365.25) to PPA selector
  170 REM added 'convert levels to extras' function - nice!
  180 REM TCC/£100 only reported for APR
  190 REM modfied series checking, force RDATE% input for periods with date
  200 REM added 'log first' tool and related mods to output and options
  210 REM docked dialogue to a window (uses WINLIB2B for main dialogue)
  220 REM removed cachedial and Dial$
  230 REM saved calculation includes program version
  240 REM -home result displayed in rebates panel as a sum
  250 REM rationalised results display procedures (only write on display)
  260 REM include single mode:
  270 REM - dialogue mods
  280 REM - PRR, APR and Act calcs
  290 REM - output mods
  300 REM re-instated -quit parameter for tools (gone since v101? oops!)
  310 REM stopped PROCclrAddins stripping parameters from toolset file (again, oops)
  320 REM introduced Own$ for program description
  330 REM removed parameter from PROCxwind (now only does '6')
  340 REM corrected PROCcutParam for zero length after ':'
  350 REM mods to meet new Reg.11 spec:
  360 REM - PROCcheckReg11 complete (actually not)
  370 REM - Reg11 option introduced
  380 REM - PROCcheckReg11 complete now
  390 REM - mods to FNperiod() for Reg.11(3)-(4)
  400 REM - mods to FNperiod and FNcheckRebate for no ESRs, RESRs months
  410 REM - mods to cope with counting 'backward'
  420 REM - added tools to switch off new periods functions
  430 REM - further mods to PROCcheckReg11 (combined levels and extras)
  440 REM resolved file installation/location issues
  450 REM implemented calculation export to clipboard
  460 REM implemented -local switch, forces data to program folder

Bugs ...

The most significant change to the program was not strictly a bug (because the program was doing what it was designed to do) but is being recorded here because it corrected a 'bug' in our interpretation of how the regulations should be applied.

The OFT has in the past taken the view that the periods in a statutory calculation should be done in either weeks, months or years and days, and that only one of those three periods should be used in any one calculation - ie if the calculation was being done in years and days all the periods in the calculation should be done in years and days.

DualCalc reflected this view and, essentially left the user to decide what periods to use, if the user selected a calculation using periods of years and days, all the periods between two dates (ie the relevant or settlement date and a repayment or advance date) were converted to years and days.

However, we received an enquiry from another developer who questioned this approach.  This caused us to reconsider our interpretation and we now accept that, under Regulation 11 of the Total Charge for Credit Regulations, each period in a calculation should be examined individually to see whether it can be expressed in weeks, months or Years and days.

DualCalc has now been adapted to work this way and this will result in different answers for some calculations, generallly those using dates.

Unfortunately, the revised interpretation also raised a number of other issues connected with the calculation of periods:

• how to determine whether a period between two dates is a whole number of calendar months - we take the view that this applies where the two days in the month are the same (ie the 12th to the 12th) ofr where both dates are the end of a month

• how to determine whether a period is a whole number of weeks - obviously multiples of 7 days are weeks, but Regulation 11 refers to repayments which 'are to be' paid weekly from the start of the loan (the relevant date).  In OFT's view that means it is necessary to look at the original contractual repayments.  For actuarial calculations, where periods are measured from the settlement date, this creates a problem.  Under the regulations an actuarial calculation can be done using the rpeayments the borrower has actually made during the loan, so the original payments are not available to be examined by the program.

  Consuquently, the program provides an additional 'All-weeks' periods in a year option, adjacent to the Years&days option, which, for actuarial calculations, allows the user to indicate that periods are expressed in years and days (ie dates) and

Improvements ...

Bugs ...

The drop-down (or combo) input for the deferment to be applied to rebate calculations had a couple of last minute bugs introduced into v1.02a while adding an, as yet un-released, facility:

• a typo in the name of the flag variable which identifies certain deferment values as statutory meant that 2 Month deferment was not correctly recognised as such and threw up a 'non-statutory deferment being used' type warning.  If the user continued with the calculation the value was treated and reported as two periods rather than 2 months.  This has been corrected

• correcting that revealed a further typo in the routine to set the deferment combo's value which meant that when 2 Months was selected it was reset to 1 Month next time the dialoge was updated.  This has also been corrected

Unfortunately we were not informed the oft.gov.uk version of the credit-programs address was no longer available and some enquiries to the address in 'Reporting Problems' in these help files were lost.  The revised address is now given and is:

credit-programs@oft.gsi.gov.uk

Improvements ...

The interval calculator has been renamed the interval 'converter' and modified:

• the previous version was a little annoying because the precision button also had to be used to carry out the calculation and this sometimes meant you had to cycle around all the settings to get the result you wanted.  An additional 'Convert' button has now been added

• the precision options have been increased to allow for 1 to 5 decimal places

• intervals can now also be (approximately) 'back-converted' to dates

• the tool allows access to internal day codes (not particularly useful).

[Click here for more information]

Bugs ...

• In v1.02 the calculator reset function, which is run before loading a new calculation, was 'improved' by ensuring that it also cleared the internal APR and period effective rate (PER) values held by the program  This appears to have been one of the changes introduced to remove duplication in the routines to display a calculation's results (I may have been concerned that old results would get written back into the dialogue if they weren't cleared) but it may simply have been done for consistency, because I noticed these results were not reset when all the others were.

  Unfortunately, this has been found to be incompatible with the way the load function reads APR and PER values for actuarial rebate calculations - they were simply read straight into the program's main dialogue, rather than to the internal values, and were subsequently being overwritten by the cleared values.  This is, no doubt, why they were not reset in earlier versions.

  The effect was that loading and running an actuarial calculation resulted in an unexpected 'this is a zero rate loan' message because the rate to be used had been cleared.  You could only get a result by entering an APR or PER value before running the calculation.

  Rather than revert to the previous approach, this has been corrected by altering the load function so that it sets the internal APR and PER values to those in the file before writing them into the dialogue.

• I noticed that the HTML coding for APR iteration logs contained a minor error which has been corrected.

Improvements ...

The opportunity was also taken to re-compile the program using an updated BBC BASIC for Windows (BB4W) library for the production of dialogues (WINLIB2 v1.2), and to improve the 'landmarking' in the IDE context menu of points in the program's listing using a revision introduced with BB4W v5.30a (this change is only of interest to me).

A significant number of improvements, enhancements and the removal of some bugs:

The Bugs ...

• The routines to perform simple rebate calculations were receiving the time of the deferred settlement as an integer (a whole number).  For agreements with annual repayments, ie those where 'Periods in a year' is set to 'Years&days' (or '1'), the deferred settlement date can have a fractional value, for example 2.083333 (two and one twelfth years), and the fractional part was lost.  Consequently, in these cases the program's results did not take account of any deferment.  This has been corrected.



NOTE:  as, in a limited number of (albeit unusual) cases, this error produced incorrect statutory results, the version number has been increased and you are advised to upgrade.  It should be noted that, as the error produced results with larger rebates, and lower settlement figures, than would otherwise be the case, they were not, technically, in breach of the regulations.  On the other hand, neither was a trader who took the deferment into account in their calculations.



• Date entries in the extras and advances panels could be displayed incorrectly, appearing as day codes (generally six digit numbers) rather than dates in dd/mm/yyyy format.  This was the result of a basic programming error:  The offset to the start of the currently displayed 10 rows had been omitted when reading the array of flags which indicates whether the value is a time or date.  This resulted in an intermittent fault because the display routine always read the flags for the first 10 rows regardless of which 10 rows were being displayed.  If the program was being used in a correct 'statutory' calculation (ie all the times had been entered as times or dates) the problem was not apparent, because all the flags were set to dates anyway.  But with mixed time and date entries which used more than the first 10 rows the problem arose ... unless the corresponding flag in the first 10 rows happened to be the same as that in the displayed row.  This issue has been present since version 1.00 and has now been corrected.
• Inputs which accepted dates would not correctly read non-date inputs (ie periods) above a certain degree of precision.  They would be labelled 'INVALID=>' unless they were preceded by an '=' sign.  Even then, they would only be read as the less precise value displayed.  This was because an omission from the code was causing these values to be converted using the default string-to-number precision (&90A), rather than the value set in the program (&C0C), and has been corrected.
• The 'open program folders' utility inadvertently opened the help files rather than the folder containing them, this has been corrected.
• The routines for validating dates had poor error handling which allowed them to overwrite some variables in other routines in certain circumstances, This had been corrected, however, it was only apparent when one of the enhancements mentioned below was added.
. 

The Enhancements ...

• quite a few changes have been made to the main dialogue.  The first three inputs (loan, initial and final sum), the levels and extras panels and the rate results group have all been moved down so that the panels are now all in line.  This created two spaces, the one at the top being filled with a logo or 'badge' image [click here for more information] and the smaller gap at the bottom with four additional buttons which provide easier access to the tools mentioned below;
• an 'Input calculator' tool has been added.  In its current form this just gives the user a little more space to carry out intermediate calculations in BASIC notation and allows them to view intermediate results before they are entered into the main dialogue by keying '=' (rather like the similar facility in the earlier DOS programs) [click here for more information];
• a 'Calendar picker' tool has also been added.  This provides the user with a standard Windows gadget to select dates from a drop-down calendar for entry into the main dialogue, rather than having to type them.  This has also been linked to the Series and Interval calculator dialogues so the user can pick dates for entries in these via small 'date:' buttons [click here for more information];
• the 'Interval calculator' tool has been re-named and promoted to a button, it's also been re-designed with a 'tumbling' button (like the existing toggling buttons, but rotating around three settings rather than switching between two) to indicate whether an exact, rounded or truncated result for the length of an interval is required [click here for more information];
• a 'Period rate convertor' tool (previously a separate program provided as an add-in) has also been added.  This converts annual effective rates to period rates and vice versa [click here for more information];
• a facility has been added to allow all the above tools to insert their results directly into the main dialogue (rather than the user having to cut and paste) by selecting the required entry item before running the tool.  This is indicated by the 'OK =>' buttons in the tools.  The selection facility also determines whether the selected input is appropriate for the tool (eg whether the entry will accept dates, periods, or rates, and warns the user, or restricts the use of the tool, appropriately [click here for more information];
• the 'Payment Series' tool has been modified slightly so that it works in a similar manner to the other tools above.  The 'Add Advances' and 'Add Extras' buttons have been replaced with a toggling [ Extras ] / [ Advances ] button to choose which panel the series should be added to, and an 'OK =>' button to carry out the action [click here for more information];
• an 'Import raw data into rows' tool has been added.  This may help you to transfer information such as long lists of repayments and/or dates held in other software into the calculator.  It can also transfer data held on the clipboard [click here for more information];
• an 'Input or delete panel colums' tool, similar to the import tool, has evolved from the former delete rows tool.  This may help you to enter multiple payments or times in one go, or amend or delete incorrect blocks of information [click here for more information];
• the load, input and import functions bypass the data validation of panels which takes place when data is entered manually.  If properly formatted data is loaded (eg that previously saved by DualCalc) this shouldn't be an issue, but data constructed elsewhere [as described in detail here] or imported or automatically input data (as described above) may contain, eg, a negative level or an invalid date or time, which would be stored directly into the program's data arrays without checking.  To help the user detect this, DualCalc now runs a 'scan' of the information in its data arrays after a load or import.  Basically, this involves loading the panel displays with each occupied block of rows from the arrays and then reading them back into the arrays (at which point they are validated).  If any invalid values are detected, the user is warned and required to correct them [click here for more information];
• DualCalc now warns you if there's already another copy running when you start it, you can however choose to continue - in fact it keeps a count of the other copies running and warns you accordingly [click here for more information];
• the 'Early settlement examples' tool has gained two improvements:

  • rather annoyingly, this produced the same warnings about all three example calculations.  This has now been limited so that warnings are only issued in relation to the first settlement calculation and warning are switched off for the remaining two;
  • there was also a potential problem with the tool and levels.  If the user entered a complex actuarial calculation which used levels, they would be taken into account in the APR calculation and then (since complex actuarial rebates do not use levels) ignored in the rebate calculation.  The user is now told that levels can't be used in this situation; [click here for more information]

• an oversight in the rebate method drop-down/combo meant that the user could - pointlessly - type a value into it.  This has been corrected with an unexpected improvement to the switching of the panels, they now change as the options are scrolled through rather than waiting for a selection to be made;

• the values '365 days' and '365.25 days' have been removed from the PPA drop down (combo) input as they do not relate to statutory (or arguably statutory) values.  You can however still enter '365', '365.25' (or other values, eg '366') into the PPA input [click here for more information];
• where the PPA value is set to 'Years&days' DualCalc rate calculations previously produced period and nominal annual rates which were the same value as the effective annual rate.  While those results were accurate, they added nothing to the information provided.  From v1.02, the program provides an 'Effective daily rate'.  I understand that this result can be useful in cross-checking other systems and/or calculations and it avoids pointless repetition of the same value [click here for more information];
• the program now also provides a simple facility for removing add-ins from the toolset when they are no longer required, without the need to edit the toolset.txt file.  Essentially all the user needs to do is delete the add-in's executable or script and DualCalc will detect this next time it starts, warn the user the program is gone, and modify the file itself [click here for more information];
and
• the prompt function now provides a title bar appropriate to the circumstances in which it's being used.  It has also been modified to accommodate the 'Input calculator tool' which is built using a prompt;
• finally, the program is now compiled with Windows XP Visual Styles enabled.  This means that, if you use visual styles on your setup, the program will too, instead of retaining the 'Classic' windows look.  Your main dialogue would therefore look something like this:
  

  the exact appearance will depend upon the colour scheme or theme you have chosen.  Unfortunately, on some systems, some of the buttons can appear a little clipped at the bottom because of their reduced size, but they should all remain readable.

The Improvements...

'Technical' changes which should be transparent to the user:

• the sequence of actions taken on startup has been re-ordered slightly;
• the space for dialogue routines had been allocated more efficiently;
• a new BASIC syntax to read null-terminated strings has been used;
• a more Windows-friendly way of determining whether a folder exists has been incorporated.  Previously the program attempted to create the folder and captured the error generated if it already existed - actually this change is more useful to me than the user, as the program editor would switch away from the code I was testing to the line containing the 'error';
• the truncation of an APR requires the calculation of the integer part of a floating-point number.  Earlier versions of BBC BASIC could only do this for a limited (albeit large - numbers more than 2.7 billion) range of values and DualCalc avoided trying to truncate the APR where it was beyond that range.  Often this made little difference, with the right result generally displayed anyway, and hopefully there are few APRs in the billions, but internally the program used the untruncated value.  This aspect of BBC BASIC was improved some time ago and DualCalc has belatedly been modified to take account of that by no longer avoiding the integer calculation for larger results;
• some major re-ordering of the code has taken place and the HTML/Printer/Spool output routines and the panel tidying routines have been broken into sections - in this is just to make the program easier to maintain; and
• as part of the changes to provide an 'effective daily rate' result, some duplication in the routines to display calculation results has been removed;
• some improvements have been made to the routines to handle the PPA, DIY etc drop down items;
• the program has been re-compiled with the current version (5.30a) of BBC BASIC for Windows.

The Add-ins ...

Two JavaScript add-ins are now provided pre-installed with the program:

• A slightly enhanced version (1.6) of the 'Credit Card Repayment Calculator' previously distributed with the program.  This version avoids possibly confusion over the displayed values by clearing the calculation results whenever the user attempts to edit their input and also includes some copyright etc information.
• A 'Credit Card APR Model Calculator' which is intended for use as a benchmark by credit card operators etc, by carrying out the credit card APR calculations required by Schedule 7 of the Consumer Credit (Agreements) Regulations 1983 (as amended) and the relevant assumptions in Schedule 1 of the Consumer Credit (Advertisements) Regulations 2004, in accordance with the Office's interpretation.  This is a minor update (v0.7) since the first made available (the only changes are to the name of a variable 'int' in the program code which caused a problem in one browser's JavaScript interpreter and a clarification to the text about entering the time of payment of an annual fee).

  You can run these from here for more information:

  Card Charges Calculator
  Card APR Calculator
  

Mainly this release repackages DualCalc with the Inno Setup installer, but the opportunity was also taken to include a few changes which had already been finalised:

A few minor corrections to some of the program's code were made, mainly these are transparent to the user (a line of legacy code which did nothing was deleted, the re-ordering of a few lines for clarity).

A few minor bugs were also corrected:

• the command to set the printer margins had, at some point, been moved to before that to select the printer font.  However, a side-effect of the font command is that it resets the margins to zero, so the user's margin selection was being ignored.  These commands have now been swapped and the program uses the entered margin settings.
• the facility to switch the APR iteration to the Bisection Method (by pressing the Alt key during the calculation) could be used even after Newton's method had successfully found a result.  The effect was that the result from Newton's method was set to zero and the program then tried to calculate the APR etc causing a 'division by zero' error.  The use of the Alt key after a result has been found is now blocked.
• a typo which prevented the printing or logging of calculations which used non-statutory periods in a year has been corrected.  The omission of a variable name from a line of code caused a 'not a function' error.  This has apparently been lurking undetected since version 1.00

Iteration Log

Information about the iterations in an APR calculation appears briefly at the bottom of the dialogue as it progresses.  The only way to read this more clearly if you need to (eg to check your own program) was to slow down the iteration delay setting in Options, which was sufficient for my purposes when debugging the program.

However, this information may also be useful to some users may want to use the program to compare results with their own solutions, so v1.01b2 accepts a command line switch '-itlog' which tells it to keep a record of the progress information from the bottom line.  This can be read in a raw format from the file itlog.txt in the Resources folder inside DualCalc's folder and, if the 'Analyse' option is set in Options, it will also be added to the bottom of the calculation's log or print output.

Details of what the information in itlog.txt and the 'iteration log' in an analysis mean [are avalable by clicking here].

A minor but important update, again the results produced by the program are not changed:

• unfortunately, version 1.01a was issued with a debugging facility still partly 'switched on'.  This meant that some errors were not correctly reported and instead went to a window not available to the user.  This could cause the program to 'hang';

• previous versions did not deal adequately with the situation where the user provided no valid time for the repayment of the 'Final sum' under the agreement - for example, if they used the Final sum to describe the repayment in a single instalment agreement but didn't use a level length or number of regular repayments to establish when the final sum was paid.  An invalid last time (zero or less) is now detected and an error message generated;

• There was a glitch in the way the program's APR calculations switched from Newton's method to the Bisection method.  The program would only switch if 50 iterations of Newton's method had failed to find a result or if the user held down the Alt key.  A third condition, where Newton's method produces a negative intermediate value, simply caused the program to give up and report that an APR could not be calculated (in some cases, before the user even had a chance to hit Alt).  This has now been corrected and a negative intermediate value also triggers a switch to the Bisection method.

Some improvements have also been made to the coding:

• some instances were found where program code was duplicated rather than existing routines being used, these have been removed;

• the routines which read text input from various files have been made more tolerant of encountering an unexpected end to the file;

• the routines to detect .add files and modify toolset.txt have been improved;

• version 1.01b has been re-compiled with the recently issued version 5 of BBC Basic for Windows.

Several changes, some quite significant, but none of them change the results produced by the program:

• the user is now warned about payment times/dates which fall before the relevant date - an omission from the original checks and warnings;

• the program has been modified slightly to enable running across a network (see here);

• the program will now look for .add files in the Tools folder when it starts up and automatically add add-ins to the Toolset.txt file (see here);

• the series tool now provides an additional 'Days' option for interval units.  This removes an oversight in the original which meant that all the repayment dates for weekly loans had to be entered into actuarial calculations manually (see here);

• the 'Add 28 days' (to the settlement date) tool has been made more accessible by moving it to a [+] button next to the settlement date entry (see here);

• the 'Delete rows' tool has been made more user-friendly and there have been some other changes to the lists of internal 'Tools' (see here);

• the Loan/Price, Simple/Complex and APR/Rebate buttons now all cause the data in the dialogue to be checked when they are toggled.  I was uncertain why they used different approaches (this was probably a left-over from earlier development) and this seems the safer approach;

• an additional '-run' switch for calling external tools has been added (see here);

• the main dialogue poll code and the routines which deal with the VCR buttons have been re-coded to be much shorter and more efficient;

• a general review of how other routines and internal tools used the routines to switch the content/greyed status of the dialogue and change the information line messages was undertaken and some improvements made;

• a tool to produce the three early settlement examples required by the Agreements Regulations has been added (see here);

• partly as a consequence of adding the above tool, a simple tool to enable a description to be included in a logged or printed calculation has also been added (see here);

The installer program now also installs the program's sub-folders and certain files to make if easier for administrators to install DualCalc on systems with restricted access rights.

Our thanks to TSOs and staff within OFT who continue to provide feedback on the program.

The first public release of the program.

Most importantly this version provides a facility to print properly formatted results directly to the printer (ie without the intervention of your web browser).

There were numerous other small changes in this final 'tidy up' of the program and help files, probably not all of which are documented here:

• the formatting of the headings to the logged and printed output has been re-done and made consistent for all types of output

• the 'Spool' option is now also available for direct printing, to assist with producing large print output.  The program has also been tested with the Jaws for Windows reader for the blind or visually impaired user, and appears to work reasonably well

• some of the debugging information about calculations, formerly only available when running the program from the source editor, is now reported in the information line.  If you want to examine this it may help to increase 'Iterations' delay in 'Options'.  It is however very abbreviated and uses terms peculiar to the program

• another debugging facility which may be of interest is that keying 'Alt' during an APR calculation (which uses Newton's Method by default) will cause it to switch to the Bisection method

• some anomalies in the checking of values entered into the combo-boxes (where this is permitted) have been corrected - essentially so that they reject values of zero or less

• some further bugs and glitches associated with removing the First sum and First interval inputs have also been corrected

You can find an archive of the history of older (pre-public-release) versions of the program on the developer's site by clicking here.