In an effort to create a simple solution to this, I created a form and two functions (a "set" and a "get") that can be cleanly and easily called whenever you need to work on a global variable. The "variables" are not stored in memory, but in a simple persistent table that can be accessed throughout the application. This approach has been suggested before, but I tried to make it cleaner by wrapping some set/get functions around it to reduce redundant coding.

This is not a perfect solution by any means, but it gets me most of the way there. Just sharing it in case useful to others. I am attaching all the code in a file.

High-level, these are the steps to implement it:

1. Create a form called globalvar per the attached source code.

2. Hide the form in your app by moving it to a "dummy" section and hiding that section.

3. In a namespace of your choosing, create a user function called setvar, copying the attached source code. This function will be globally available to your Zoho apps, so you only have to create it once. 

What this function does is c reate or update an entry in the globalvar table that associates a user-supplied variable value with a user-supplied key and the user's login identity. It is up to the developer to ensure a unique key; I usually use a prefix indicating the relevant context (e.g. a form name), with a variable name and the relevant record ID appended. You could add a timestamp if you want to be REALLY sure it's unique, but then you'd have to remember that timestamp when you go to retrieve the value again. The way I do it seems to suffice. There is an example in the attached source file.

4. Create a corresponding getvar function per the source code attached. It includes a boolean parameter that allows you to decide whether to "free" the global variable after reading its value. If you don't free it, it will persist beyond your session, which could actually be useful and in any case doesn't harm much.

5. When you need to store a global variable value in a script, simply call setvar(), When you need to get that value back, use getvar(). These can be used to hit the same variables throughout your application—i.e., they have truly global scope. So you could set a value inside the OnUpdate handler of one form and retrieve it in the OnLoad of a different form. Handy.

LIMITATIONS:

Just some I can think of....

- My sample code handles only string variables. You could create similar functions for other data types, but for my purposes this is fine; I can convert the type after retrieving the value if I need to.

- There is no automatic garbage collection upon application termination, as you might expect in a real programming language. The getvar function allows you to free a variable (= delete the record from the globalvar table), but if you forget to do it you will slowly accumulate outdated records. If Zoho exposed a session_id we'd be easily able to control this, but they don't. Overall, the effect of leaving stray records behind you is pretty benign IMHO. Note that depending on your key-naming conventions, a dangling record will simply be reused the next time the same user wants to operate on that form.

- It's up to you to make sure the lookup key you feed to setvar() is unique enough to avoid accidental overwrites by other processes, since you're storing your stuff in the database rather than in memory. This is a double-edged sword, though. By being clever in your key-naming you could decide which variables to persist session to session, across users, and there might sometimes be a good reason to do that architecturally.

So - not perfect, but anything to get rid of the clunky "hidden field" hack! I hope this is useful to someone out there until Zoho gets their act together and implements true variable scoping. (Hey, it's Christmas time, Zoho - what a nice gift that would be!)