Global Variables - Director Class

I am tiring to initialize a set of global variables in main.lua and have them be accessible in all of my “scenes” using Ricardo’s director class. However im having trouble with the values assigned not sticking from scene to scene

example:
main.lua - toggle=true
switch to
scene1.lua - print(toggle) displays “true” (expected, because no change in value ANYWHERE in this scene)
switch to
scene2.lua - toggle event changes toggle=false and print(toggle) displays “false”
switch back to
scene1.lua - print(toggle) displays “true” (unexpected, because no change in value ANYWHERE in this scene)

Could anyone shed some light on why the value keeps going back to “true”?

note**
if in main.lua i replace toggle=true with toggle={} toggle[1]=true

and now manipulate toggle[1], everything works as i would expect with the value sticking from scene to scene.
I must be missing something here. Thanks in advance for any help! [import]uid: 9187 topic_id: 2664 reply_id: 302664[/import]

Is toggle a value already being used by the director class by chance?

How about changing the word ‘toggle’ to something arbitrary, like ‘THE_DOG_JUMPS’, and see if that keeps the value properly.

If so, sounds like a variable name conflict. [import]uid: 8541 topic_id: 2664 reply_id: 7955[/import]

thanks for the input.

i used the word “toggle” im my post as an example.

all of my problem variables have arbitrary names so im confident it is not a name conflict. [import]uid: 9187 topic_id: 2664 reply_id: 7977[/import]

I just encountered the same problem you’re describing (although I really DO appreciate the Director Class VERY VERY much. It might just have saved my hide/deadline!!!).

Here is how I worked around it (certainly interested if someone has a better solution).

in main.lua:

lockedDays = 1
– create Unlock funtion that other modules can see/use
function unlock()
if lockedDays == 0 then lockedDays = 1
elseif lockedDays == 1 then lockedDays = 0
end
end

I then call the unlock() function from a module that needs to manipulate lockedDays and it works perfectly.

-Mark [import]uid: 9189 topic_id: 2664 reply_id: 8212[/import]

agreed, Director Class is great!

using your example, here is the work around i’m using

in main.lua:
lockedDays={}
lockedDays[1]=true

then manipulate it like normal in all other modules - lockedDays[1]=false or lockedDays[1]=true

I’m not sure why using a table sticks and simple boolean doesn’t. [import]uid: 9187 topic_id: 2664 reply_id: 8236[/import]

Oh yah, I get it (should have read your first post more carefully). Good to know I can use a table if needed, although I kind of like the idea of having a function to the work in main.lua.

I think the problem in general is the way global variables are passed to and from modules in LUA vs how tables are built. I found a critique of global variables in modules somewhere (main LUA site?) that seemed to almost touch on the issue we’re seeing.

-Mark [import]uid: 9189 topic_id: 2664 reply_id: 8253[/import]

Guys,

Really sorry, I didn’t see this topic!!!

I have a file called settings.lua where I have all my globals and some functions to get/set them and load/save from database:

module(..., package.seeall)  
  
---------------------------------------------------------  
-- DATABASE  
---------------------------------------------------------  
  
require "sqlite3"  
--  
local dbPath = system.pathForFile("settings.db", system.DocumentsDirectory)  
local db = sqlite3.open( dbPath )  
--  
db:exec [[CREATE TABLE IF NOT EXISTS tb\_settings (  
 name VARCHAR(50) PRIMARY KEY,   
 type VARCHAR(1),  
 value\_string TEXT,   
 value\_number NUMBER);]]  
--  
local function onSystemEvent( event )  
 if( event.type == "applicationExit" ) then   
 db:close()  
 end  
end  
  
---------------------------------------------------------  
-- VARIABLES  
---------------------------------------------------------  
  
local tabVars = {}  
--  
tabVars["gameTime"] = 300  
  
---------------------------------------------------------  
-- FUNCTIONS  
---------------------------------------------------------  
  
-- GET  
function settings:getVar ( pVarName )  
 return tabVars[pVarName]  
end  
  
-- SET  
function settings:setVar ( pVarName, pVarValue )  
 tabVars[pVarName] = pVarValue  
end  
  
-- LOAD  
function settings:loadVar( pVarName )  
 for row in db:nrows("SELECT \* FROM tb\_settings WHERE name = '" .. string.upper(pVarName) .. "'") do  
 if row.type == "N" then  
 return tonumber(row.value\_number)  
 else  
 return tostring(row.value\_string)  
 end  
 end  
 return nil  
end  
  
-- SAVE  
function settings:saveVar( pVarName, pVarValue )  
 --  
 if type(pVarValue) == "nil" then  
 pVarValue = tabVars[pVarName]  
 else  
 settings:setVar ( pVarName, pVarValue )  
 end  
 --  
 local vVarType  
 --  
 if type(pVarValue) == "number" then  
 vVarType = 'N'  
 elseif type(pVarValue) == "string" then  
 vVarType = 'C'  
 else  
 return true  
 end  
 --  
 for row in db:nrows("SELECT count(\*) as cont FROM tb\_settings WHERE name = '" .. string.upper(pVarName) .. "'") do  
 --  
 if row.cont \> 0 then  
 if vVarType == "N" then  
 db:exec ("UPDATE tb\_settings SET type = 'N', value\_number = " .. pVarValue .. " WHERE name = '" .. string.upper(pVarName) .. "';")  
 else  
 db:exec ("UPDATE tb\_settings SET type = 'C', value\_string = '" .. pVarValue .. " WHERE name = '" .. string.upper(pVarName) .. "';")  
 end  
 else  
 if vVarType == "N" then  
 db:exec ("INSERT INTO tb\_settings ( name, type, value\_number) VALUES ('" .. pVarName .. "','N'," .. string.upper(pVarName) .. ");")  
 else  
 db:exec ("INSERT INTO tb\_settings ( name, type, value\_string) VALUES ('" .. pVarName .. "','C','" .. string.upper(pVarName) .. "');")  
 end  
 end  
 end  
end  

To use it is simple:

settings:setVar("gameTime",500)  
local gameTime = settings:getVar("gameTime")  
--  
settings:saveVar("gameTime",1000)  
gameTime = settings:loadVar("gameTime")  
  • get/set functions works only at runtime
  • save/load functions stores the variables at the SQLite database [import]uid: 8556 topic_id: 2664 reply_id: 18675[/import]