Notice: This forum has been recovered from an old backup, so some content, links, and dates may be outdated. The forum is currently read-only while we restore sign-in and registration functionality. Details
If you find this forum valuable and would like to help keep it online, donations to help cover hosting and domain costs are greatly appreciated, but never expected. You can support the forum through Buy Me a Coffee or Ko-fi. Thank you for helping preserve the EventGhost community.
Bitmonster wrote:But after thinking about it, I'm not sure, if an input data encoding is really needed.
I know that the vast majority of cases it is not useful.
Therefore I also chose the default encoding "unicode internal". But I am convinced that it is not unnecessary. For instance I can receive data from serial port, from another program, etc. Don't forget, that the ordinary people who will not be able to use scripting.
Pako
But if you get wrong chars from the serial port, the serial plugin has to do the input encoding. (This is actually missing in the serial plugin and this is a bug.) If you have a plugin that generates a playlist for example, the strings in the playlist should already be decoded to unicode. If you do otherwise and combine the two, there would be no way to handle it right, because there might be no common encoding.
So actually there is only one way to do it right: every code that receives something from the outside world has to immediately do the decoding to unicode and everything that sends something to the outside world has to do the encoding in the last step.
The longer I think about it, the more convinced I get, that we should drop the idea to give a choice of the input data encoding here.
Please post software-related questions in the forum - PMs will only be answered, if really private, thanks!
Bitmonster wrote:The longer I think about it, the more convinced I get, that we should drop the idea to give a choice of the input data encoding here.
That is true, and I can cancel it.
But consider one more option. I am still not wrote that plugin also provides eg.result. eg.result is the string that I get after decoding. I brought the idea that this plugin may be more universal.
Can also read the data from the specified file.
He should appoint a "Read / write file". What do you think? I got to add this feature?
Pako
I was thinking about it, and came to this conclusion:
Plugin will have two actions (Read and Write).
Action Write will look the way you recommended.
eg.result is the input string after parsing. Is this reasonable?
Layout is as follows:
