Omnis Studio - Multi Library Tasks

[Stephane Pras]

Brian,

Thanks for this helpful clarification. Your analysis is correct. Effectively
I have three Startup_Tasks running together Š Since I implemented some
controls on it, I can say that current task always is MyLib, while active
task is switching between LibA and LibB, according to the topmost window.

LibA and LibB are totally independent, they do not interfere. The only
reason why I want to open both simultaneously, it is that while I am working
on LibA for instance, it may be useful to open LibB and browse the contents.
Rather than closing / opening / closing / reopening them, I'm willing to
open and run both libraries "in parallel". So I just have to switch if I
want to check something in the other, for instance printing a report listing
some relevant data I need.

> It's like having LibA for processing client's technical data, and LibB for
> storing general legal information. You often need to check on B while working
> on A.

Each library is properly ruled by its own Startup_Task, which opens and
closes windows, menus, datafile, etc. I have no need to establish a
centralized control, except for passing to both the instruction:
> $autoactivate.$assign(kTrue)
and for enforcing the proper Set current data file() when switching the
active task (this was my problem we just have been discussing).

I followed Omnis Programming's "Using Tasks" instructions, but maybe I
misunderstood them. Creating two tasks LaunchA and LaunchB in MyLib for the
only purpose of opening and closing LibA and LibB may be overkill.  I
imagine I could remove them and just have the open and close library
instructions in the MyLib menu.

But then, where to put $autoactivate.$assign(kTrue) and Set current data
file() ? Presently the first one is in LaunchA/LaunchB, the second one in
LibA/LibB.

Any suggestion to make it simpler would be welcome Š

Stephane

From:  Brian O'Sullivan <brian.os at verizon.net>
Reply-To:  OmnisDev List - English <omnisdev-en at lists.omnis-dev.com>
Date:  Tuesday, January 13, 2015 2:00 AM
To:  OmnisDev List - English <omnisdev-en at lists.omnis-dev.com>
Subject:  Re: Omnis Studio - Multi Library Tasks

On Jan 12, 2015, at 12:30 PM, Stephane Pras <stephane.pras at noos.fr> wrote:

>  Effectively inserting:
>  
>  $activate()
>       Set current data file {myFile}
>  
>  is enough to ensure that the proper data file will be used each time a task
>  is activated. But where to put it?
>  1. Not in the Startup_Task of the container MyLib;
>  2. Nor in any of the LaunchA or LaunchB tasks I put in MyLib to open and
>  close LibA or LibB respectively;
>  3. But only in the Startup_Task/Class methods of LibA and LibB.
>  Don't ask me why, I tried all, only (3) is working !


They key question to ask here is: which task instance is active when you
install menus & open window instances? *That* will be the owning task
instance. If LibA's and LibB¹s startup tasks contain the logic to install
menus & open window instances, that explains #3 perfectly.

I don¹t understand the design you are using in point #2. There are parallels
between tasks and libraries in that they are both containers; a library
contains classes at design time, while a task instance contains instances at
runtime. When you create a new library, Omnis Studio gives you a
Startup_task by default, and an instance of this Startup_task will open when
the library is opened (unless you tell Omnis not to by holding down the
<Ctrl> key in the Studio browser, or by using the command option in the
³Open library² command). If MyLib, LibA, and LibB each have a startup task
and you are *not* using the ³do not launch startup task² option, then after
all 3 libraries are open you will have three separate task instances open -
MyLib¹s startup task, LibA¹s startup task, and LibB¹s startup task.

It sounds like you¹re trying to establish ³ownership/control² of LibA from
MyLib.LaunchA, but that¹s not how tasks work. You could use LaunchA to open
LibA, but that creates no relationship between the instance of LaunchA and
the library LibA. Task instances contain only instances in the runtime
universe, while LibA lives in the design universe. You can open instances of
LibA¹s classes in the runtime universe, but the task instance does not exist
in the design universe, only its task class "blueprint".

If your goal is to have two independent tasks to contain instances from LibA
and LibB respectively, the simplest design would be to use each library¹s
startup tasks - which it sounds like is happening for you in point #3!


>  having two independent libraries operating in parallel in the same task...

I¹m not sure I understand your main goal - is it to have all libraries under
control of one task instance, or did you really want each library¹s classes
to operate ³locally² in its own task instance? Both designs are possible; I
showed examples of both types of application patterns at  EurOmnis last
October. I hope the discussion here is helpful!

-brian o¹sullivan; bear, DE
(USA)_____________________________________________________________
Manage your list subscriptions at http://lists.omnis-dev.com