https://bugs.documentfoundation.org/show_bug.cgi?id=166232
--- Comment #15 from Mike Kaganski <[email protected]> --- (In reply to Cameron from comment #12) > I cannot lunch the macro in safe mode. It does not work even if I apply > default settings in the Safe Mode options and set minimal security > requirements. You cannot launch a macro in safe mode, *because* you try to run it from a document (which shows how you do not read what I wrote: I explicitly asked you to test *without anything opened first*). You never attached a sample document with the data or macros (only GIFs), and your GIFs show how complex your documents are - and you expect people who want to reproduce your problem to invent your data for themselves. But I didn't ask you to attach your document - because even if you did that, it would be a hard work to make sense in someone else's complex code. I asked you to prepare a *standalone* macro, that does *not* depend on anything else. It should be easy to test for anyone; and in my comment 11, I described which steps should be enough. These steps did not include "look at GIFs and try to re-create something yourself; or open a document, and try to figure which of the sheets and which of the functions are relevant". The idea was: paste the code copied from here, into the "My Macros and Dialogs", and it would run. And yes, it would run from there. But for a document-local macro, the default security level prevents that, which you see. Sigh; if you pay attention, when you *change* the security level, the dialog will show you a yellow warning about the need to reload the document (implemented in bug 159985 for version 24.8.0). It will show it, when the choice is *changed* - so it definitely appeared to you the first time (not shown on your screencast - because there you already didn't change the setting). So yes, your code would run in safe mode, too - but that wouldn't allow me to reproduce, because your code relies on your document, and comment 12 doesn't provide a code that works out-of-the-box. Now let's see at your previous descriptions. You start comment 0 with: > One of the fields gives a wrong answer when performing the same mathematical > operation: when trying dividing the values of two cells, if one of them has > a decimal value between 0 and 1 (e.g.: 0.05), Calc gives a wrong answer. > > In my example : if field A (containing value of 3) divided by field B > containing value of 1.5), Calc returns the value of 1.5 (instead of 2). Just reading this already creates some confusion. It talks about "a decimal value between 0 and 1 (e.g.: 0.05)", and immediately provides an example of dividing 3 by 1.5, where both are greater than 1. > I understood the cause of this: Calc (& BASIC) consider "," as a thousand > separator while "." is used for decimal values (which is annoying, you > should just keep one of them for decimal values and that's it). This is wrong, thousand separator has nothing to do here. If it were relevant, then it would only affect treatment of "1.5", and if the decimal there would be treated as thousand separator, then the resulting number used in calculations would be 15 (or even 1500), and dividing 3 by any of these would make the result of the division not 1.5, nor 2, but a value less than 1 (either 0.2, or 0.002). > ... > > Steps to Reproduce: > 1.Build a simple interface with two field boxes > 2.Make them divide one another and make the result be written in a cell > using this line of code for instance: MySheet.getCellByPosition(1, 1).Value > = Clng(FieldA_string) / CLng(FieldB_string) And here is the problem, that you use CLng. This problem has been explained to you by Robert in comment 6. Yes, CLng is documented [1] to return a long *integer*. It *necessarily* converts any floating-point number that it may obtain from the string, into a *whole number*. Meaning, that "1.5" is rounded up to 2, which produces the result that you see: 3 / 2 = 1.5. You were advised to use CDbl. > ... > > Actual Results: > Wrong mathematical result (or sometimes division by zero error) So here we see the wrong expectation, not a wrong mathematical result. Then in comment 7 you provide another screencast, showing that you replace CDec with CDbl, and get an error (that you translate in comment 8). But we can't see the actual value in "PrixProduit_string"and "Contenance_string" - and your dialog is complex, e.g. with some of the controls using currency. You are in the position to inspect the strings locally, and create the *simple* code for us to reproduce. "Simple" meaning: you, when preparing that code, put a breakpoint before the failing line; you inspect the values of the strings; you create the code that has these exact string literally, like in sub HereIsAReallySimpleReproducingMacro s1 = "2,02 euro" s2 = "3,0" MsgBox CDbl(s2) / CDbl(s1) end sub And note how my sample does not anybody to look at any kind of GIF, or to inspect something called "Sub DisplayingDialogbox" (which is even not referenced from "Sub Macro"!) to understand, what "ActivationInterface" is, and how to obtain it. [1] https://help.libreoffice.org/latest/en-US/text/sbasic/shared/03100600.html?DbPAR=BASIC -- You are receiving this mail because: You are the assignee for the bug.
