Parent | Child | Previous | Next
 

Xbasic - DIMMing Variables

Description

A change has been made in how Xbasic operates when DIMMing a dot variable. If the user has not explicitly specified the scope in the DIM statement, Alpha Anywhere will now try to see if the dot variable parent container already exists in all scopes (GLOBAL, SHARED, etc. ) and if so, it will DIM the variable in that scope rather than creating a new locally scoped variable.

It is possible that this change will break an existing application in some way. We think that chance of this breaking existing applications is extremely small, but if so, the change to your Xbasic to fix the problem will likely be very simple, as explained below.

The example in this article will illustrate the point.

This article applies to developers who are migrating applications from Alpha Five V10 or older to a newer release of Alpha Anywhere.

dim global myGvarContainer.myvar1 as c = "alpha"
dim myGvarContainer.myvar2 as c = "beta"

In the above example, the user was explicit about the scope in the first statement, but not the second statement. As a result, with the previous version of Alpha Anywhere, the following variables were created:

Now, as a result of the change, the following variables are created by the above two commands:

In the above example, had the second DIM statement been written as:

dim global myGvarContainer.myvar2 as c = "beta"

Then the old behavior of Alpha Anywhere and the new behavior would have been identical.

To reiterate the point here, if you look at the second DIM statement above, you see that there is no explicit scope. But since Alpha Anywhere can find the variable container ('myGvarContainer') in the Global name space, the new variable ('myvar2') is created as a child of the existing variable in the Global namespace, rather than creating a new variable in the Local name space.

In the above example, if you want to preserve the old behavior, you can easily do so by adding this extra DIM statement (highlighted below):

dim global myGvarContainer.myvar1 as c = "alpha"
dim myGvarContainer as p
dim myGvarContainer.myvar2 as c = "beta"

Now there will be two 'myGvarContainer' dot variables - one in the Global name space and one in the Local name space, and the DIM statement for 'myvar2' will create a Local variable (just as it did before this change was introduced).

Why was this change made? The reason this change was made is that users were breaking their Web applications by writing code like this:

dim session.var1 as c  = default "beta"

The reason for doing this was to ensure that a session variable existed before its value was tested. For example:

dim session.var1 as c  = default "beta"
if session.var1 = "" then
    'do something
end if

This would not work as the user was probably expecting because the DIM statement was actually creating a LOCAL variable called 'session' and then DIMming 'var1' as a child of the LOCAL 'session' variable.

The user was likely expecting the above DIM statement to DIM 'var1' in the Global 'session' object.

Now, as a result of the change made in this build, the above statement will DIM var1 in the Global 'session' object.

Note however, that the following code pattern would still be wrong and would lead to errors:

dim session as P
dim session.var1 as c  = default "beta"
if session.var1 = "" then
    'do something
end if

This would create a LOCAL variable called 'session' that would mask the global 'session' object and 'var1' would have been created as child of the local 'session' variable.

Bottom Line

Do not put DIM session AS P in your Xbasic code in Web Applications unless you actually want to create a local variable of type P in the LOCAL name space. We think this is incredibly unlikely.