Issue 70700 - Basic Mid instruction is changed by CompatibilityMode(True)
Summary: Basic Mid instruction is changed by CompatibilityMode(True)
Status: CLOSED NOT_AN_OOO_ISSUE
Alias: None
Product: App Dev
Classification: Unclassified
Component: scripting (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: PC Windows XP
: P3 Trivial
Target Milestone: ---
Assignee: ab
QA Contact: Unknown
URL:
Keywords: oooqa
Depends on:
Blocks:
 
Reported: 2006-10-22 12:56 UTC by bmarcelly
Modified: 2013-02-24 21:00 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description bmarcelly 2006-10-22 12:56:11 UTC 
Run this macro:

Sub Main
dim test as string
CompatibilityMode(True)
test = "abcdefg"
Mid(test, 3, 3, "Y")
' result should be : abYfg
print test, "result is " & (test="abYfg")
End Sub

With version 2.0.4 the result is "abYdefg"
With CompatibilityMode(False), or with version 1.1.5, result is "abYfg", consistent 
with Mid() specification in OOoBasic.

In VBA Mid() instruction does not exist. It is only a function with 3 arguments. (VBA 
detects a syntax error if 4 arguments or if used as an instruction).
If the idea is to use CompatibilityMode() to adapt to VBA syntax, there is a bug, and 
this is a very bad idea. Because CompatibilityMode() was introduced in version 1.1.1 
to enforce Private declarations in OOoBasic, and programmers may already use it for 
this, and not for VBA compatibility.
Comment 1 kay.ramme 2006-10-27 16:58:25 UTC 
Andreas, please take care of this ...
Comment 2 ab 2006-10-30 10:54:33 UTC 
No, CompatibilityMode() has not been introduced to enforce private declarations.
CompatibilityMode(true) has the meaning "Behave compatible to VB(A)" and there 
has never been any different meaning. CompatibilityMode is important as it al-
lows to change the behaviour of existing runtime functions in order to make
them VB compatible without breaking existing code not using CompatibilityMode.
Making private declarations really private is only one example amongst many
other changes covered by CompatibilityMode(true).

Also Mid has been changed. In CompatibilityMode it's possible now to use the 
correct VB syntax: Mid(test, 3, 3) = "Y". Internally this is mapped to the old
Mid(test, 3, 3, "Y"), but of course also the result must be the same as in VB.
As this hasn't been the case it had to be fixed. Your "false" result is the
correct VB result and that's what I expect in a VB compatibility mode. As you
wrote VB doesn't even know Mid with four arguments. The CompatibilityMode is
designed to run correct VB programs correctly, the behaviour of incorrect VB
programs is not specified.

So when using CompatibilityMode(true) Basic programmers must be aware of the
fact that the behaviour of runtime functions may differ from the former beha-
viour and that there could be even more changes in the future. You can only
decide if you want to use the CompatibilityMode completely or not at all.
There's no way to only pick a detail you like. -> INVALID
Comment 3 ace_dent 2008-05-17 20:58:19 UTC 
The Issue you raised has been marked as 'Resolved' and not updated within the
last 1 year+. I am therefore setting this issue to 'Verified' as the first step
towards Closing it. If you feel this is incorrect, please re-open the issue and
add any comments.

Many thanks,
Andrew
 
Cleaning-up and Closing old Issues
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html
Comment 4 ace_dent 2008-05-17 22:59:46 UTC 
As per previous posting: Verified -> Closed.
A Closed Issue is a Happy Issue (TM).

Regards,
Andrew