Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5182

First just look at the screen shot then I will explain what was done to make it.

The first step was to enter '#WINDOW abc;#ALL {#THREAD};:abc:#THREAD' at the command line.
Next was '#ALL {#THREAD}'
Then I turned on the command line for the 'abc' window and entered '#ALL {#THREAD}' there.

From the output we see that the entire contents of each command line entry is contexted to the window that sourced it. When using the #ALL command it would make more sense for there to be multiple threads, one in each window. The window that issued the #ALL would have 2 threads by the time it executed the command, and each other window would have thier own thread for the contents of what the #ALL is preforming. In the screen shot you can see the last entry for the 'abc' window; the stopped thread is presumably the last command completed from the 'untitled' window not having to do with the current #ALL.

Similarly the focus character should causes its commands to be in the context of the target window. The second #THREAD display in the 'abc' window should have only shown a #THREAD command owned by the 'abc' window.

I started thinking down testing this path based on Thinjon's problem with a stopped trigger and multiple windows. Once I saw the results I thought about some of the old posts regarding variables being created in the wrong place due to activities in secondary windows. I believe at least one mention in those posts was about an alarm, all of which seem to be run from the main thread.

Something in here may be the source of the context issues a few people have had in recent betas.

Posted: Sat Sep 29, 2007 1:36 am

To look for context issues, you really need to create variables with the same name in each window and then investigate their contents. Using #THREAD doesn't really show this. #THREAD is showing a global thread list which is common to all Windows.

The fact that #ALL does *not* create multiple threads is done on purpose. In fact, I go out of my way in CMUD to try and maintain past operation where scripts are executed sequentially and *not* in parallel. I'm trying to minimize the cases where people need to worry about thread locking and thread synchronization. So it's only when you use a #WAIT variable that you end up with multiple threads running at the same time.

So, the normal operation of #ALL is to loop though each window sequentially and wait for the command to finish executing in each window. This is done from the main thread because only the main thread can directly access the user interface (other threads have to "synchronize" access of the UI with the main thread).

Anyway, the main issue here is that #THREAD doesn't just show the threads owned by the window. It always shows the entire global list of threads, no matter what window you run it from.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I thought I would put this concept to the test. I entered this at the command line from a blank session

Wizard Joined: 14 Aug 2004 Posts: 1269

What trigger pattern to the windows get?