 |
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
 Posted: Sun Jan 05, 2014 2:09 am
PSUB madness
|
All right, here's an obscure one for you.
First, run this prep code:
| Code: |
#clr testing
#win testing "foo"
#win testing "bar" |
That should open a window with this text:
Next, run this code off the command line:
| Code: |
| :testing:#psub "q" 1 1 2 2 |
The text in the window should change to this:
That, I believe, is expected behavior. Run the prep code again to reset the window.
Next, create this event and this trigger:
| Code: |
#event testevent {:testing:#psub "q" 1 1 2 2}
#trigger {^test$} {#raise testevent} |
Finally, fire the trigger:
This will fire the trigger, which raises the event that contains the exact same psub code that worked fine on the command line, but now the text of the window changes to this:
Am I doing something wrong? Assuming I'm not and this is a bug, is there a workaround?
Edit: did some further testing and it seems like the problem lies just with the trigger. A standalone alias or event works fine, as does calling the alias from the event, etc. A standalone trigger does not work, neither does any code (event, alias, etc.) called from the trigger. |
|
|
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Mon Jan 06, 2014 9:15 pm
|
So, unable to find a workaround, I replaced the #psub's with ansi cursor control codes to write to the window at the specific spots I want. Unfortunately, this has come with its own problems, namely colors. Unlike with psub, colors are not handled automatically so I need to write them back into the window every time. After a while of doing this, they'll seemingly randomly get, for lack of a better word, "corrupted". It looks like a weird sort of color bleed; the text is displaying in colors that have no business being there. Unfortunately I haven't found a simple test case to reliably reproduce this yet, but regardless, has anyone experienced this? More importantly, does anyone have a reliable way to write to a child window at an arbitrary position while maintaining color integrity?
|
|
|
|
|
rozdwojeniejazni
Wanderer
Joined: 13 Aug 2011
Posts: 74
|
Posted: Thu Jan 09, 2014 5:56 pm
|
Hi Daern :)
Posting bug reporst? Who cares? Cmud has bugs, we all know it. A lot of them concern subs and colors. But Cmud is also dead for years. :( |
|
|
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Thu Jan 09, 2014 7:26 pm
|
I'm not posting a bug report, I'm asking if anyone knows a workaround. I'm well aware that it won't be fixed.
|
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4718
Location: Pensacola, FL, USA
|
Posted: Thu Jan 09, 2014 7:30 pm
|
have you tried pushing the code into a #THREAD? or #EXEC ing it?
|
|
_________________
Discord: Shalimarwildcat |
 |
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Thu Jan 09, 2014 8:20 pm
|
Good call! Running it in a separate thread works, thanks shalimar :)
|
|
|
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Thu Jan 09, 2014 8:40 pm
|
Never mind, I spoke too soon. It does work fine in my simplified test case:
| Code: |
#trigger {^test$} {#thread "test" {:testing:#psub "q" 1 1 2 2}}
#clr testing
#win testing "foo"
#win testing "bar"
#show "test" |
This will correctly change the contents of the window to:
However, in my real script, this code is being run in a loop:
| Code: |
#trigger {^test$} {#loop 2,2 {#thread "test" {:testing:#psub "q" 1 1 %i %i}}}
#clr testing
#win testing "foo"
#win testing "bar"
#show "test" |
Note that the only thing that changes here is that the literal twos in the #psub have been changed to the loop index (which will be two as well), but that's enough to break it. The window now changes to:
Any ideas?
Edit: I also tried concatenating together a string and executing it, and that didn't work either, which is even more confusing.
| Code: |
// This works:
#loop 2,2 {#thread "test" {:testing:#exec %concat("#psub ""q"" 1 1 2 2")}}
// This doesn't:
#loop 2,2 {#thread "test" {:testing:#exec %concat("#psub ""q"" 1 1 ", %i, " ", %i)}} |
The exact same string is getting executed in both cases...
Edit 2: I also tried moving the loop body out of the trigger and into an alias. This is perhaps the most confusing of all, because nothing happens, even with literals in the psub (the window content doesn't change).
| Code: |
#trigger {^test$} {#loop 2,2 {test %i}}
#alias test {#thread "test" {:testing:#psub "q" 1 1 2 2}} |
|
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4718
Location: Pensacola, FL, USA
|
Posted: Thu Jan 09, 2014 9:55 pm
|
would #EXECWIN work?
|
|
_________________
Discord: Shalimarwildcat |
|
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Thu Jan 09, 2014 10:42 pm
|
Again, works fine with literals, not with %i. There's no difference between #execwin and :windowname:, as far I know - the documentation for #execwin says so too.
|
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4718
Location: Pensacola, FL, USA
|
Posted: Thu Jan 09, 2014 10:51 pm
|
Is there a reason that you need to run it through a loop that i am missing?
|
|
_________________
Discord: Shalimarwildcat |
|
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Fri Jan 10, 2014 2:27 am
|
Well, this is just an extremely simplified example to demonstrate the issue. In my actual code, the loop is quite important, yes.
|
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4718
Location: Pensacola, FL, USA
|
Posted: Fri Jan 10, 2014 4:26 am
|
have you tried assigning the values to $localVars and using those?
or just enclosing the exec in brackets? |
|
_________________
Discord: Shalimarwildcat |
|
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Fri Jan 10, 2014 7:13 pm
|
Aha! A local variable didn't work, but a normal variable does, as long as it's set outside the thread. Back in business, for now...
|
|
|
|
|
Daern
Sorcerer
Joined: 15 Apr 2011
Posts: 809
|
Posted: Fri Jan 10, 2014 10:58 pm
|
Wow, I was barking up the wrong tree the whole time. It was all just a question of scope. I was using several local variables throughout, both in the replacements and the position indexes. Changing them all to absolutely pathed variables (so they can be referenced from the other window) seems to have fixed it. The thread is still required for some reason, or else it just throws everything on the bottom line, but I won't question that. Thanks for the suggestions :)
|
|
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4718
Location: Pensacola, FL, USA
|
Posted: Fri Jan 10, 2014 11:33 pm
|
no problem
|
|
_________________
Discord: Shalimarwildcat |
|
|
|
|
|
|
