Created attachment 109093 [details]
spreadsheet to show eroneous behaviour
crash when using oDoc.NumberFormats.AddNew in attached spreadsheet
Steps to reproduce:
1. execute macro Main results in:
In V126.96.36.199 normal execution
In V4.2.6 and V188.8.131.52 results in crash with message:
Er is een uitzondering opgetreden
the crash occurs in the line
nFormatId = oDoc.NumberFormats.AddNew(sFormat, oLocale)
This was tested on three different computers, all with Windows7
Normal completion as with V184.108.40.206
No crash with LO 4.3.3, win7.
no crash with Version: 220.127.116.11.0+
Build ID: fae7fed54206b98cc3aac24abcdac384d3bd9437
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-11-06_02:16:12 crash nor
No crash, but error message>BASIC runtime error.
An exception occurred
nFormatId = oDoc.NumberFormats.queryKey(sFormat, oLocale, True)
BASIC runtime error.
Argument is not optional.
Macro works in LO 3.5, linux (no crash nor error message), setting as NEW.
I don't understand the purpose of the macro, "nl" is language, not country.
So if you reverse the order of paramaters, it's ok.
Now I recognize that in this case, you don't enter in addEntry.
I changed a format just for the test to enter in AddEntry part, it was ok.
Eike: thought you might be interested in this one (Calc + Format/locale Number). I wonder how this could work in previous version.
Are you sure this ever worked? Because it can't, or the outcome is at least arbitrary at best... note also that a BASIC runtime error is not a crash.
Anyhow, this macro tries to query/add a format code to the locale "du-nl", probably assuming that would be Dutch in Netherlands. But it is not, Dutch has the language code "nl" instead of "du", in fact ISO 639 language code "du" is not defined at all. So the correct locale would be "nl-NL".
What happens then is that the locale falls back to en-US because du-NL is unknown, and trying to parse the format code does not work because of different separators and keywords, so querying for the format key always fails, and adding the numeric format apparently adds *something* because it can't be properly parsed, which when repeated yields the runtime error. The exact behavior may have changed here, but throwing an error seems not to be wrong.
Changing du-NL to nl-NL makes the macro magically work ;-)
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":
for unknown locales check is needed even for ll[l][-CC] tag, fdo#86011 related
It will be available in 4.4.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
So one difference was that current versions fall back to en-US in this case while earlier versions effectively fell back to the system locale for the number formatter, which in your case probably happened to be nl-NL and thus matched the format codes by accident. The above change has the side effect that the fallback is system locale for the number formatter again, but that is nothing to rely on, it still is undefined behavior to pass an unknown locale / language tag.
Julian, Eike, Raal,
Thanks for your help!
I wrote this macro in 2006 and it has been working as long as I did not update from 3.6 to 4.3.
After reading the LibreOffice documentation it became clear that I should use nl-NL. This of course works great!