Bug report : 'Optional' keyword with 'Option Compatible'
Hello,
I would like to report the following bug : in the declaration of a
function, when an "Optional" parameter declares its type definition,
that type is not assigned to the parameter immediately, but only after
the first use of this parameter by the function.
Example :
1 Option Compatible: Option VBASupport 1
2 Function TestCompatible(*Optional xyz As Long = 5*)
3 If xyz = 5 Then
4 xyz = 23
5 else
6 print "KO"
7 end if
8 print xyz
9 End Function
This function should obviously print out '23', however it prints out "KO" !
Here is the explanation why :
- setting a break at line 3 shows that xyz has a value "Missing parameter"
- the condition of line 3 thus evaluates to False,
- and execution continues at line 6, printing "KO"
- note that breaking again at line 8 shows that xyz now has a type
'Variant/String' with value "5"
Discussion :
- Andrew already reported this bug in 2016 in its 'OOME Pitonyak 2016
_3_0 UserGuide.pdf', page 58.
- Note that without the "Option Compatible" the function could be
written also :
2 Function TestCompatible(Optional xyz) As Long
2.5 If IsMissing(xyz) then xyz = 5
and in this case there is no bug (and it is then normal for xyz to
have that value "Missing parameter", used by IsMissing).
-> Thus as a preliminary conclusion, it shows that the parser
actually processes the "As Long = 5", because the value "5" is displayed
at line 8,
but it does not apply this type and value immediately : it sets the
value to "Missing parameter" (just as if ignoring Option Compatible at
that moment)
To demonstrate that the type of xyz is assigned only after the first use
of this parameter, look at the following example now, where a line 2bis
has been inserted :
1 Option Compatible: Option VBASupport 1
2 Function TestCompatible(Optional xyz As Long = 5)
*2bis **xray xyz*
3 If xyz = 5 Then
4 xyz = 23
5 else
6 print "KO"
7 end if
8 print xyz
9 End Function
This function is the same as previous one and should also obviously
print out '23', however it now prints out '5' !!
Here is the explanation why :
- xray of xyz tells us that xyz is of type "String" with value "5" ;
this is confirmed by setting a break at line 3 which shows that xyz is
"Variant/String"
- the condition thus evaluates to True, as it compares xyz to Cstr("5")
- line 4 is thus executed, but ... *the assignment xyz = 23 is not
performed* !
Discussion :
- The same behavior will result if the line 2bis is replaced by any
statement making use of the variable xyz, like e.g. "txt$ = xyz"
- We observe that upon the first use of the parameter xyz in the
function, its value changes from "Missing parameter" to its declared value,
but without changing its type to its declared type.
Conclusion : there are in fact potentially 3 bugs to report :
1. the parameter xyz has a value "Missing parameter" when it is first
used :
with Option Compatible the parameter should receive the declared
type as soon as the function begins
2. after the first use of this parameter in a statement, it hasthe right
value but a type "Variant/String" instead of the declared type "Long" :
the declared type should be transferred over
3. it is not possible to assign any value to the parameter
Versions tested : OO Version 4.1.6
OO Version 4.1.13
notice: on LO Version 6.0.7.3, same behavior, except : the
assigmnent "xyz = 23" works (the value is assigned).
Thank you all !
Lucien.
Re: Value returned by CInt("+1")
Hi, Le 19/06/22 à 10:41, Czesław Wolański a écrit : In LibreOffice 7.2.7 each of the functions: CInt, CLng, CDec, CSng and CDbl returns 1 if the argument is "+1". Same outcome on a VBA version Excel 2010. If I may ask: Does it also happen with Excel 2003? Yes, in Excel 2003, both CInt, CLng, CDec, CSng and CDbl return 1 if the argument is "+1" Best regards, Lucien
Re: isnumeric function
Thank you Dennis for this explanation. This is an answer to my original
question.
To know what is recognized as a number, someone should specify the grammar for
such constants, and then there's something to QA against.
From what I see the grammar includes 'D' as a valid exponent marker, as
type conversion functions recognize 'D' as an exponent. Thus nothing to
QA on the side of 'isnumeric'.
However, after the tests I ran I discovered the following, which on my
opinion should be considered as bugs :
- CDbl("123E456") and CDbl("123D456") which enter an infinite loop,
- CDec("123E456") and CDec("123D456") which should raise an overflow
instead of returning 0
yours faithfully,
Lucien
Le 23/06/22 à 18:57, dennis.hamil...@acm.org a écrit :
Lucien asked,
" Is that a relic from prehistoric ages ?"
Yes.
E was the original exponent marker for what we would now call float values.
D was added to distinguish double from (single-precision) float.
This had nothing to do with (Visual) Basic (for Applications) originally.
To know what is recognized as a number, someone should specify the grammar for
such constants, and then there's something to QA against.
- Dennis
-Original Message-
From: Lucien Mathay
Sent: Thursday, June 23, 2022 08:12
To:qa@openoffice.apache.org
Subject: Re: isnumeric function
Le 23/06/22 à 16:23, Dave a écrit :
Like Pedro, I can replicate your issue, but cannot explain it, other
than to say it might be that the function is seeing 123D456 as a Hex
value, which equates to Decimal 19.125.334.
Dave,
the problem then is that 'A', 'B', 'C' and 'F' are not accepted
Only 'D' and 'E' are accepted :
- 'E' probably stands for Exponent, thus is should be valid character in the
numeric string
- 'D' : something like "Decimal" ?
[orcmid] [ ... ]
- I note that msgbox ("123D-456") also returns True : 'D' seems thus to behave
like an exponent.
Power of 10 maybe ?
- lets test msgbox("123D3") : it prints out 123000 ; it seems thus
perfectly equivalent to "123E3"
Note that msgbox CDbl("123D3") does not loop but prints out 123000
Is that a relic from prehistoric ages ?
Lucien.
-
To unsubscribe, e-mail:qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail:qa-h...@openoffice.apache.org
-
To unsubscribe, e-mail:qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail:qa-h...@openoffice.apache.org
Re: isnumeric function
Le 23/06/22 à 16:23, Dave a écrit :
Like Pedro, I can replicate your issue, but cannot explain it, other
than to say it might be that the function is seeing 123D456 as a Hex
value, which equates to Decimal 19.125.334.
Dave,
the problem then is that 'A', 'B', 'C' and 'F' are not accepted
Only 'D' and 'E' are accepted :
- 'E' probably stands for Exponent, thus is should be valid character in
the numeric string
- 'D' : something like "Decimal" ?
- in fact, as Basic states it is a number, I tried to print it out :
-> msgbox CLng("123D456") : raises an error stating an overflow
-> msgbox CDbl("123D456") : enters an infinite loop and you must
terminate the program to exit from this loop
-> msgbox CDec("123D456") : prints the value zero (0)
- I note that msgbox ("123D-456") also returns True : 'D' seems thus to
behave like an exponent.
Power of 10 maybe ?
- lets test msgbox("123D3") : it prints out 123000 ; it seems thus
perfectly equivalent to "123E3"
Note that msgbox CDbl("123D3") does not loop but prints out 123000
Is that a relic from prehistoric ages ?
Lucien.
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: isnumeric function
Le 23/06/22 à 14:53, Dave a écrit :
Try =ISNUMBER("123D456") instead of =ISNUMERIC("123D456")
Thank you and sorry, Dave, I forgot to specify that the question was
related to Basic. ( msgbox ISNUMBER("123C456") sends "Basic error -
function not defined" )
In Basic thus, msgbox isnumeric("123D456") returns True, although it
should return False, if I am not wrong ?
Lucien
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
isnumeric function
Hi again,
can anybody explain me why isnumeric("123D456") returns True ? (notice
well the "D")
To me it looks strange ... but maybe I miss something
Thanks,
Lucien.
Re: Bug Label not recognized after if...then Resume
Hi Mathias, Le 23/06/22 à 13:31, Matthias Seidel a écrit : Since you are on Windows, you might also want to test on my personal builds of AOO42X: no, it also fails. Best regards, Lucien
Bug Label not recognized after if...then Resume
Hello all, I am back already. I found a bug similar to the bug reported previously with "If...then...else" followed by a comment. In the present case, the bug concerns a Label "exitfunction" that follows a line "if...then Resume" ; here is the code : Function EffacerFichier(nom As String, msg As String) As Boolean Dim nb As Long On Error GoTo erreur EffacerFichier = True GoTo exitfunction erreur: nb = nb + 1 If nb<3 Then Resume exitfunction: End Function The error message states : "Label 'exitfunction' undefined. However when inserting a blank line just before the label 'exitfunction', the compiler parses OK. I tested it on both OO4.1.6 and OO4.1.12, both fail. Sorry for that, Lucien.
Re: Value returned by CInt("+1")
Hi Carl,
Le 18/06/22 à 17:49, Carl Marcum a écrit :
I see that VBA does handle this now. I don't know if that was always
the case.
When tested on a VBA version Excel 2003, CLng("+1") returns 1
Best regards,
Lucien
Hi Czesław,
On 6/16/22 6:58 AM, Czesław Wolański wrote:
Hi,
The problem was reported yesterday on the English forum: topic
"CINT("+1")
returns 0".
https://forum.openoffice.org/en/forum/viewtopic.php?p=525249=0481325a63f94adf45c49ba4175701d7#p525249
In version 4.1.12, CLng("+1") returns 0 too.
I haven't found any relevant report in Bugzilla. Do you think this
problem
is "Bugzilla-worthy"?
Kind regards,
Czesław
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
-
To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bug report : comment after "if ... then ... else"
Thanks Mathias for introducing this part of the team ; I will also introduce myself : I am the developer of a program in VB, and I now start to translate it into Basic. It has some complexity. You might hear more from me in the future if I discover other strange things. Best regards, Lucien. Le 15/06/22 à 16:57, Matthias Seidel a écrit : Hi Lucien, I only did provide the build. Carl found the fix and backported it... Thanks Carl for finding it and Damjan for fixing it in the first place! ;-) Regards, Matthias Le 14/06/22 à 16:52, Matthias Seidel a écrit : Hi Lucien, Please find my latest builds for Windows here: https://home.apache.org/~mseidel/AOO-builds/AOO-4113-Test/Full%20Installation/ Regards, Matthias Am 13.06.22 um 19:05 schrieb Matthias Seidel: Hi Lucien, Am 13.06.22 um 18:23 schrieb Lucien Mathay: Hi Mathias, yes, I can test it out with pleasure. Great! I use Windows XP. It's the easiest for me, but I can also have access to a Windows 10. Windows XP *should* work. Try that and if you find the time test on Win 10... I will start a new build now and will come back when finished and uploaded. Regards, Matthias Regards, Lucien. Le 11/06/22 à 16:51, Matthias Seidel a écrit : Hi Carl, Now that the fix is in AOO41X I will prepare a new build (for Windows). Maybe Lucien can test/confirm the issue is solved? @Lucien: What OS do you use? Regards, Matthias Am 07.06.22 um 23:23 schrieb Carl Marcum: Hi Matthias, On 6/7/22 6:53 AM, Matthias Seidel wrote: Hi Carl, Am 07.06.22 um 00:59 schrieb Carl Marcum: Hi Lucien, On 6/6/22 12:51 PM, Lucien Mathay wrote: Thank you Regina, but if I add an 'endif' at the end of the line ( " if a = b then a=1 Else a=2 endif 'test "), the compiler fails with the message "Syntax error : unexpectes symbol : End If". Furthermore, the book from "OpenOffice .org Macros OoOffice et Apis" from Bernard Marcelly and Laurent Goddard states p.118 : "Lorsqu’une seule instruction suffit dans la partie Then et dans la partie Else, la séquence peut s’écrire sur une seule ligne : If expr1 Then instruction1v Else instruction1f Notez l’absence du End If dans cette forme simplifiée." which means, translated : "When only one instruction is used in the section Then and in the section Else, the sequence can be written on one single line : If expr1 Then instruction1v Else instruction1f Please note the absence of End If in this simplified usage" Therefore I still consider this as a bug. I believe you are correct. In my recent work on making the trunk test suites standalone to run against other branches like AOO41X I discovered some other bug fixes that were applied to trunk and AOO42X but never back ported to AOO41X. Two examples I put in a PR-150 [1]. One of which related to variable names in single-line if statements. I tested your example against that build but it isn't fixed by it but I believe I found the patch that fixed your bug in trunk [2]. Issue 126272 [3] is listed in Bugzilla with a target milestone of 4.2. I think this needs a more general discussion on dev@ about how much we should change API's in 4.1.X. Which I intended to do anyway before merging my PR-150. Thanks for pointing this out! [1]https://github.com/apache/openoffice/pull/150 [2] https://github.com/apache/openoffice/commit/07396187f6055b1e7cffa86f38cc88b274dfb1d6 [3]https://bz.apache.org/ooo/show_bug.cgi?id=126272 I think this fix [2] should be cherry-picked to AOO41X. BTW: The target milestone 4.2.0 was trunk at that time. Later we made trunk 4.5.0 and branched 4.2.0, but the milestones were not updated. Yes, I just want to make sure it wasn't intentional to leave this one and a few other changes the the Basic macros out of the 4.1 line due to not wanting to change API or code behavior. I will create a PR for it or maybe just add it to the other one I've got open since they are all small and bring a discussion on dev@. Then if we agree it's okay I'll pull them in. Best regards, Carl Regards, Matthias Best regards, Carl With kind regards, Lucien Le 6/06/22 à 13:32, Regina Henschel a écrit : Hi Lucien, Lucien Mathay schrieb am 06.06.2022 um 10:42: Hello, I would like to report the following bug : in the macros when a line containing "if ... then ... else" is followed by a comment on the same line, the compiler fails. Example : Function test() dim a as long, b as long a=0: b=0 if a = b then a=1 else a=2 'test b=1 call msgbox b End Function The if-statement misses endif. Kind regards, Regina - To unsubscribe,e-mail:qa-unsubscr...@openoffice.apache.org For additional commands,e-mail:qa-h...@openoffice.apache.org - To unsubscribe,e-mail:qa-unsubsc
Re: bug report strange behaviour usertypes
Actually, maybe I have a clue (by me it always comes after sleep) I would best describe it as a scenario : - when the code of the basic is modified, as per point 3 below, OO probably sets a flag - when executing the program, as in point 4, OO checks this flag and if the code of the basic has been modified, it parses the section of the definitions (Consts, Dims and Types). Thus the first execution runs flawless. - when executing the program a second time, as in point 5, OO checks the flag and does not parse the section of the definitions again as nothing has been changed, this reduces execution time. - however, when finishing the execution of the basic code in point 4, OO more than probably has done some sort of cleanup in its storage allocation. And in doing that it could maybe have wiped out the storage of the definition "Type ZONEDIALOG" Therefore when executing point 5, this storage would be missing, hence the error message. With the knowledge you have, does this scenario seem valid ? Thanks, Lucien. Le 15/06/22 à 16:52, Lucien Mathay a écrit : Hi all, the version 4.1.13 I tested does not make any difference with regard to the bug 'strange behaviour usertypes' reported earlier. (unfortunately ; why would it have made a difference anyway ? :-) I still worked on this problem and managed to further simplify the code showing the problem. It is shown here, along with the steps necessary to show the strange behaviour : option explicit Type ZONEDIALOG hauteur As Long largeur As Long End Type Dim ZDstack(0 To 2) As ZONEDIALOG Sub Main() dim quoi as Long quoi = ID_UNDEFINED msgbox "OK" End Sub If you want to show the problem : use the attached file, (as it does not show up when this code is copied into a fresh sheet), then follow the steps : 1. Execute the code : -> error "undefinded variable" on ID_UNDEFINED : which is perfectly normal ; program stops. 2. Execute the code again : -> the same error "undefinded variable" ; program stops. (as expected, but this point is just there to check this :-). 3. Replace "ID_UNDEFINED" by a constant : "quoi = 2" 4. Execute the code : message box "OK" : and you think the problem is solved, ... BUT ... 5. Execute the code again : -> error 9 "index out of defined range" at "Dim ZDstack(0 To 2) As ZONEDIALOG" ; and the program continues, as it displays "OK" 6. Execute the code again : -> same error 9 as point 5. 7. Now ! Modify the code : Replace "OK" by "Really OK ?" 8. Execute the code : message box "Really OK ?" : no more error 9 ! , and this is due to the fact that the code has been modified 9. Execute the code again : -> error 9 appears again ; and program continues, as it displays "Really OK ?" The stack dump here attached shows that the exception "error 9" is thrown from within "basic::NameContainer::getByName", and the exception specifies "com::sun::star::container::NoSuchElementException", which is 'thrown by child access methods of collections, if the addressed child does not exist'. Just as if the "Type ZONEDIALOG" definition would have been removed from memory ? Does anyone have any clue of what is going on ? Thanks alot if you have ! Lucien. Le 10/06/22 à 17:03, Lucien Mathay a écrit : Ah, sorry, I am not yet used to this exercise with 'Reply to List' ! Lucien Le 10/06/22 à 16:44, Carl Marcum a écrit : Hi All, I got reply this off-list so I'll add it here: OO on 4.1.6 and 4.1.12, installed on Windows XP and LibreOffice Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.11 Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail:qa-unsubscr...@openoffice.apache.org For additional commands, e-mail:qa-h...@openoffice.apache.org
Re: Bug report : comment after "if ... then ... else"
This bug is now fixed. Thanks Matthias. Le 14/06/22 à 16:52, Matthias Seidel a écrit : Hi Lucien, Please find my latest builds for Windows here: https://home.apache.org/~mseidel/AOO-builds/AOO-4113-Test/Full%20Installation/ Regards, Matthias Am 13.06.22 um 19:05 schrieb Matthias Seidel: Hi Lucien, Am 13.06.22 um 18:23 schrieb Lucien Mathay: Hi Mathias, yes, I can test it out with pleasure. Great! I use Windows XP. It's the easiest for me, but I can also have access to a Windows 10. Windows XP *should* work. Try that and if you find the time test on Win 10... I will start a new build now and will come back when finished and uploaded. Regards, Matthias Regards, Lucien. Le 11/06/22 à 16:51, Matthias Seidel a écrit : Hi Carl, Now that the fix is in AOO41X I will prepare a new build (for Windows). Maybe Lucien can test/confirm the issue is solved? @Lucien: What OS do you use? Regards, Matthias Am 07.06.22 um 23:23 schrieb Carl Marcum: Hi Matthias, On 6/7/22 6:53 AM, Matthias Seidel wrote: Hi Carl, Am 07.06.22 um 00:59 schrieb Carl Marcum: Hi Lucien, On 6/6/22 12:51 PM, Lucien Mathay wrote: Thank you Regina, but if I add an 'endif' at the end of the line ( " if a = b then a=1 Else a=2 endif 'test "), the compiler fails with the message "Syntax error : unexpectes symbol : End If". Furthermore, the book from "OpenOffice .org Macros OoOffice et Apis" from Bernard Marcelly and Laurent Goddard states p.118 : "Lorsqu’une seule instruction suffit dans la partie Then et dans la partie Else, la séquence peut s’écrire sur une seule ligne : If expr1 Then instruction1v Else instruction1f Notez l’absence du End If dans cette forme simplifiée." which means, translated : "When only one instruction is used in the section Then and in the section Else, the sequence can be written on one single line : If expr1 Then instruction1v Else instruction1f Please note the absence of End If in this simplified usage" Therefore I still consider this as a bug. I believe you are correct. In my recent work on making the trunk test suites standalone to run against other branches like AOO41X I discovered some other bug fixes that were applied to trunk and AOO42X but never back ported to AOO41X. Two examples I put in a PR-150 [1]. One of which related to variable names in single-line if statements. I tested your example against that build but it isn't fixed by it but I believe I found the patch that fixed your bug in trunk [2]. Issue 126272 [3] is listed in Bugzilla with a target milestone of 4.2. I think this needs a more general discussion on dev@ about how much we should change API's in 4.1.X. Which I intended to do anyway before merging my PR-150. Thanks for pointing this out! [1]https://github.com/apache/openoffice/pull/150 [2] https://github.com/apache/openoffice/commit/07396187f6055b1e7cffa86f38cc88b274dfb1d6 [3]https://bz.apache.org/ooo/show_bug.cgi?id=126272 I think this fix [2] should be cherry-picked to AOO41X. BTW: The target milestone 4.2.0 was trunk at that time. Later we made trunk 4.5.0 and branched 4.2.0, but the milestones were not updated. Yes, I just want to make sure it wasn't intentional to leave this one and a few other changes the the Basic macros out of the 4.1 line due to not wanting to change API or code behavior. I will create a PR for it or maybe just add it to the other one I've got open since they are all small and bring a discussion on dev@. Then if we agree it's okay I'll pull them in. Best regards, Carl Regards, Matthias Best regards, Carl With kind regards, Lucien Le 6/06/22 à 13:32, Regina Henschel a écrit : Hi Lucien, Lucien Mathay schrieb am 06.06.2022 um 10:42: Hello, I would like to report the following bug : in the macros when a line containing "if ... then ... else" is followed by a comment on the same line, the compiler fails. Example : Function test() dim a as long, b as long a=0: b=0 if a = b then a=1 else a=2 'test b=1 call msgbox b End Function The if-statement misses endif. Kind regards, Regina - To unsubscribe,e-mail:qa-unsubscr...@openoffice.apache.org For additional commands,e-mail:qa-h...@openoffice.apache.org - To unsubscribe,e-mail:qa-unsubscr...@openoffice.apache.org For additional commands,e-mail:qa-h...@openoffice.apache.org
Re: Bug report : comment after "if ... then ... else"
Hi Mathias, yes, I can test it out with pleasure. I use Windows XP. It's the easiest for me, but I can also have access to a Windows 10. Regards, Lucien. Le 11/06/22 à 16:51, Matthias Seidel a écrit : Hi Carl, Now that the fix is in AOO41X I will prepare a new build (for Windows). Maybe Lucien can test/confirm the issue is solved? @Lucien: What OS do you use? Regards, Matthias Am 07.06.22 um 23:23 schrieb Carl Marcum: Hi Matthias, On 6/7/22 6:53 AM, Matthias Seidel wrote: Hi Carl, Am 07.06.22 um 00:59 schrieb Carl Marcum: Hi Lucien, On 6/6/22 12:51 PM, Lucien Mathay wrote: Thank you Regina, but if I add an 'endif' at the end of the line ( " if a = b then a=1 Else a=2 endif 'test "), the compiler fails with the message "Syntax error : unexpectes symbol : End If". Furthermore, the book from "OpenOffice .org Macros OoOffice et Apis" from Bernard Marcelly and Laurent Goddard states p.118 : "Lorsqu’une seule instruction suffit dans la partie Then et dans la partie Else, la séquence peut s’écrire sur une seule ligne : If expr1 Then instruction1v Else instruction1f Notez l’absence du End If dans cette forme simplifiée." which means, translated : "When only one instruction is used in the section Then and in the section Else, the sequence can be written on one single line : If expr1 Then instruction1v Else instruction1f Please note the absence of End If in this simplified usage" Therefore I still consider this as a bug. I believe you are correct. In my recent work on making the trunk test suites standalone to run against other branches like AOO41X I discovered some other bug fixes that were applied to trunk and AOO42X but never back ported to AOO41X. Two examples I put in a PR-150 [1]. One of which related to variable names in single-line if statements. I tested your example against that build but it isn't fixed by it but I believe I found the patch that fixed your bug in trunk [2]. Issue 126272 [3] is listed in Bugzilla with a target milestone of 4.2. I think this needs a more general discussion on dev@ about how much we should change API's in 4.1.X. Which I intended to do anyway before merging my PR-150. Thanks for pointing this out! [1]https://github.com/apache/openoffice/pull/150 [2] https://github.com/apache/openoffice/commit/07396187f6055b1e7cffa86f38cc88b274dfb1d6 [3]https://bz.apache.org/ooo/show_bug.cgi?id=126272 I think this fix [2] should be cherry-picked to AOO41X. BTW: The target milestone 4.2.0 was trunk at that time. Later we made trunk 4.5.0 and branched 4.2.0, but the milestones were not updated. Yes, I just want to make sure it wasn't intentional to leave this one and a few other changes the the Basic macros out of the 4.1 line due to not wanting to change API or code behavior. I will create a PR for it or maybe just add it to the other one I've got open since they are all small and bring a discussion on dev@. Then if we agree it's okay I'll pull them in. Best regards, Carl Regards, Matthias Best regards, Carl With kind regards, Lucien Le 6/06/22 à 13:32, Regina Henschel a écrit : Hi Lucien, Lucien Mathay schrieb am 06.06.2022 um 10:42: Hello, I would like to report the following bug : in the macros when a line containing "if ... then ... else" is followed by a comment on the same line, the compiler fails. Example : Function test() dim a as long, b as long a=0: b=0 if a = b then a=1 else a=2 'test b=1 call msgbox b End Function The if-statement misses endif. Kind regards, Regina - To unsubscribe, e-mail:qa-unsubscr...@openoffice.apache.org For additional commands, e-mail:qa-h...@openoffice.apache.org - To unsubscribe, e-mail:qa-unsubscr...@openoffice.apache.org For additional commands, e-mail:qa-h...@openoffice.apache.org
Re: bug report strange behaviour usertypes
Ah, sorry, I am not yet used to this exercise with 'Reply to List' ! Lucien Le 10/06/22 à 16:44, Carl Marcum a écrit : Hi All, I got reply this off-list so I'll add it here: OO on 4.1.6 and 4.1.12, installed on Windows XP and LibreOffice Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.11 Best regards, Carl - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
bug report strange behaviour usertypes
Hi, I am sorry to seek help and at the same time report a strange behaviour, for a problem on which I can not find the origin. I have a strange behaviour in an OOBasic program, and to make it simple I pruned down the question to the 12 lines of program which are displayed here : option explicit Type ZONEDIALOG hauteur As Long largeur As Long End Type Dim ZDstack(0 To 2) As ZONEDIALOG Function Auto_Open() dim quoi as long quoi = 2 'const_xyz msgbox "OK" End Function The strange behaviour is as follows : * when executing this program, the message "Ok" comes up as expected, everything is fine and there is no error. * However now, consider the constant "2" at line 'quoi = 2' : if you replace this constant "2" by "const_xyz" (which is obviously undefined), observe what happens during thenext executions : o first execution brings up the message "Ok" : the error was not detected, although option explicit is active ... but that is not yet the biggest problem o executing a second time brings up "Basic execution error 9 : index out of the assigned range" at the line 'Dim ZDStack' * Now if reverting back to the constant "2" by removing "const_xyz" and putting the constant "2" in place again, it is also abnormal : o first execution shows "Ok" o following executions bring up "Basic execution error 9 : index out of the assigned range" at the line 'Dim ZDStack' There is however a background to this behaviour : this file is issued from a full program showing this problem by removing all the unnecessary functions and sheets out of the program. If this small portion of code is copied to a fresh calc file, the strange behaviour does not show up. Therefore, I suspect the behaviour to be caused by something else than just the code ; this is why I appended the file to this mail, for you to be able to debug. I compared the sections of the file with the xml sections of a fresh document, and I found differences only in content.xml, settings.xml and styles.xml, but nothing that could explain me why this behaviour. If a charitable person could analyse this file, it would help me getting running the full program from which it is issued ... and it would probably expose a new bug in OO. It won't be an easy job however I believe, therefore I am really thankful in advance ! Lucien PS: I tried the file on two versions of OO and one LibreOffice, it does not make any difference. Copie de FACTURE debuggage.ods Description: application/vnd.oasis.opendocument.spreadsheet - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Bug report : comment after "if ... then ... else"
Thank you Regina, but if I add an 'endif' at the end of the line ( " if a = b then a=1 Else a=2 endif 'test "), the compiler fails with the message "Syntax error : unexpectes symbol : End If". Furthermore, the book from "OpenOffice .org Macros OoOffice et Apis" from Bernard Marcelly and Laurent Goddard states p.118 : "Lorsqu’une seule instruction suffit dans la partie Then et dans la partie Else, la séquence peut s’écrire sur une seule ligne : If expr1 Then instruction1v Else instruction1f Notez l’absence du End If dans cette forme simplifiée." which means, translated : "When only one instruction is used in the section Then and in the section Else, the sequence can be written on one single line : If expr1 Then instruction1v Else instruction1f Please note the absence of End If in this simplified usage" Therefore I still consider this as a bug. With kind regards, Lucien Le 6/06/22 à 13:32, Regina Henschel a écrit : Hi Lucien, Lucien Mathay schrieb am 06.06.2022 um 10:42: Hello, I would like to report the following bug : in the macros when a line containing "if ... then ... else" is followed by a comment on the same line, the compiler fails. Example : Function test() dim a as long, b as long a=0: b=0 if a = b then a=1 else a=2 'test b=1 call msgbox b End Function The if-statement misses endif. Kind regards, Regina
Bug report : comment after "if ... then ... else"
Hello, I would like to report the following bug : in the macros when a line containing "if ... then ... else" is followed by a comment on the same line, the compiler fails. Example : Function test() dim a as long, b as long a=0: b=0 if a = b then a=1 else a=2 'test b=1 call msgbox b End Function The presence or not of the comment " 'test " at the end of the line changes the result displayed : >When the comment is present on the line, the message displays the result "*b=0*", which is wrong >When the comment is omitted, the message displays the result "*b=1*", which is correct The error thus comes from the fact that *when this comment is present, the program ignores the next line*. You can confirm this again by placing the line with this comment just before the line "End Function" : the compiler will report "End Function is missing" ! Thank you all ! Lucien.
