Today we finished the porting of the Unit Conversion Engine from ESBPCS for VCL to ESBDevLib.
In ESBPCS, whilst we did have Conversion Components for each Measurement Type – most of the work was done by a plethora of standalone Functions. In the new approach, we have a Class for each Measurement Type, and these classes do all the computational work – though many do rely on Global Constants like “OnePound” which is One Pound in Kilograms. The various “Onexxxxx” constants are grouped in Measurement Type Regions and we have aimed to based things on “primary conversions” such as the definition of a Pound in Kilograms, an Inch in Metres, etc – and then build up the constants and conversions from those. Hence we have increased the accuracy in some of the conversions but more importantly have improved maintainability.
We have had Mark and Luke both working on Unit Testing over their Holidays (they enjoy getting some extra money), and today we also finished all the DUnit based Unit Testing for the Classes. So this also should increase the Reliability. We did discover a few bugs and these will also be fixed in the next release of ESBPCS for VCL (hopefully end of next week).
We have also finished adding Abbreviations (where available) for each unit. This feature won’t be added to ESBPCS as it fits in better with the Dictionary Approach we are using for the Resource Strings. We are using a nice little in-house App to maintain these – and at a push of a button it generates all the code and strings for the various Dictionaries for both Delphi and C#. Plus it generates the current String Resources for ESBPCS.
So our Classes are “happy” in VCL and FireMonkey – sadly we have fallen behind in the C# port of these but should catch up over the next month.
As far as components go – we are strongly considering just having one non-visual component that encapsulates all the Conversion Classes (36 of them so far). In ESBPCS, we have a Component for each Measurement Type – but I think if you just want to do Mass Conversions then the current class is fine without needing a non-visual component. However when you do use the Component you get all the Conversions as well as all the Dictionary Lookups. Anyway I am open to further discussion on this point 🙂
Currently we do have 834 Units in 36 Different Measurement Categories – and are aiming to see this grow as we work on v9 of our ESBUnitConv Pro which will be using the new ESBDevLib Conversion Engine 🙂