ANSI colors

[paccer]

Hi, I would love to see a feature that would allow for colored text in
terminal..
This is already pretty standard in a lot of terminals, and would be a great
addition to Scriptcommunicator

An example could be \u001b[31mHelloWorld" which would print HelloWorld
with red text

I've attached an image of what I have in mind

[image: image.png]

[Stefan Zieker]

Hi,

you can find a script under exampleScripts\WorkerScripts\MainWindowConsole\ANSIColorConsole that adds an ANSI console to ScriptCommunicator.
To print a red text you have to send \u001b[0;31m.
This script is by a user. I don't know why you have to add a ';' . But you can change it easily (line 7 to 15).

[Anonymous]

That's awesome! Thank you so much, I've been googling around, reading docs etc. but the solution was under my nose all this time ;) Thank you for this great piece of software!

[Anonymous]

Did the API change recently? loading up the script, or even just the utf8Console example gives me a console without newlines, proper background color etc. - my suspicion is that readConsoleSetting() / getConsoleSettings() is failing somehow.. I am currently trying to figure my way around debugging and fixing it

[Stefan Zieker]

No I did not change the API for gettings the settings. I testet the utf8Console example and everything works fine.
You can print a variable to the console of the Script Window with scriptThread.appendTextToConsole, then you can see if getConsoleSettings works correct.
By the way which version of ScriptCommunicator are you using (the current version is 5.18)?

[Anonymous]

Thats weird - I am using a relatively freshly installed 5.18, i will try and re-install if the example is working for you.

[Anonymous]

ScriptCommunicator_05_18_windows_no_installer.zip to be exact

[Anonymous]

Fresh install/extract of ScriptCommunicatorSetup_05_18_windows.exe and ScriptCommunicator_05_18_windows_no_installer.zip with fresh config gives the same result.

with my "main" installation i also have a custom background color set in console options, which is not applied in the worker console

I've tried installing in c:\ScriptCommunicator_5.18 to rule out path/permissions being a problem

[Anonymous]

scriptThread.getConsoleSettings() seems to be working,
g_settings = scriptThread.getConsoleSettings(); scriptThread.appendTextToConsole("g_settings: "+JSON.stringify(g_settings));
gives me

g_settings: {"showReceivedData":true,"showSendData":true,"maxChars":200000,"lockScrolling":false,"font":"Consolas","fontSize":"10","updateInterval":25,"receiveColor":"bbbbbb","sendColor":"ff0000","backgroundColor":"000000","timestampColor":"7c0000","newLineAfterBytes":0,"newLineAfterPause":0,"createNewLineAtByte":true,"newLineAtByte":10,"ceateTimestampAtByte":false,"timestampAtByte":10,"generateCyclicTimeStamps":false,"timeStampInterval":100,"timestampFormat":"\nyyyy-MM-dd hh:mm:ss.zzz\n"}

[Anonymous]

I am loading the script by clicking scripts in main window, going to script>add worker script, selecting the ScriptCommunicator_05_18\exampleScripts\WorkerScripts\MainWindowConsole\Utf8Console\utf8Console.js (or ANSIColorConsole), clicking open and then click "start"

I'm on windows 10 (pro, 21h2)

[Stefan Zieker]

mmh, weird. The important part of the script (for new lines) is line 48-59. The only way to find out what happens there is that you debug these lines with scriptThread.appendTextToConsole or with the script debugger.
Sorry, I wish I could help you more.
Can you send me the received data in hex format (HEX console) please?

[Anonymous]

You've helped a lot already ;) I'll dig around some more and see what i can work out...
Here is my hex file

[Anonymous]

Alright, my debugging of the script did not seem to reveal anything strange.
However, I've narrowed it down to being related to the fact that I am getting the data as a TCP client. It does not happen if i receive the data via serial port.
I've tried as TCP client on multiple machines to rule it out being an isolated local problem.
Any ideas on where to look from here?

[Anonymous]

by "it does not happen" I mean that its working as expected, of course ;)

[Anonymous]

@stefan do you have any idea why / where the serial data is treated differently to tcp client data, which might cause this?

[Anonymous]

sorry, wrong stefan - @szieke

[Anonymous]

The data is treated independently from the source (except CAN). Can you connect two instances of ScriptCommunicator via TCP, send the data and see what happens?

[paccer]

I'm running out of options here, this is not making any sense.
Receiving the exact same input in either Serial or TCP client mode yields different results. (which should not happen according to you, since data is treated independently)

Either I am missing something or there is a bug lingering somewhere.
The problem can be reproduced (on multiple computers) by running both client / server as you suggest and pasting the hex in the server and sending it - it also happens in UDP mode. (but again, does not happen with a serial device)

I'm very much open to any ideas you might have.

I've attached 3 screenshots showing my findings plus a txt file with the hex.

[Stefan Zieker]

I will try to reproduce it on my PC tomorrow. Thx for you help.

[paccer]

And thank you! I will keep an eye on this thread ;)

[paccer]

Ok, it looks like I actually got it working now by changing line 57 in utf8console.js and line 70 in ANSIColorConsole.js
From:
stringToAdd = stringToAdd.replace(newLineAtByte, "<br>" + newLineAtByte)
To:
stringToAdd = stringToAdd.replace(/(?:\r\n|\r|\n)/g, '<br>' + newLineAtByte);

I'm still a little confused as to why this actually worked and why I was getting the results and conclusions that I was from my debugging, but I have a feeling its related to the fact that the console is trying to render the output. (even though i was doing my best of escaping the output)

I also have a suspicion that the hex console is perhaps not outputting \r as hex but rendering it instead? could maybe explain the differences I was experiencing between sources perhaps (looking identical but giving different results, as seen in screenshots above) - I'm not entirely sure..

Yeah, I'm still a bit confused about the whole ordeal but it works now for me... Might be worth making a few changes to the scripts though..
My solution works, but I don't know if its ideal for distribution in this way or not, I'm having trouble thinking through all the possible scenarios. (i THINK it should be fine?)

I hope I didn't take too much of your time with this...
Thank you very much for your valuable input! And again, for this great piece of software!
I can't wait to get on with my project, and getting the colored debug output via UDP that i was hoping for ;) (= no more reconnecting to my devices)

[Stefan Zieker]

I know the reason for this weird behavior. Because of the low serial port data rate the received bytes are delivered in several chunks to the script (several calls to dataReceivedSlot). In case of a socket the bytes a delivered in one chunk.
stringToAdd.replace(newLineAtByte, "<br>" + newLineAtByte) replaces only the first occurrence of the new line byte. In case of the serial port this works because the new line bytes are in different chunks, in case of a socket the new line bytes are in one chunk and therefore only the first new line byte is replaced.
Your solution replaces every occurrence of \r\n,\r and \n. A better solution would be:
stringToAdd = stringToAdd.replace(RegExp(newLineAtByte, 'g'), "<br>" + newLineAtByte)
This replaces every occurance of newLineAtByte.

PS: Don't forget to replace stringToAdd = stringToAdd.replace(newLineAtByte, ""); with stringToAdd = stringToAdd.replace(RegExp(newLineAtByte, 'g'), "").

[paccer]

Ahhh gotcha ;) that makes a lot of sense - i guess i must have misunderstood your "The data is treated independently"-reply or just jumped to conclusions - i was under the impression that the script was presented with the exact same input.. Either way, i am just happy we got to the bottom of this ;)