Created attachment 109093 [details] spreadsheet to show eroneous behaviour Problem description: crash when using oDoc.NumberFormats.AddNew in attached spreadsheet Steps to reproduce: 1. execute macro Main results in: Current behavior: In V3.6.7.2 normal execution In V4.2.6 and V4.3.2.2 results in crash with message: ------------- BASIC-runtime-fout. Er is een uitzondering opgetreden Type: com.sun.star.uno.RuntimeException Message: . ------------- the crash occurs in the line nFormatId = oDoc.NumberFormats.AddNew(sFormat, oLocale) This was tested on three different computers, all with Windows7 Expected behavior: Normal completion as with V3.6.7.2
No crash with LO 4.3.3, win7. no crash with Version: 4.3.4.0.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 Type: com.sun.star.uno.RuntimeException Message: . 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.
@Wim: 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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0d3ca29fd21bbd39531c2dd72fca05eeee2f166a 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: http://wiki.documentfoundation.org/Testing_Daily_Builds 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!