Two applications running with same variable names problem

[mrcoollion]

I have the following problem.

I am running two applications side by side (Livecode 7.1.1 indy).
The problem I have is that I use the same routines with same variable names in both applications (in this case database open or create routines).
As soon as I start up the second application, LiveCode does not separate those variables in memory per application but it overwrites the variables set by the first started application.
This means in my case that when I use a database ID (gDatabaseID) variable in the first opened application after I have opened the second application it uses the wrong information (from the second opened application). So in this case it cannot find the table (that is how I found out about this ).

Shouldn't LIVECODE keep variables separated per application even in development mode?

Kind regards,

Paul

[bn]

Hi Paul,

this ONLY happens with global variables and it is not a bug but the way global variables behave and what they are made for. That is one of the reasons many people advise against using them. As handy as they are at times you don't know where they were changed.

Alternatively you could use a script local variable (those are the ones declared outside of any handler usually at the top of a script. Now the problem is that only handler in that script can access that script local variable.

A solution could also be that you have your scripts that need access to a common information in e.g. the stack script and you do all your database in the stack script.

here is an example stack that shows how to access script local variables in the card script.

Kind regards
Bernd

[mrcoollion]

Hi Bernd,

Thanks for the explanation.
At least I now know to be careful with global vars and have a way to do it different.

Kind regards,

Paul

[quailcreek]

Hi Paul,
The script in Bernd's stack is great advice. If you are using a global for your database ID, here is an alternative. It uses a stack user property. I try to avoid using global's.

Code: Select all

## Connect to the current open DB. This goes into a preOpen or open stack script
   put specialFolderPath("documents") & “/MyDatabase.sqlite" into tDatabasePath
   put revOpenDatabase("sqlite", tDatabasePath, "binary,extensions") into tDatabaseID
   set the uDatabaseID of this stack to tDatabaseID

## This is code for calling the Db ID. See the second line
      put "SELECT FigureID, Condition, theDescription, bCodeNum FROM " & theCollection into tSQLStatement
      put revDataFromQuery(tab,cr, (the uDatabaseID of this stack) ,tSQLStatement) into tData

[mrcoollion]

Just an idea for others.

I am now working different with global variables.
With this methode it is easy to find out what the global vars are and what data they contain.
Also I only have to carry away one global variable in each script instead of multiple.
So what did I do?

Wel it is easy. I define all my global variables in one Array variable called gApplicationnameV01

like here :

Code: Select all

 put gDatabaseID into gApplicationnameV01["gDatabaseID"]

With the routine below I am always able to to see what global vars have been declared and what data they contain.
Also if I have two versions of the same application I can easy replace the gApplicationnameV01 for gApplicationnameV02 with search and replace and run them side by side without global variables getting in the way.
Also running two applications is not a problem anymore due to the different global variable array names (the application-name is therefor part of the global array variable name).

Code: Select all

// This code comes from a button, the function is an existing script from livecode tutorials. it could be simplified for this purpose.
global gApplicationnameV01
on mouseUp
  answer displayArrayData (gApplicationnameV01)
end mouseUp
 
 function displayArrayData pArray, pIndent
    # create the variable that loops through the keys in the array
    local tKey
    if pArray is an array then
        # print information to indicate that we are entering a new nested level of the array
        get "Array" & return
        # print full stops that allow the reader to track the depth of an element
        put "." after pIndent
        # create the indentation
        put tab after pIndent
        repeat for each key tKey in pArray
            # call displayArrayData with a nested array
            put format("%s[%s] => %s\n", pIndent, tKey, displayArrayData (pArray[tKey], pIndent)) after it
        end repeat
        delete the last char of it
        return it
    else
        return pArray
    end if 
end displayArrayData

If this seem interesting for you just try it and if there are big drawbacks please let me know here!

Kind regards,

Paul

[jacque]

You don't mean "applications", you mean "stacks", right? Apps don't share variables.

[mrcoollion]

Correct...

[dunbarx]

Hi.

All good stuff. Know that these problems go away if you use custom properties in place of global variables. These do not cross stack boundaries like globals do. So even if each stack has, say, a unique custom property in its own "field 1", calling that property from somewhere else, like the msg box, will depend on which stack is the defaultStack.

Craig Newman

[mrcoollion]

Hi Craig,

I tried the following.

Put the following line in the main stack script

Code: Select all

set the cMyGlobalVar of this stack to "InfoInMyGlobalVar" 

In another card in a button I placed.

Code: Select all

   put the cMyGlobalVar of this stack into testvar
   answer "cMyGlobalVar = " & testvar

Works ! Thanks Craig.

[dunbarx]

Good.

Play with working this from different stacks. You will have to call properties explicitly:

Code: Select all

put the someProperty of stack notThisStack...

In that sense, custom properties require more effort than globals, which lurk everywhere all the time. But they cannot be partitioned as we just did.

Craig