Remy Lebeau

You should file a bug report about that. Embarcadero spend a lot of effort revamping the MDI system in 12.0.

It is true that variables can't be initialized when using the 'var' block at the top of the function. But inline variables can be initialized: begin var foo: Integer := 10; // OK

Does it have to be Win10 specifically? Or is Win8 enough? The ability to use the WS_EX_LAYERED style on child windows was added in Win8.

Or, simply run each build in a separate cmd.exe instance so they each have their own environment. Changes made to the environment variables are local to each instance, not saved globally or across instances.

They stopped publishing roadmaps publicly, there hasn't been a new roadmap shown for several years now.

Have you read the documentation yet? https://docwiki.embarcadero.com/RADStudio/en/MSBuild https://docwiki.embarcadero.com/RADStudio/en/Building_a_Project_Using_an_MSBuild_Command

Do you have the same problem if you use MSBuild instead of invoking the compilers directly? Building a Project Using an MSBuild Command

You have that backwards. It doesn't. Libs that are shipped with the IDE are separated, but user-provided libs are not. So either separate them yourself, or don't have them both installed at the same time.

That won't work. SetPairs() expects a list, not a Set or an array. You would need to use this instead: JsonObject.SetPairs(TList<TJSONPair>.Create); This is because SetPairs() takes ownership of the new list, freeing the old list. The list can't be nil or else you risk crashes on future operations on the TJsonObject.

The "crew" is me. Since Indy 11 has been pending for a very long time, I've been considering lately about updating Indy 10 just to bring it more inline with Embarcadero's releases (ie, adding LIBSUFFIX, etc) sooner rather than later. Dropping older compilers, etc will still wait for Indy 11 for now.

The OpenSSL code that is currently in the main library is being pulled out completely into its own separate package that uses the main library. This way, future updates to OpenSSL are more isolated and can be worked on and committed independently outside of the main library. Yes, that is the plan. I've already asked Embarcadero for details about the changes they make to their bundled release of Indy.

