* Check Installed Plugins Against The Store Downloads

[tatewise]

A user of one of my Plugins has just reported a problem, which on investigation appears to arise in the Check Installed Plugins Against The Store Plugin.

When an updated Plugin is detected and downloaded, every line has the Carriage Return character code 13 appended.

I have repeated this several times with different Plugins:
Both Ancestral Sources Data Entry and Change Any Fact Tag
But if they are downloaded directly from the FH Plugin Store there is no problem.

If Check Installed Plugins Against The Store line 124 has the following line inserted after it, the problem is fixed.

Code: Select all

        data = data:gsub(string.char(13),"")  -- Remove CR characters

[tatewise]

Thank you Jane for updating the Plugin so quickly, but overnight I have realised that the change would remove any genuine CR, such as in my encoder library used for HTML XHTML XML URI UTF8 ISO CP1252 character encodings.
Thus the following line would be better and clearer:

Code: Select all

        data = data:gsub("\r\n","\n")  -- Remove CR characters at end of line

Sorry!

[Jane]

I have got Calico to release the newer one, can you double check it with any you are worried about.

Thanks

[tatewise]

I have checked the original Plugin, the interim Plugin, and the latest Plugin.

The original Plugin consistently uses Carr.Ret. (code 13) and New Line (code 10) characters at the end of every line.
I have searched the WinHttpRequest online documentation for Properties such as ResponseBody and ResponseText and Option but nothing explains or adjusts that feature, except that CRLF is a common line delimiter.

Both the interim Plugin, and the latest Plugin behave perfectly correctly, and in fact neither upset the code I was concerned about. But I still think the latest version is a cleaner solution.
In hindsight I realise that in Plugins there never are any Carr.Ret. (code 13) characters, only pairs of ANSI characters \ & r - doh!

Do you recall the Plugin Discussion last October about Possible enhancement for Search and Replace (6069) in which extra CR at end of lines was a mysterious problem?
Well, I think the cause has now been discovered and fixed

As we discovered then, downloading directly from the Plugin Store does not suffer the problem.
It is only the WinHttpRequest ResponseBody that inserts the CR.

I have added a note to plugins:code_snippets:read_direct_from_web_page|> Read Direct From Web Page (code snippet).