I need to store some global stuff, so I’ve created a module for it called, Globals. In globals are a bunch of properties that a number of windows need. Among these are some attributes that I pull out of an executive SQLite database that stores all the stuff the program needs.
So I have a table containing stuff, eg.
create table foo
(
foobar text primary key
,description text
, etc …
)
I read these into the program for use by several routines. So in the module I have stuff like
Globals (the module)
Class
Foo
properties
foobar as string
description as string
etc …
So in a window I might want to use what is stored, say in a pushbutton. So …
pbSomeButton.Action
…
Globals.Foo.foobar = tfSomeStringInATextField
…
I get an error message like
This item does not exist
Globals.Foo.foobar
The compiler sees the class, but not the property.
I do this to group table attributes. I could use a structure. But if I want to do something with a method, then it gets more messy. I guess I could create a global method, but wouldn’t a class be better?
I see nothing in the User Guide or documentation that helps here. Xojo clearly understands the class, because it fills in the properties, but the compiler doesn’t.
Alwyn, I do use the notation you suggested for the Globals.Properties.
I tried instantiating the global classes, but where? In App.Open it didn’t work. If I do something like x = new Globals.Foo somwhere lese then the contents of x belong to the containing class or object, n’est-ce pas?
You can add a property of type Foo to your Globals module (MyProps), and then instantiate it in the App.Open event. Just make sure the scope of MyProps is Global.
You should then be able to access MyProps.foobar from anywhere in the app.
Here is the link to an example project that does exactly that…
When you click the button it reads the value from Globals.MyProps.foobar and outputs it as a messagebox.
Alwin, Thanks again. It had occurred to me to add a method of type Foo. I was going to try it this morning. Thanks for the example. Norman, it is supposed to be a singleton.
OK so in your module add a computed property for this class (lets say its call myProps)
It’s backed by a private instance call mMyprops that is the same type
The in the computed property getter you do something like
[code] if mMyProps is nil then
mMyProps = new props // whatever the class type actually is
end if
return mMyProps
[/code]
you don’t implement the setter
Now you can access Module.MyProps any time and it will always only create one and you don’t have to worry about creating it at the right time - it gets created when you first try to use it
Kem, that what I did at first but decided I needed a class because specific methods need to be encapsulated in the class.
Norman, I like your idea about instantiation … I was going to instantiate in App.Open, but hmmm… I like this idea, not necessarily for this particular class, but for others that may or may not be needed, depending on user choices. Great idea !
Thank all of you for your suggestions. This is a great blog!
PS. Did I see a Malloc somewhere? Can Xojo allocate memory on the fly like this? Where is this stuff? I’m not going to need it, but … my analytic routines are written in C++. This could be really interesting …