Ad blocker detected:
Our software and support is 100% free. This website is not.
You can donate in 2 ways, by turning off your ad blocker or by pressing the Donate button.
************ NOTICE ************
UPDATE YOUR BOOKMARKS!!!
We have an issue that there is no way around as of yet.
I have done all I can to try and prevent this from happening.
We are going to be losing the .com, .org and .de domains.
We have not been able to contact the original author of EventGhost
(the person that owns those domains) to redirect them to the new web server.
I set in motion when we first moved a redirection from the old server to the new server.
I also put in markers so that search engines would see this change and update any pointers
they have. We still have the .net domain for the production site. and the .rocks for the test site.
For the past few months you have been getting redirected to the .net site if you used one of the 3
domains mentioned above. I just wanted to tell everyone so they can make any changes needed.
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.
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?
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: