Backward compatibility
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 "...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.
Thanks.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | 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
1 Posted by Stuart Beesley ... on 29 Dec, 2022 02:25 PM
Easy... Yes!
Ah, hang on... Is this Python or pure java?
If Python:
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:
Let me know how this goes?
Any more questions, shout..?
2 Posted by Mike Bray (Quot... on 29 Dec, 2022 04:09 PM
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
https://infinitekind.com/previous-versions-of-moneydance 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.
Regards
Mike
System closed this discussion on 30 Mar, 2023 04:10 PM.