Atom Execution with On Deactivate

[agitated]

I'm having a problem getting my head around atoms using 'On Deactivate'.

When 'On Activate' is triggered, it affects a single window. When 'On Deactivate' is used, potentially multiple windows are affected at the same time.

PiP is the example. If I write a pip script that contains code to place multiple deactivated windows in various places on screen, they all execute the atom at the same time and, if there's a condition in the atom to use certain pip locations first, all deactivated windows see the first location as available at the same time, and the pip windows end up stacking on top of each other in the same place.

If I create an identifier for each window (session or something else) then the pip windows are statically assigned onscreen positions and won't fill empty pip slots that may have been made available earlier, so you end up with gaps in the pip window 'list'.

Not really a syntax question, but rather design. I do have a working pip script for 6-boxing, working on the UI and LavishSettings now. The script is fired off from a game configuration but does not run in a loop. It sets some variables and then activates a global atom (On Activate only, no On Deactivate since I couldn't get the timing issue resolved).

The problem I have is that I don't know how to position the multiple deactivated windows inside an 'On Deactive' atom (since they all see the first pip position as available at the same time and stack there).

How to best accomplish this? Any advice would be helpful

[Lax]

I would probably recommend having a script running in the Uplink receiving commands from the sessions to indicate activate/deactivate, and sending commands to each of the sessions to position them.

To relay a command to the uplink, you can use the Uplink command (which does not support the -event switch), or relay <computername> (which does).

All relayed commands are enqueued and executed one at a time on the same thread, so order would be guaranteed. All you need to do is notify your script in the uplink that On Deactivate is triggered. This may also simplify the process by allowing you to keep information about each of the sessions in one place (in the uplink script)

[agitated]

Ah That sounds much cleaner. I hadn't yet realized that I could run scripts in the uplink.

Thanks again, Lax.

[agitated]

I tried the following but the variable didn't get updated (pipFlag is defined in function main() as variable int pipFlag):

Uplink Script[pipscript].VariableScope.pipFlag:Set[0]

If I define pipFlag outside of a function it becomes global(?) and updateable with:

Uplink pipFlag:Set[1]

Is there something wrong with the 'Script' version I tried? Worried about having global vars all over the Uplink.

[Lax]

You shouldn't worry too much about having global variables, you wont run into problems unless you start running multiple scripts that use the same variable names for different purposes

If you define pipFlag outside of a function, the default scope is script scope, as it's being defined in the script. You can explicitly specify it as global if needed.

What I would do instead of directly modifying a variable, is create a global atom in pipscript to use as a command. For example:

Code: Select all

atom(global) pipOnDeactivate(string session)
{
  ; do stuff, such as
   echo OnDeactivate(${session})
   pipFlag:Set[1]
}

While the script is running, this becomes a command that can be executed at the global level (without specifying global, it would be usable only in the context of the script). The command accepts 1 parameter, being the name of the session.

So in the session, your On Deactivate atom would do something like this:
Uplink pipOnDeactivate "${Session}"

[agitated]

Sweet, thanks )

[agitated]

Lax, I get 'Unknown command' in the session when trying to execute atoms in the uplink. So I went to the uplink console itself and tried to execute the atom with the script running that contains it, and it still couldn't find it.

Any ideas why the uplink would not know about the atom? I have to register it or something first?

The portion in the uplink's script:

Code: Select all

atom(global) handleChat(int ChatType)
{
  echo "Received Chat Relay Request"
}

And the session script bit:

Code: Select all

Uplink handleChat "${ChatType}"

[Lax]

atom behavior in the uplink is the same as sessions, you don't do anything special for the uplink. When it says unknown command, afterward it shows the name of the command you tried to execute -- does it literally say the following?

Code: Select all

Unknown command 'handleChat'

If it says anything else between the first ' and the last ', including stray quotes for example, then the problem probably isnt the atom.

The only thing to be aware of as far as the atom goes is that with atom(global), the script must be running for the atom to be available. As soon as the script stops running, the atom is destroyed. There is the option of atom(globalkeep), but then the atom is logically removed from the script, and cannot directly access the script's resources (variables, functions, etc) -- otherwise it would also have to be destroyed when the script stopped.

[agitated]

Yessir, it says 'Unknown command 'handleChat'' and nothing else.

The atom is defined in a script that runs an infinte while loop to keep it alive.

[agitated]

Disregard. I'm a total hoser and suck. Syntactically complex commenting defeated me.

[Lax]