Summary: | Basic's Str function adding unnecessary blank space before negative numbers | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Rafael Lima <rafael.palma.lima> |
Component: | BASIC | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | himajin100000, mikekaganski |
Priority: | medium | ||
Version: | 7.2.2.2 release | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: |
Description
Rafael Lima
2022-01-05 12:33:31 UTC
(In reply to Rafael Lima from comment #0) > However, running the same code above with Option VBASupport 1, I get the > expected result: > ' 10' > '-10' The difference is related to https://git.libreoffice.org/core/+/cb52ceae9eeeeac3b13a97b73746570315f1aa66, which implemented the different handling for VBASupport, while previously it added leading space unconditionally, in all modes. I would *guess* it was done to be backward-compatible with some code; and I'd say just keep it as is, because, while conceptually wrong, it doesn't matter much (today, even the space before positives to align with negatives is just a legacy from monospace-font terminal times), and so fixing this might create more problems in existing code expecting the spaces, than resolve. My suggestion would be - just avoid mentioning this detail in help, if possible, and keep it as is :-) > As a side note, running the code above with Option Compatible does not fix > the problem. Only adding Option VBASupport 1 fixes it. Well, this does not seem to be a problem itself. Option Compatible is compile-time option (enabling/disabling language features); runtime functions returning different results should *rightfully* depend on Option VBASupport, which is about run-time. |