window management

[Simon]

Hi Greg,
I think I understand, but why don't you just rebuild the standalones with a new name (not rename)?

Simon

[adventuresofgreg]

Hi Simon:

I could name each standalone build with it's own unique name, but then I have tons of script references to the "main name" which would all have to change - in each case. The way it works now is very convenient because I just make a dozen duplicates of the same standalone app, and re-name each app in Windows. Then when that copy of the SA is launched, it looks at it's name on openstack, and then locates it's unique datafile which is linked to the app name. This way, each SA will run as it's own unique app, and the task of importing (or opening) a unique data file for each copy is automated by the app name changes.

Your script would work if there was someway to reference the "Process name" rather than the app name.

Here is a screen shot of a single copy of my app "G59" running. I have 16 copies running at the same time. Each is connected to a live data server.

[jacque]

Hi Simon:

I could name each standalone build with it's own unique name, but then I have tons of script references to the "main name" which would all have to change - in each case.

I use a function rather than hard-code stack names:

function main
return the short name of the mainstack of this stack
end main

If the script references "stack main()" instead of an actual name, it doesn't matter what the stack is called.

[adventuresofgreg]

So far, the only way I've found to my my "switcher" work is to use a macro program called "autohotkey", and create key activated macros that bring various window to the forefront. Then, I have a LC control panel that fires out the key codes to activate the macro to bring various windows to the front. My problem now, is that when using script :

type "n" with controlkey,controlkey

nothing happens. My typing script does not seem like it is being passed through to windows. The key commands when actually typed on the keyboard work, but when simmulated via a LC script, they don't. I can get it to work by compiling the macros into self running .exe's, and then LAUNCHING each macro .exe from my LC script, but this is all getting pretty complicated just to control window stacking in Windows. Any ideas as to what my script issue is?

Thanks,
Greg

[jacque]

I don't think the "type" command communicates with the OS at all, it just puts text into a field and sends related keystroke messages through the LiveCode message hierarchy. The OS doesn't know any typing has happened.

[FourthWorld]

I probably just missed something basic early on here, but why do these need to be standalones? Seems like a lot of work (and system resources) to have all those stacks using separate copies of the same engine.

[adventuresofgreg]

HI Richard:

Yes, i have been thinking about the pros and cons of creating multiple instances in a single stack. The con is that this main stack consists of 10 sub stacks that refer to each other. If I were to create a copy of the entire main stack (and all of it's related sub stacks), then how would each of the sub stacks refer to each other? And How would I manage all of my Global variables without getting them mixed up between different instances of the main copies? Also - I'm not sure that I can create a copy of my main stack (+ all of it's subs) from within a standalone.

Greg

[FourthWorld]

Because a stack's name is separate from its title, you can refer to it in script by name without affecting what the user sees. So "stack1", "stack2", or whatever other naming scheme you like would work.

Once you decide on a naming scheme, use arrays for your global vars, separating out their values by that name, e.g.:

gMyArray["stack1"]["someProperty"]

[Simon]

Not sure if this helps, but don't forget "this" keyword.
set the filename of image 1 of this stack to...

Simon

[adventuresofgreg]

It's time that I re-visit this multiple instance issue, and I'm just trying to think of a logical way to manage this. So rather than opening multiple instances of the same standalone LC app, I am trying to think of a way to run all of these 'instances' in the SAME stack.

This would be basically done by duplicating the card - easy enough. However, i make extensive use of handlers and globals. These handlers and globals would get mixed up between the different cards. I could partly resolve the issue by moving the handlers for each card over to the card script (from the stack script where they are now), however, the handlers all use global variables and the global names would be the same between the different cards.

This multiple card solution would work if there was a way to declare a global that was only global throughout the CARD, and not the ENTIRE STACK.

Any ideas?

Thanks!
Greg K

[sturgis]

YOu can either use a local to the card script and have any object interactions be bare minimum scripts that use the handlers on the card. Since all handlers in a card can use the script local (if declared at the top of the card script outside any handlers) then that should solve one issue. Another option would be to use properties. Then you could get and set information like "set the whateverproperty of this card to..." method or "get the whateverproperty of this card" ..

Properties are a little slower than variables but work well.

[adventuresofgreg]

ahh - so local declared as locals (rather than globals) at the start of a script outside of any handler can be used as a sort of card-local global???? I did not know that.. Thanks!

YOu can either use a local to the card script and have any object interactions be bare minimum scripts that use the handlers on the card. Since all handlers in a card can use the script local (if declared at the top of the card script outside any handlers) then that should solve one issue. Another option would be to use properties. Then you could get and set information like "set the whateverproperty of this card to..." method or "get the whateverproperty of this card" ..

Properties are a little slower than variables but work well.

[adventuresofgreg]

one possible snag: If my Card script is doing stuff to fields and polygons graphics on the card, I can refer to "this" card - which works, but as soon as I change cards, the previous card script gets lost, as it does not know what "This" card is anymore. ?? It is important that each card in the stack continue to function and run even when that card isn't the currently viewed card.

[sturgis]

Hard to say for sure exactly how to solve your problem without seeing some code, but.. you could use the long id of the card as a reference instead maybe? Though seems like when the code fires off, the "This" reference should work. If the script is on the card, then "This" -should- refer to the containing card. Can you post some code, and/or an example stack that demonstrates the problem?

Someone correct me if i'm wrong.

[adventuresofgreg]

Hard to say for sure exactly how to solve your problem without seeing some code, but.. you could use the long id of the card as a reference instead maybe? Though seems like when the code fires off, the "This" reference should work. If the script is on the card, then "This" -should- refer to the containing card. Can you post some code, and/or an example stack that demonstrates the problem?

Someone correct me if i'm wrong.

As a test, I made a script that added 1 to x and wrote it out to a field on a card. As soon as I changed cards, I got an error that LC could not find my the button on "this" card.

Card script:
local x
on turnon
if the hilite of button "turnon" on this card is true then
if x is empty then put 1 into x
put x+ 1 into x
put x into field "turnonfield" on this card
send turnon to me in 5 seconds
end if
end turnon