-
Impact of changing $root.$prefs.$language on my code
It took me long session of debugging to find out that instead of only changing the runtime/user environment’s language and locale settings, it also changes my code, in an inconsistent way:
Switching from English to German in order to have the right decimal points (,) and thousands separator (.) when exporting data, it also changes (without notice) the parameter delimiter from (,) to (;). This goes & works without further intervention, BUT what it does not change is parameters passed as a string (see example below). After the language change, Omnis expects the delimiters to be (;) but still finds (,), and throws the error ‘Invalid subform parameters’ when trying to open the form.
Aside from this being a nasty behaviour (I’d expect the the program code to remain untouched by language settings) – is there pref setting to keep the runtime language and the IDE language apart, or at least to determine the parameter delimiters (;/,) independently of language settings?
Well, in Andreas original post (https://www.omnis.net/community/forums/forum/discussion/export-to-a-file-issues/) to my export-to-a-file-issue, I found the right clue:
Calculate #S1 as $root.$prefs.$separators() ## gets the current set of separators
Do $root.$prefs.$separators.$assign(‘,.,,;’) ## changes the functional separator to (,)
Maybe this will keep someone safe from stepping into the same problem …
Calculate lcParams as "1,2,3,4,5" $cinst.$clientcommand('subformdialogshow';row('rfFormToShow';<b style="font-size: 1rem;">lcParams;'Title';320;480;kFalse))
omnis.net
Export to a file-issues - Omnis Forum
Dear $all,I would like to export list data into a file.a) is there a (platform-independant) way to export to Excel?b) I'd like to include a…
Log in to reply.
