STEPS TO REPRODUCE: 1-a. Run the following code Sub Main() Dim x As Date Dim y As Date x = #1/2/2013# y = 1/2/2013 Msgbox(x <> y) End Sub EXPECTED RESULT: true ACTUAL RESULT: false ===================== ADDITIONAL INFORMATION: 1-b. Run the following code REM ***** BASIC ***** Sub Main() Dim x #x = 1 #If x #Then Msgbox(x) #End If End Sub EXPECTED RESULT: COMPILE ERROR ACTUAL RESULT: 1 ========================= '#' is ignored except for some special cases http://opengrok.libreoffice.org/xref/core/basic/source/comp/scanner.cxx#243 http://opengrok.libreoffice.org/xref/core/basic/source/comp/scanner.cxx#502
Reproduced. Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: fi-FI (fi_FI)
@Jan, a plausible easyhack?
(In reply to Xisco Faulí from comment #2) > @Jan, a plausible easyhack? yup.
I uploaded a patch to support date literals: https://gerrit.libreoffice.org/#/c/36002/ Currently, lines starting with # are treated as compiler directives and ignored. I didn't change this behavior as it could break compatibility with some existing macros.
For My Information: I'm unsure where I can find the official speicification of StarBasic. At least there exists a format requirements for date literals in VBA https://msdn.microsoft.com/en-us/library/3eaydw6e.aspx >Format Requirements >You must enclose a Date literal within number signs (# #). You must specify the date value in the format M/d/yyyy, for example #5/31/1993#, or yyyy-MM-dd, for example #1993-5-31#. You can use slashes when specifying the year first. This requirement is independent of your locale and your computer's date and time format settings. >The reason for this restriction is that the meaning of your code should never change depending on the locale in which your application is running. Suppose you hard-code a Date literal of #3/4/1998# and intend it to mean March 4, 1998. In a locale that uses mm/dd/yyyy, 3/4/1998 compiles as you intend. But suppose you deploy your application in many countries. In a locale that uses dd/mm/yyyy, your hard-coded literal would compile to April 3, 1998. In a locale that uses yyyy/mm/dd, the literal would be invalid (April 1998, 0003) and cause a compiler error.
I updated the patch few days ago. Please have a look.
Thanks for your great work. I've already taken a look on gerrit. (but without compiling, for the reluctance to learn about how to build the libreoffice source. I will try the software when the new build comes out.) Also, I'm sorry not to be useful, I don't have a Mac. (In reply to Grzegorz Araminowicz from comment #6)
Created attachment 132554 [details] macroTest.xls: push-button tests for this bug report (In reply to himajin100000 from comment #0) > ADDITIONAL INFORMATION: > > 1-b. Run the following code > > REM ***** BASIC ***** > Sub Main() > Dim x > #x = 1 > #If x #Then > Msgbox(x) > #End If > End Sub This was fixed in LO5.4 on 2017-02-28 by https://cgit.freedesktop.org/libreoffice/core/commit/?id=97caa8a8a0d80baa1a77859b117a8bc2b8b952f8. x no longer is assigned the value of 1, so an empty msgbox is now displayed. (There are no compile errors, but that hardly seems important. If you want cross-compatible VBA, do your programming modifications in MSOffice.) Note: as suggested by OP, # is not a comment marker in VBA. Excel2003's compiler complains as you type #x = 1. Thus, these functions are invalid code.
Created attachment 132584 [details] macroTest.xls: updated push-button tests for this bug report - all date tests work in Excel (In reply to himajin100000 from comment #0) > Sub Main() > Dim x As Date > Dim y As Date > x = #1/2/2013# > y = 1/2/2013 > Msgbox(x <> y) > End Sub (y = 1/2/2013) is deceptive because this is not treated by VBA as a date. It needs to be a string (y = "1/2/2013") to be treated as a locale-dependant date. In Excel, time-only can be specified as #hh:mm:ss PM#, but not as a string apparently. ("hh:mm:ss PM" doesn't work.)
possible double # on a line from https://msdn.microsoft.com/en-us/library/aa243386(v=vs.60).aspx Data Value assigned to variable ---- -------------------------- #NULL# Null #TRUE# or #FALSE# True or False #yyyy-mm-dd hh:mm:ss# The date and/or time represented by the expression #ERROR errornumber# errornumber (variable is a Variant tagged as an error) And I suppose something like this would be valid. line input #1, myString1 : line input #2, myString2
I thought this bug is only about date literals. I'm afraid supporting more complicated literals would require significant changes how scanner works. Beside uses of # mentioned by Justin, it can be also used as type specifier: 100# means to treat 100 as double. If date literal has spaces inside, it's difficult to differentiate it from other cases, because scanner does not know about context. For example #123 456# can be treated as input parameter and double literal or as incorrect DateTime. Maybe let's keep this bug focused on supporting dates only and open another one for other literals?
A polite ping, still working on this bug
(In reply to Xisco Faulí from comment #12) > A polite ping, still working on this bug I had little free time recently, but I'm getting back to work on the bug this week.
(In reply to Grzegorz Araminowicz from comment #13) > (In reply to Xisco Faulí from comment #12) > > A polite ping, still working on this bug > > I had little free time recently, but I'm getting back to work on the bug > this week. That's fantastic. Thanks for your help Looking forward to seeing this bug fixed
Grzegorz Araminowicz committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f45463d8e2bb0771ec1837d159ff98108b0047cf tdf#93727 Support date literals in basic It will be available in 5.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.
Note: commit notification has a hickup, master is for to-be 5.5.0
I'm no longer working on this bug. Generally date literals are working now, but parsing in scanner.cxx should be improved to support literals containing spaces.
This bug is solved?... In comment 15 is a patch. Is this working still?...
(In reply to BogdanB from comment #19) > This bug is solved?... In comment 15 is a patch. > Is this working still?... (In reply to Grzegorz Araminowicz from comment #18) > I'm no longer working on this bug. Generally date literals are working now, > but parsing in scanner.cxx should be improved to support literals containing > spaces. Bogdan: someone could improve the parsing
Re-evaluating the EasyHack in 2022 This EasyHack is (partially) relevant. The behavior for the first code (1-a) is correct, but for the second one (1-b) is not. The expected behavior for the second code is giving "syntax error", but a blank message box appears. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ed0372bac123b402fe3cd694a455e8328117752d CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: fa-IR (fa_IR); UI: en-US Calc: threaded
Where can I run the given codes 1 and 2 as given in reproducible steps to observe the behaviour?
(In reply to Luv Sharma from comment #22) > Where can I run the given codes 1 and 2 as given in reproducible steps to > observe the behaviour? For example in Writer, Tools - Macros - Organize Macros - Basic, select your document name, New, OK, replace the placeholder code with the code from this report and click Run button (or F5).
I have uploaded a patch, an attempt to solve the Syntax Error part https://gerrit.libreoffice.org/c/core/+/162639
I have implemented a solution to # problem: look at each line if starts with # store the initial words of the line, if it doesn't meet the date condition compare it with #If or #End, if it matches then pass else syntax error is popped. I have tested the approach and it seems to work fine for the above two codes. However the test [1] gives an error during build, output: [2] Can Someone please help me to figure out what am I doing wrong? [1]: void EnableTest::testWin64() { MacroSnippet myMacro(" #If Win64\n" "Declare PtrSafe Function aht_apiGetOpenFileName Lib \"comdlg32.dll\"" "\n" "#End if\n"); myMacro.Compile(); CPPUNIT_ASSERT_MESSAGE("#if Win64 Declare PtrSafe causes compile error", !myMacro.HasError() ); } [2]: test_append.cxx:71:Assertion Test name: (anonymous namespace):: EnableTest::testWin64 assertion failed - Expression: !myMacro.HasError() - #if Win64 Declare PtrSafe causes a compile error My Submission: https://gerrit.libreoffice.org/c/core/+/162639
Luv Sharma committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a400c865a6c9f0185a1986db617ee6fc9dd1861d tdf#93727 Syntax Error on # in basic It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.