Is #L8 truly global?

Mike Matthews - Omnis omnis at
Thu Nov 9 10:51:39 UTC 2023

Ah, you new boys :)

#L1 - #L8
#S1 - #S5 (different lengths)
#1 - #60

So I think you are saying they are ties to a startup_task, but seem to be be available, the same value, to all tasks.  But close the original task, and it goes away.  Well, not the variable itself, just the contents.  So not quite like a task variable.

I know about the passing of vars between libs, I was definitely caught of guard with #L8 disappearing.  I already added a new task var in the second lib to get past this, just a surprise really.  I was hoping they belonged to the Omnis root world.



Lineal Software Solutions
Commercial House, The Strand<x-apple-data-detectors://1/1> Barnstaple, Devon, EX31 1EU<x-apple-data-detectors://1/1>

omnis at<mailto:mike.matthews at><><>

On 8 Nov 2023, at 21:37, Doug Easterbrook <doug at<mailto:doug at>> wrote:

Caution: This is a message which has originated from outside the organisation. Ensure the sender is trusted and the content is safe before opening links or attachments.

#L8 .. I’m going to go truly wild now.  I thought there was only #L1 .. and to find out the are numbered #1 to #8

My understanding is this (from working with Michael M. on our web servers eons ago) .

You have these hash variables available to you per startup_task, and per remote_task instance

so if you close the startup_task that created/defined #L8, its data is gone.   but it is available to be used by other libraries when it is opened.

same with creating a remote_task instance .. you got a set of hash variables and file class variables  unique to that startup task that are not visible to the other remote_task.

if you are thinking of using these to pass around data to various libraries as super globals,  I might suggest not to (it kind of breaks encapsulation)..

instead, I’d pass a parameter (like the example in this statement - #S1)…. if you want libraries to know about each other..

but I’d probably pass in some item references that point back to common objects or just the task itself


Open library (Do not close others,Enable conversion by runtime,Convert without user prompts) [theatreLibraryPathName] (#S1)


Open library (Do not close others,Enable conversion by runtime,Convert without user prompts) [theatreLibraryPathName] ($ctask.$ref,objectRef,etc)

and then, if you want the data in your second libary, you do callbacks to get it, or explicitly clone the data in the second library.

i.e in the library you opened, I’d do things like

do refToMainLibrary.$getL8 returns localList

in other words, don’t depend on something like these being global.       copy the data.   it will reduce points of failure and expectations that data exists.  because the place you talk to the other library is in one spot.

just my thoughts.

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at
Phone (403) 650-1978

On Nov 8, 2023, at 1:18 PM, Mike Matthews - Omnis via omnisdev-en <omnisdev-en at<mailto:omnisdev-en at>> wrote:

Hello All,

In olden days, we only had these # hash type of variables.  We were told they were global to the instance of Omnis.

Then came multi libraries, task variables, instance variables, and so we were encouraged to forget #L1, #S1 and so on.  I still remember #G1, but they has sadly died, while the others stubbornly refuse to die!  Hooray.

If you define #L8 in library A, which opens library B, add lines to it, all is good.  But if you close Library A, then #L8 disappears.

So my questions is this : Are the Hash vars tied to the library that made them, ie, not Omnis Global, or something else that is pushing us to forget these wonderful variables?  I have two demo libraries as well.


Mike Matthews

Lineal Software Solutions
Manage your list subscriptions at
Start a new message -> mailto:omnisdev-en at

More information about the omnisdev-en mailing list