Leaderboard

The code will not work as intended. Streams store bytes, not characters, and the size of a character is 2 bytes in Unicode-enabled Delphi versions. To calculate the number of bytes to write you have to use strmSize := Length(s) * Sizeof(char); TStream.Read and TStream.Write are also somewhat deceptive and excellent traps for beginners . They use untyped parameters and those do not work as you obviously expect from your code snippets. The compiler passes the address of the variable s to the method, not its content. So your strm.Write statement writes strmsize bytes starting from the address of s, but since strings in Delphi are reference types that address only holds a pointer pointing at the actual content of the string. You have to use strm.Write(s[1], strmSize); to write the content of the string. Reading it back has to follow the same pattern, and you have to position the stream to the start first and make sure the string you read into has enough memory allocated. Assuming the stream contains only the one string you have written into it this would look like this. I use a local string variable here to make things clearer, globals just confuse things: procedure TForm1.btnStrmToStringClick(Sender: TObject); // load/read into a tedit control var LTarget: string; begin strm.Position := 0; SetLength(LTarget, strm.Size div sizeof(char)) strm.Read(LTarget[1], Length(LTarget)* sizeof(char)); eb2.Text := LTarget; end; Things get more complex if you want to store more than one string into the same stream. In such a case it is advisable to store the length of a string (as integer) before the string content, so you can read the length first to figure out how to size the target string and how many bytes to read into it. Delphi has useful helper classes like TStringReader and TStringWriter to make such stuff easier. And if you only have to handle text you can put it into a TStringlist and use the list's SaveToStream and LoadFromStream methods to avoid all the hassle completely.

We have just released an open-source Delphi implementation for a HTML-based cross-platform application help system. Information page: Ziphelp - an open cross-platform help format Direct download link: https://www.helpandmanual.com/download/delphi-ziphelp-demo-source.zip About Ziphelp On the surface, Ziphelp is basically HTML in a compressed zip archive, hence the name. Pack any folder with HTML files into a zip archive and you are good to go. But Ziphelp is more than that, it is a protocol based on the standard sitemap protocol, designed to give a help viewer (here: the Delphi implementation) extended information about the content of the help system. That is help context numbers, help keywords, associative keywords, page titles. This information is missing in a standard sitemap.xml. Ziphelp extends the sitemap protocol and enables direct communication of an app with the help system. The Ziphelp protocol is not just for zip archives. It works inside an archive, with uncompressed folders or with HTML content loaded directly from a website. A Delphi desktop app may be deployed with local application help, uncompressed, zipped or embedded. A mobile or web application might not ship with local HTML content, but refer to an online version instead. The mechanism is the same in both cases and the TZiphelp component implements this for Delphi. Demo Application A demo app for VCL and FMX (Win/MacOS) is included. The demo builds on standard Delphi components (TWebBrowser) to display the help system.

ICS will now build again with the OpenSSL DLLs. Angus

Yes, per the EULA: The EULA explains several restrictions on the Community Edition, but this is not one of them.

Strictly speaking assuming a specific order in a for-in loop is wrong to begin with.