Calc 24.8 Comment in Basic macro incompatibility problem

English
,
#1

Up until including Libreoffice version 24.2
Next to REM and ’ as comments indicators # worked as well
Unfortunately, since working with diverse code languages for other packages, I accidentality used # as comment indicator just 1 up to 3 times per workbook in about 2000 (out of 4000) workbooks since 2015 which I sometimes use to analyse historical financial data stored in these workbooks.

When I load these workbooks with LibreOffice 24.8 it causes many error messages during opening.
These errors end in the Basic IDE and indicate fortunately each time #debug as the cause.
For example in a Sub like this;
Function nInRange( aRange as Array, Value as Variant ) as Long
#debug msgbox LBound( aRange,1)
#debug w=LBound( aRange,1) x=UBound( aRange,1) y=LBound( aRange,2) z=UBound( aRange,2)
nInRange=-1
For h=LBound( aRange,1) to UBound( aRange,1)
For i=LBound( aRange,2) to UBound( aRange,2)
if aRange(1,i)=Value then
nInRange=i
h=UBound(aRange,1)
i=UBound(aRange,2)
End If
Next
Next h
End Function

How can I change in these 2000 files the #debug into 'debug (or into REM debug) by a command-line in linux?
Or change a setting in Libreoffice Calc 24.8 to still accept the # as comments indicator?

#3

The erroneous handling of # was fixed in commit a400c865a6c9f0185a1986db617ee6fc9dd1861d, without an option to revert. It was a plain bug; and we should not re-introduce a spacebar heating option :wink:

image

I say that as someone who had to create such options at least once :slight_smile:

2 Likes
#4

worth mentionning it to ReleaseNotes/24.8 - The Document Foundation Wiki ?

#5

Of course no. All mentions of bugfixes in release notes are wrong - release notes aren’t about bugfixes, they are about features. Whoever adds bugfixes there is confused (we have different lists for bugfixes, available from release plan pages like this). Note, that no references to other projects are relevant - it is about how it’s in this project, not elsewhere.

1 Like
#6

:thinking:

image
image847×46 15.6 KB

#7

This is why I added yo to the block list. Your comments everywhere are just nonsensical, and this is an example of a “reply” that provides no value, no question, no use. Yes you provided a screenshot, where Miklos added a bugfix. So what? What is your statement or question? (I decided to react to your posts - and here is how I immediately see I would better do if I kept ignoring you, which I resume now.)

1 Like
#8

so according to you it’s wrong.
so be it, Miklos being one of the most senior contributor ?
would need to check *“nonsensical” * :frowning:
(and “wrong” )
→ ReleaseNotes/Guidelines - The Document Foundation Wiki

#12

I would like to contribute on this that reintroducing # for comments is not logic.
But for downward compatibility, for only when opening files created in earlier versions, a solution would be required for less experienced users or is that against legacy support?
When altering BASIC coding of these legacy files in 24.8 and onwards then the correct style could be enforced.
On my Ubuntu installation the current version of LibreOffice is 24.2 and the SNAP version is 24.8.
This is why I can still use CALC files I use for my private monthly financial administration which where designed, Basic macros, years ago already. But no longer on my WIndows OS where only 24.8 is installed without altering the BASIC coding. That is a nobrainer for me but not for many user cases.
And for history analyses by importing data from many CALC files by macros from within a workbook the opening of these legacy files will fail as well if the BASIC macros have the # for comments on some places.
For the both I would suggest legacy support instead of the given solution in this item.
But may be this should be a new item?

#14

I would suggest legacy support instead of the given solution in this item

You are welcome to file a bug report. However, changing code to support some bug forever means ever increasing code complexity (itself meaning more possible bugs), and ever increasing support burden on volunteer developers.

You may see in the link I posted above, that at least once, we had to make a decision to keep compatible with an old bug. But that happened, when we learned from actual reports, that there is a real large amount of affected code, which can’t be fixed easily.

So in your case: you are, so far, the only person who stumbled this change. And you can fix it. So your case should not be a reason to introduce that complexity. We are really large project - which means, that any significant problem eventually gets reported (among the affected users, there will definitely appear someone who reports); a reasoning like “there may be users who suffer, but you don’t get reports because they don’t write them” doesn’t belong here. So - my advice would be, just don’t file it, let the problem tell about itself, if and only if it happens to be significant.

#15

I understand where you’re coming from, being an ex support employee on embedded software decennia ago.
And let’s see if others come across the issue as well or find their own solutions.

1 Like
#2

unzip xyz.ods Basic/Standard/* && perl -i -pe 's/^\s*#debug/rem /' Basic/Standard/* && zip -rm xyz.ods Basic

1 Like
#9

fpy thanks for clarifying.
I expected it to be a repaired bug item and so no surprise that # for comments will be supported no longer.

I used;
unzip xyz.ods Basic/Standard/* && perl -i -pe ‘s/^(\s*)#debug/${1}rem /’ Basic/Standard/* && zip -rm xyz.ods Basic
, to preserve eventual leading whitespace before the # .

The command-line works well but alters the creation/modification datetime .
Since the 2000 files are of older dates it would be nice if the original creation/modification datetimes are kept/restored after modification.
Might you also have an addition to the commandline to achieve this?

#10

→ touch(1) - Linux manual page

touch -r xyz.ods dummy.ref &&   ... && touch -r dummy.ref xyz.ods
#11

Thanks again.

So given solution by you in total is (including preserving leading whitespace):
command-line
touch -r xyz.ods dummy.ref && unzip xyz.ods Basic/Standard/* && perl -i -pe ‘s/^(\s*)#debug/${1}rem /’ `Basic/Standard/* && zip -rm xyz.ods Basic && touch -r dummy.ref xyz.ods

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.