This App is No Longer Maintained. Visit the Replacement at StrokesPlus.net

StrokesPlus Forum
                       
StrokesPlus Forum
Home | Profile | Active Topics
Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 Feature Updates
 Existing Features
 [CHANGED] Action Threading
 Forum Locked
 Printer Friendly
Author Previous Topic Topic Next Topic  

Rob

USA
2615 Posts

Posted - 07/08/2012 :  08:40:00  Show Profile  Visit Rob's Homepage
Changed in 2.1.8:

Created an additional Lua state (total 2) and prevent more than 2 actions from firing concurrently. This is a compromise to allow some level of multi-threading, but preventing S+ crashes when actions were tripping over each other. This was only noticable when firing two actions back-to-back which had calls to acDelay (for the most part) leaving the Lua state unstable if another action fired in the same state, which caused S+ to crash. Now, only two actions can fire simultaneously, each with their own state. However, since these are separate states, they won't share the same values assigned to variables. For example, if you define a global variable named MyGlobalVar in the Global Lua tab and set it to 123, it will be 123 for each state initially, but if you fire an action which sets MyGlobalVar to 321 within a script that is still running while you execute another action which sets MyGlobalVar to 456, in Lua state 1, MyGlobalVar will be 321, but in Lua state 2 it will be 456. Lua state 1 is always the primary state used for actions, state 2 is only used if state 1 is currently executing a script. For the most part, no one will likely be affected by this change, and those who are will likely understand this contention and the necessity for it. Again, it's a compromise to keep some level of functionality prior to this change, even though it often led to crashes.

If a gesture is completed and state 1 and state 2 are both executing, the gesture will be discarded; if you have Play Sound For No Match checked and a WAV file selected, it will be played when this condition occurs to let you know it was ignored.

Rob

USA
2615 Posts

Posted - 07/08/2012 :  08:43:05  Show Profile  Visit Rob's Homepage
Note that if you have Fire Recognition on Mouse Wheel Scroll enabled, subsequent actions which execute from wheel scrolls (all while the stroke button is still down) are only fired when the previous wheel scroll action is complete. This isn't a change in 2.1.8, it's always been that way due to internal reasons, as that functionality was added later and plugged into the existing code so it has to work a little differently.
Go to Top of Page
  Previous Topic Topic Next Topic  
 Forum Locked
 Printer Friendly
Jump To:
StrokesPlus Forum © 2011-2018 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000