Backward compatibility

andy's Avatar


29 Dec, 2022 01:36 PM

If my objective is to develop an extension that is compatible with past versions to a limited extent, what is a successful approach to check for this. "Compatible" as in "don't fail" by either a workaround for the lesser version or don't implement the affected feature.

For example, the Account.getRecursiveBalance() is " only available since build #274". So I assume if my extension were installed on a pre-274 version it would fail at runtime.

So disregarding for a moment the age of a pre-274 version, in general is there common way of using the FeatureModuleContext.getBuild (or alternative) that might enable me to work around this sort of thing - (or at least detect that a feature is not available). Extension is in Java if needed.

Is it as simple as checking the getBuild result against e.g. 274 and applying logic?

Can it be suggested what a reasonable "cut-off" might be for older version compatibility where the extension would not be expected to function. And how to implement such a cut-off.


  1. 1 Posted by Stuart Beesley ... on 29 Dec, 2022 02:25 PM

    Stuart Beesley (Mr Toolbox)'s Avatar

    Easy... Yes!

    Ah, hang on... Is this Python or pure java?

    If Python:

    if moneydance.getBuild() >= 4091:
       print "This is the current version of MD"
       print acct.getRecursiveBalance()

    So, Py(jy)thon is perfectly happy with this as all code is run dynamically, there is no precompile.

    You just need to know the build numbers relevant to the methods you are calling..

    Toolbox extension has many of these checks so it can use code relevant to that build...

    So, for Java to resolve/compile, then I expect you will need to supply it (your IDE/compiler) with a moneydance.jar file that contains the relevant methods... I'm guessing here, but if you want a multi version setup then you might have to link all the relevant jars from relevant versions to your project so that it can resolve all the calls..... As far as I am aware you can just save your jar files as moneydance4091.jar, moneydance274.jar (etc) and just link them all into the IDE (even if you don't include them in the final extension package)...

    As for your other question:
    - I hard code a check for a minimum build of 1904 (which is MD2019.4). Why, well there was a major change to CurrencyType / Securities before then and also changes to the internal structure(s) of MD... Just too complicated to worry about.. If you are using the official API moneydance dev jar to link/compile then everything in there (except one thing) should work / compile... If you are going off piste and using unpublished methods, then you need to know which were added/changed since the API jar was compiled.. Thus 2019.4(1904) is a reasonable cutoff..

    NOTE: when using java to get back to the right Main version of context you need to cast as follows: mdContext = ( context;

    Let me know how this goes?

    Any more questions, shout..?

  2. 2 Posted by Mike Bray (Quot... on 29 Dec, 2022 04:09 PM

    Mike Bray (Quote Loader Author)'s Avatar

    You need to be careful.  How far do you want to go back? The underlying
    data model of MD changed between versions 2015 and 2017 of MD so you
    have different versions of your extension.  With 2017/2020/2021/2022 the
    data model is the same. Sean introduced the SyncRecord way of
    controlling updates in MD 2017.

    Also be careful of which version of java you use to compile. TIK has
    been changing the java version and if you compile with a newer version
    of java than your target version then you might run into problems.

    If you are writing Java then the .mxt file will have a meta_info.dict
    file which has the minbuild parameter ( "minbuild" = "1820").  1820
    happens to be the one of the earlier builds of MD 2020.  MD will not
    load your extension if the minbuild parameter is greater than the build
    of MD.

    Lastly, if you look at you can get the
    final build number for each version of MD. Just click on the version and
    the build number is shown, eg. MD 2017 is build 1706.

  3. System closed this discussion on 30 Mar, 2023 04:10 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac