Remy Lebeau

FreePascal has {$I %LINE%} (doc) , but Delphi doesn't.

You are invoking floating-point division, not integer division. All floating-point exceptions have been intentionally disabled by default in Delphi 12: http://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#Disabling_Floating-Point_Exceptions_on_All_Platforms Dividing a floating-point value by 0 used to raise an EDivByZero exception, but by default it no longer does so. This page explains how to restore the old behavior if you really need it: http://docwiki.embarcadero.com/RADStudio/Athens/en/Floating_Point_Operation_Exception_Masks#How_to_Restore_Old_Behavior

That error message doesn't necessarily mean the specified file can't be found. It can also mean that a DLL/BPL that the specified file depends on can't be found. Unfortunately, Windows doesn't differentiate between those two cases. But what you can do is use a tool like SysInternals Process Monitor to see exactly which file is not being found and where exactly Windows is looking for the file. That may give you some better clues.

Unless you are sending a massively large JSON, or receiving a massively large JSON, then it should not be taking anywhere near that long to encode/decode the data. So I have to assume that either 1) you are on a very slow network, or 2) the response from the server is really taking that long to transmit. Use a packet sniffer to check that, as well as to compare the Postman traffic to the TIdHTTP traffic any differences.

Yes, I'm well aware of how LIBSUFFIX works and the benefit of using it. It's been on my TODO list for a long time (https://github.com/IndySockets/Indy/issues/133), but it's not likely to be implemented in Indy 10 because that is a major interface change. But it's already implemented for Indy 11.

The packages in Indy's GitHub repo are named with version-specific suffixes on each DPK/DPROJ file. The bundled Indy packages that ship with the IDE have been modified by Embarcadero to use LIBSUFFIX when compiled, so the version suffixes are omitted from the generated DCP files but not from the final BPL files.

The ticket is not closed: https://github.com/IndySockets/Indy/issues/133

I have updated IdHL7.pas and IdCompilerDefines.inc with your changes.

If the record is 8-byte aligned, then it would have padding between the 2 integers. That is why I suggested you verify the record's actual size and alignment on the Delphi side. If you need to ensure the record is 8 bytes, then applying 'packed' or ($ALIGN 4} to the record is the way to go. You are missing the 'cdecl' calling convention on your declaration of ts_node_start_point() under 32bit, so the Delphi compiler uses the 'register' calling convention instead.

I have now updated Clean_IDE.cmd to do exactly that. I might consider doing that for a future version of the .cmd script. That would probably require making a separate .txt file of all the known Indy units and then have the .cmd script loop through that file for every platform.

See: https://stackoverflow.com/questions/45241488/how-does-the-cdecl-calling-convention-returns-a-struct https://stackoverflow.com/questions/16119116/passing-record-as-a-function-result-from-delphi-dll-to-c The C code is returning the struct wholly in the EDX:EAX register, but Delphi is expecting it to be passed via a hidden reference parameter instead, according to the same Language Guide you linked to: So, your Int64 hack is likely the only way to go for 32bit, unless you have access to change the C code to match Delphi's use of an output parameter. Also, make sure your TPoint record in Delphi has the right size and alignment to match the C type. You did not show your declaration of the record, but if it is not declared with 'packed' or {$ALIGN} then it may have extra padding in it, making it larger than the C type, which would explain why you are having trouble accessing the column field.

Yes, but you did that using Indy's master code, which only had bug fixes and new package files. Try it again with branched code that has interface changes in it, and you may have a different result.

More accurately, there are some interface changes to the base TIdSASL class and the TIdSASLMechanisms class, which affects several Indy components that use SASL, including TIdPOP3, TIdSMTP, TIdIMAP4, and TIdDICT. Yes, but that's not going to happen until the branch is merged into the master code. Embarcadero doesn't ship branched code.

The new OAuth SASL classes are not compatible with the pre-bundled Indy version. The sasl-oauth branch contains some interface changes, to add an APort parameter to the SASL process. Unfortunately, not.

When I try this step in Delphi 12, there are only 16 files TOTAL listed: - 8 starting with FMX - 8 starting with VCL All 8 are Indy files (and all of them are related to IdAntiFreeze), there are no "play" files, no "idoc.dcu" or "idispids.dcu" files, etc. I'm guessing the missing files are platform-specific files, in which case this step is dependent on the configuration chosen when you install the IDE. I don't have any non-Windows platforms installed. I'll have to figure out a way to filter out the non-Indy files so they don't get auto-deleted by accident.

It should not be ambiguous. Indy uses the LocaleCharsFromUnicode() function that Delphi provides in the System unit. The IdGlobal unit defines its own version of that function only if Delphi's version doesn't exist. So there should be no such function defined in the IdGlobal unit in Delphi 12. If there is, then something is wrong. The DPKs don't provide the conditionals that Indy uses. They are all defined in IdCompilerDefines.inc which is included by the individual .pas files.... OH, yeah, the branch wasn't up-to-date with the latest .inc file yet. I have updated the branch with the latest master code for Delphi 12.

No, the spelling is correct. If you remove the preinstalled version of Indy then LivePreview/EMSEdge projects will break, but "you CAN use a SEPARATE installation of Indy 10 for non-LivePreview/EMSEdge projects" if you need to use multiple Indy versions. I don't have an ETA on that. The code is pretty much done for now, but it is an interface change as there is an extra parameter added to the SASL login procedures. And also, I don't have palette icons for the new OAuth SASL components yet.

Correct, there is no event published for this. You would have to subclass the ListView to handle the HDN_ITEMCHANGING notification directly. Alternatively, if you are building with Runtime Packages disabled, you can make a copy of Vcl.ComCtrls.pas and add it to your project, and then make the code change I mentioned earlier to fix the bug.

In this example, yes. Like strings, dynamic arrays are also reference-counted. When you nil a reference to a dynamic array, its refcount is decremented. When its refcount falls to 0, its contents are finalized as needed (to release their references, etc), and the array is freed from memory.

Multiple versions of Indy can't be installed in the IDE at the same time. You would have to maintain separate copies and switch between them on a per-project basis as needed. Also, TIdSASLXOAuth2 is not in the master code, it is still in a sasl-oath branch that hasn't been merged yet.

That is not a good idea. Such an indicator should not be in the data payload itself, it should precede the payload, ie in a separate message header. Also, to differentiate between UTF8 or UTF16, you could use standard Unicode BOMs. So, for instance, have a message header that indicates whether the payload is text bytes or file bytes, and the total byte size. Then in the payload itself, if it is text then have it start with a BOM before the actual text bytes. Although, in reality, it is generally not a good idea to use UTF16 in data transmissions. Better to stick with just UTF8. Convert to/from UTF16 in memory only, if needed.

Which files does it delete that it shouldn't? Oh. Nevermind.

https://docwiki.embarcadero.com/RADStudio/en/FireUI_Live_Preview

I just now closed the PR and checked in my own changes for Delphi 12.

In XE7 and later, you should use the GetTypeKind() intrinsic function instead of using TypeInfo() comparisons: https://delphisorcery.blogspot.com/2014/10/new-language-feature-in-xe7.html case GetTypeKind(T) of tkInteger: PInteger(@Result)^ := 10; tkLString: PAnsiString(@Result)^ := 'Hello'; tkUString: PUnicodeString(@Result)^ := 'Hello'; ... end;