Remy Lebeau

Focus Mode hides everything except the code editor.

I was simply fixing the broken syntax in uligerhardt's reply.

const OTHER_FLOAT_CONSTANT = Double(0.005);

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.