Author |
Topic |
|
Hax
128 Posts |
Posted - 07/07/2012 : 15:40:39
|
If you repeat (many times and quite fast) an action with this script, S+ will crash. Decreasing the acDelay value to 100 seems to be a workaround for this issue, but I need the delay at 800 because I want to have a blinking text and this high value does the trick (100 does not). Is there another way to achieve the blinking text?
acDisplayText("II", "Arial", 42, 250, 250, 250, 455, 955, 1180)
acDelay("800")
acDisplayText("II", "Arial", 42, 250, 250, 250, 455, 955, 1180) |
|
Rob
USA
2615 Posts |
|
Hax
128 Posts |
Posted - 07/07/2012 : 16:11:41
|
I forgot something else. There is a bug that prevents acDisplayText to show the text on top after some period of time. |
|
|
Rob
USA
2615 Posts |
Posted - 07/07/2012 : 17:56:52
|
Man, this is really a much larger issue involving multi-threading.
I may have to disallow actions from firing concurrently, which generally isn't noticable, but would be for scripts with longer acDelay calls as a new gesture would not be able to be drawn until the previous Lua script has completed.
I'm trying to see if I can find a graceful and efficient way around it, but the biggest problem is the Lua state. I can create new Lua states, but that would introduce a huge overhead to every gesture drawn as it would have to create the state, open the libs, load alien, load core, bind all of the action functions to the new state, load the Global Lua, then execute the action script. Plus, it would eat up more memory as they would linger around until Lua GC came along and deallocated things.
I would really hate for it to come to this, but stability has to be the first priority. It's not a final decision yet, but I don't want to start making things sloppy.
And just so you know, it's not limited to acDisplayText; I have a script that plays Mary Had a Little Lamb (you may have seen on the forum), firing that multiple times in parallel causes S+ to crash as well since running the scripts in parallel mucks up the state/stack/thread or whatever it is at the heart of the problem.
The only other possibility is having 2 or 3 Lua states, and if state 1 is firing an action, send the next action to state 2. That's what I'm going to try and test out first, but I'm uncertain of the feasibility at this point in time. |
|
|
Rob
USA
2615 Posts |
Posted - 07/07/2012 : 18:47:12
|
Try this and let me know how it works for you. Try to test out a lot of different things due to the nature of the change.
Pending Change Log Notes:
2.1.8 - Added acSetKeyboardHook(0 or 1) to turn the keyboard hook on (1) or off (0)..this is only for troubleshooting scripts so you can use the keyboard if S+ crashes to close the program - 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.
http://www.strokesplus.com/files/StrokesPlus_2.1.8_x64_chg.zip |
|
|
Hax
128 Posts |
Posted - 07/08/2012 : 00:17:01
|
The link doesn't work:
Server Error
404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable. |
|
|
Rob
USA
2615 Posts |
Posted - 07/08/2012 : 00:21:20
|
Bah, that was before I switched to the new web server and didn't upload that file in the move. There now. |
|
|
Hax
128 Posts |
Posted - 07/08/2012 : 01:12:47
|
The 2.1.8 looks good. I haven't gotten any crashes so far. No issues with the different things as well. I don't know if that "on top" issue still exists or not because it takes some time to reproduce it. |
|
|
Rob
USA
2615 Posts |
Posted - 07/08/2012 : 01:19:41
|
I imagine it may still be a possibility, due to the nature to what the acDisplayText call does behind the scenes and the potential race condition present in having two actions threads running in parallel.
Though it could be some other odd execution path/circumstance causing it too..guess we'll see =) |
|
|
Hax
128 Posts |
Posted - 07/09/2012 : 13:26:26
|
The acDisplayText still tends to hide the displayed text under windows. I've also noticed that it doesn't support non-english characters. |
|
|
Rob
USA
2615 Posts |
Posted - 07/09/2012 : 13:37:28
|
It wouldn't support non-English for the same reasons that parts of the interface do not. S+ is not compiled with Unicode enabled, so the string copy functions are ANSI only, which will ignore complex characters.
I've started making the code generic in the sense that I can toggle between Unicode and ANSI and attempt to compile without having two copies of S+, but still running into issues.
Any luck in identifying a pattern which leads to the text window not being on top? Does it simply fall behind all windows at some point and stay behind? Something else? |
|
|
Rob
USA
2615 Posts |
|
Rob
USA
2615 Posts |
Posted - 07/09/2012 : 19:57:40
|
BTW, I'm finally biting the bullet and replacing ALL of the Boost ptree code with pugixml as it has less overhead and is Unicode compatible. This should fix the language encoding stuff, but is going to be a big change as virtually every section of code is being touched; if not for the ptree change to pugixml, then because of the switch to compiling as Unicode.
Gonna take a while and will definitely be a longer Beta testing run whenever it's complete, but I can't stand this Unicode issue any longer. |
|
|
Hax
128 Posts |
Posted - 07/09/2012 : 21:10:11
|
quote: Originally posted by Rob
S+ is not compiled with Unicode enabled, so the string copy functions are ANSI only, which will ignore complex characters.
What about the ANSI code pages? An option (in Language.xml) to switch to the Windows-1250 is all I need.
quote: Originally posted by Rob
Does it simply fall behind all windows at some point and stay behind?
Yes, it does. It seems to be totally random.
I will try the 2.2.0. |
|
|
Rob
USA
2615 Posts |
Posted - 07/09/2012 : 21:26:24
|
I looked into that a little bit, but it's just driving me nuts that it's not Unicode! Probably won't take me too long, made a couple functions tonight to duplicate the default value that boost had and converted the exe (reduced size by 70k, which is nice)..though there's not much in there. I'm sure I'll have something by the week's end to test. |
|
|
Rob
USA
2615 Posts |
Posted - 07/11/2012 : 16:50:47
|
I think I'm going to have to further investigate the locale/code page option as there are just too many little oddities with this conversion. At least this time I am able to compile, but there are things that just don't work automatically without adding extra steps, and even then there are a couple weird things happening.
Things mostly work as they are, just need to figure out how to correct the code page and it should be fine. |
|
|
Rob
USA
2615 Posts |
|
Rob
USA
2615 Posts |
|
Hax
128 Posts |
Posted - 07/12/2012 : 04:49:52
|
Version A:
One random crash after doing action with acDisplayText (without acDelay). However, keeping displayed message on top works good.
Version B:
C Polish_Poland.1250 Polish_Poland.1250 C Polish_Poland.1250 Polish_Poland.1250
Version C:
Error messages after launching scripts:
[string "ActionScript"]:4:unexpected symbol near char (160) |
|
|
Rob
USA
2615 Posts |
Posted - 07/12/2012 : 07:02:58
|
In B or C, was there anything different in the UI, like the encoding of modifier text in Reports? I think that was one of the places that is showed up way back, maybe the scroll up or scroll down didn't display correctly. |
|
|
Hax
128 Posts |
Posted - 07/12/2012 : 07:47:42
|
There wasn't anything different. But...
Do those testing versions have that new XML parser? All the Polish chars are broken when Language.xml (these chars are fine in the file) is encoded in UTF-8. ANSI is OK. |
|
|
Rob
USA
2615 Posts |
Posted - 07/12/2012 : 07:57:58
|
No, I archived that whole copy of S+ code. I'm going to temporarily stop pursuing this language/encoding issue. I really have no experience in this area and will have to revisit again.
Plus, and no offense, it simply doesn't affect me so it's difficult for me to spend too much time on it. I hate saying that, but it's true..although it's also that I really have no idea what else to do.
I may simply have to make a copy of the code and strip out everything but the UI/XML parsing stuff and post it for someone else to figure it out for me! |
|
|
Rob
USA
2615 Posts |
Posted - 07/12/2012 : 09:52:57
|
Just FYI, the release of 2.2.0 in downloads doesn't include any of the encoding stuff nor address the random crash, but does include the fix which seemed to keep it on top (hopefully). |
|
|
Rob
USA
2615 Posts |
|
Hax
128 Posts |
Posted - 07/13/2012 : 03:01:10
|
Nope, the acDisplayText still doesn't display the Polish characters properly.
The issue that really bothers me is that "on top" thing which is probably fixed by now. So, I just want to let you know that I can live with those broken characters because I may just use the Basic Latin characters instead or use different words. In addition, I appreciate your effort, thanks! |
|
|
sixtyone
2 Posts |
Posted - 07/14/2012 : 05:26:20
|
I am chinese,and my english level is poor.I like s+ very much,However I feel "acDisplayText£¨£©" not work like strokeit,expecting you to improve it. Besides,S+ can not send anykey down(for example send {app down}) . Hope it the development, the better! |
|
|
Rob
USA
2615 Posts |
Posted - 07/14/2012 : 13:02:30
|
In what way does it not work? With Chinese characters? Or something else?
Which key is app down? |
|
|
sixtyone
2 Posts |
Posted - 07/15/2012 : 08:57:34
|
So sorry.Maybe I can't accurately express my meaning.For example,"acDisplayText("check", "Arial", 25, 0, 0, 0, 5000,
665, 5)" while carrying out the action, it will wait for five seconds, then can carry out any other action("acDisplayText
("question", "Arial", 25, 0, 0, 0, 5000, 665, 5)") {APPS} = VK_APPS It can send ctrl+c ,but don't send APPS+C |
|
|
Rob
USA
2615 Posts |
Posted - 07/15/2012 : 09:41:52
|
Correct, acDisplayText currently waits for the duration to expire before continuing; although I'm working to change that.
Yes, APPS is not currently considered a acSendKeys modifier key, so you would need to send the down and up events directly:acPostMessage(acGetForegroundWindow(), 0x100, 0x0000005D, 0x015D0001)
acDelay(25)
acSendKeys("c")
acDelay(25)
acPostMessage(acGetForegroundWindow(), 0x101, 0x0000005D, 0xC15D0001) You may need to use acGetWindowByPoint, acGetParentWindowByPoint, or acGetOwnerWindowByPoint (instead of acGetForegroundWindow()) depending on the application, but it will work once the proper window receives the message. |
|
|
|
Topic |
|
|
|