StrokesPlus Forum
StrokesPlus Forum
Home | Profile | Register | Active Topics
Members | Search | FAQ
 All Forums
 Bug and Issues
 Closed or Unreproducable Bugs
 [ACCEPTABLE] Some bug & acDisplayText

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List

* Forum Code is ON
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

Check here to subscribe to this topic.

T O P I C    R E V I E W
Hax 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)
acDisplayText("II", "Arial", 42, 250, 250, 250, 455, 955, 1180)
28   L A T E S T    R E P L I E S    (Newest First)
Rob 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)
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.
sixtyone 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 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 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!
Hax 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!
Rob Posted - 07/12/2012 : 13:51:05
See if this does anything (only loads the language file into boost with the Polish locale and sets the C locale to Polish, main config file not loaded any differently):

It expects that a language file exists.
Rob 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 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!
Hax 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 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 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:


Version C:

Error messages after launching scripts:

[string "ActionScript"]:4:unexpected symbol near char (160)
Rob Posted - 07/11/2012 : 18:50:53
Try this, too:

No message boxes, but sets the C and global locale.
Rob Posted - 07/11/2012 : 18:26:03
Run this, you'll get 6 message boxes when you start, let me know what they say, and in what order. And also let me know if by some magic it does anything.
Rob 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 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.
Hax Posted - 07/09/2012 : 21:10:11
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.

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 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.
Rob Posted - 07/09/2012 : 14:41:42
Try this and see if it still happens. It doesn't change anything other than adding a call to SetWindowPos sending HWND_TOPMOST on each call to acDisplayText.
Rob 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?
Hax 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 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 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 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 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 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:

- 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.
Rob 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.
Hax 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 Posted - 07/07/2012 : 15:43:38
That's related to this:

I'll have to try digging deeper to see if I can find a proper solution to this quite annoying bug.

StrokesPlus Forum © 2011-2018 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000