Just FYI, PR 299 (https://github.com/IndySockets/Indy/pull/299) has been abandoned by the author. Going forward, there is a new effort now to update Indy to the latest OpenSSL using a completely new and separate package as an add-on to indy: https://github.com/IndySockets/IndyTLS-OpenSSL The existing OpenSSL code in the main Indy library is being pulled out into this new package for a v1.0 release for existing users, and then it will be updated with the latest OpenSSL APIs in subsequent releases, independent of the main Indy library.

I started using C++Builder in the early 2000s with BCB v5, and then used v6 exclusively for ~15 years. But my day job doesn't use C++Builder anymore, so I haven't used it at all in recent years.

That is because the old Quality Portal (quality.embarcadero.com) has been replaced with a new system (qp.embarcadero.com).

Because you are explicitly giving the server permission to send compressed response, even though by default IHttpResponse DOES NOT support compressed responses. So, you are likely getting a compressed response in binary format, but IHTttpResponse does not decompress it, and then you try to convert the compressed data into a String, which fails, You need to use the TNetHTTPClient.AutomaticDecompression property to enable handling of "gzip" and "deflate" compressions. In general, DO NOT manipulate the "Accept-Encoding" header manually, unless you are prepared to decode the response manually (ie, by receiving it as a TStream and decompressing it yourself). Just because a BROWSER sends that header (and browsers do support compression) does not mean YOU should send it. TNetHTTPClient will manage the "Accept-Encoding" header for you. It will allow "gzip" and "deflate" compression if the AutomaticDecompression property enables them. Similarly, Indy's TIdHTTP does the same thing. It supports "gzip" and "deflate" compressions, and will set the "Accept-Encoding" accordingly, if you have a Compressor assigned to it.

How so, exactly? It is just a string field, JSON doesn't care what its content is. When you get the string back, simply parse it to extract the base64 substring after the comma, and then decode that substring to get the raw bytes that you can then save to a file. IOW, just reverse the code that created the string. For example: procedure Base64ToImage(const Base64String, FilePath: string); var FileStream: TFileStream; Bytes: TBytes; begin Bytes := TNetEncoding.Base64.DecodeStringToBytes(Base64String); FileStream := TFileStream.Create(FilePath, fmCreate); try FileStream.WriteBuffer(Pointer(Bytes)^, Length(Bytes)); finally FileStream.Free; end; end; procedure LoadBase64JsonToImage; var JSONObject: TJSONObject; Base64String: string; JSONString: string; JSONFile: TStringList; begin JSONFile := TStringList.Create; try JSONFile.LoadFromFile('image_base64.json'); JSONString := JSONFile.Text; finally JSONFile.Free; end; JSONObject := TJSONObject.ParseJSONValue(JSONString) as TJSONObject; try JSONString := JSONObject.GetValue('image_data').Value; finally JSONObject.Free; end; Base64String := Copy(JSONString, Pos(',', JSONString)+1, MaxInt); Base64ToImage(Base64String, 'path/to/image.jpg'); end; You are not supposed to save the entire string to a file. Just as the string wasn't produced entirely from a file to begin with, but from a text and a file.

VER360 and RTLVersion12x are specific to the D12.x series and won't be declared anymore once D13.x+ is released. So this is not future-proof.

The current version in GitHub is 10.6.3.5. It should be. Note that the Indy packages that ship with Delphi are compiled with LIBSUFFIX enabled, whereas the GitHub version is not, so if you do install the GitHub version then you will have to update your project's references to Indy packages, but other than that, everything else should be the same.

Indeed, the IdHL7.pas source file appears to be missing in D12. Delphi ships with the Indy packages preinstalled, and the TIdHL7 component was re-written and re-enabled in Indy's GitHub repo a year prior to D12's release, and it is enabled in the D12 version that is tagged in GitHub. So I would think it should be present in the Indy version that shipped with D12. But, oddly, TIdHL7 is still disabled in Embarcadero's copy of IdRegister.pas. I wonder why. To get HL7 working, you will have to remove the preinstalled version and install the latest GitHub version: https://github.com/IndySockets/Indy/wiki/Updating-Indy

The Win32, Win64, and clang compilers use different debuggers. And as everything is slowly moving towards being entirely clang/LLVM, the old debuggers just don't keep up with the latest debugging info that is being generated, which causes weird side effects.

If you are asking how to know whether a given device can be connected to by your TCP client, then the only way to determine that is to actually attempt to connect to the device's TCP server and see if it succeeds or fails. At the very least, you might try simply pinging each IP to see if it is on the network, but that won't tell you whether the TCP server can be connected to. If you have access to change the device's code, then you might add a UDP server that runs alongside the TCP server, and then you can send a UDP broadcast across the network subnet and see which UDP servers respond.

I still don't understand what you are asking for, exactly.

You are going to have to elaborate on that. What are you trying to check, exactly?

The first thing I notice is that you are calling Connected() across thread boundaries, Don't do that. Connected() performs a socket read in the calling thread, so it could interfere with a read operation in another thread. You shouldn't be calling Connected() at all. Certainly not right after a successful Connect() (which will raise an exception if it fails), and not right before a Disconnect() (which will close the socket and doesn't care if the socket was connected). Another thing I notice is that you are not serializing access to your processing data. TThread.Queue() runs asynchronously, so it is possible that you might receive a new message and overwrite your variables before an earlier queued HandleData() call has been processed. I also wonder why you are creating a new Task to stop the reading thread and reconnect, but are using the main thread to start the reading thread? Your use of multiple threads is odd to me. I would suggest a different design. I would move the (re)connect logic into the reading thread itself, where the thread runs a loop that connects, reads until done, and then disconnects, repeating until stopped. If the IP needs to change, then cache the new IP and ask the thread to reconnect at its earliest convenience. That way, the thread alone decides when it is safe to read and when it is safe to disconnect and reconnect, notifying the main thread of any status changes as needed. Try something more along the lines of this: // set ReceiveThread.Loop = True // start the thread when you are ready to connect the 1st time // stop the thread when you are ready for the final disconnect public ServerHost: String; ServerHostChanged: Boolean; procedure TMainForm.ReceiveThreadRun(Sender: TIdThreadComponent); begin try if (TCPSocket.Host = '') or ServerHostChanged then begin TCPSocket.Host := ServerHost; ServerHostChanged := False; end; try TCPSocket.Connect; except on E: Exception do begin ... for var I := 1 to 5 do begin if not ReceiveThread.Active then Break; Sleep(1000); end; Exit; end; end; try ... while ReceiveThread.Active and (not ServerHostChanged) do begin try if TCPSocket.IOHandler.InputBufferIsEmpty then begin TCPSocket.IOHandler.CheckForDataOnSource(250); TCPSocket.IOHandler.CheckForDisconnect; if TCPSocket.IOHandler.InputBufferIsEmpty then Continue; end; // read a message and process as needed ... except ... Break; end; end; finally TCPSocket.Disconnect; ... end; except ... end; end; ... procedure IpSelectF.IPBtnClick(Sender: TObject); var Btn: TButton; begin Btn := Sender as TButton; if not AvailableIP[Btn.Tag] then Exit; MainF.ServerHost := '192.168.1.' + IntToStr(Btn.Tag); MainF.ServerHostChanged := True; if not MainF.ReceiveThread.Active then MainF.ReceiveThread.Start; end;

On Windows, you can use the Network List Manager API, specifically the INetworkListManager.isConnectedToInternet property. However, as there are so many different ways that a PC can be connected to the Internet nowadays, you are better off simply trying to access an online resource (such as your status file) and see if it succeeds or fails, don't even bother polling the Internet status beforehand. That just introduces a TOCTOU race condition.