Remy Lebeau

Not that I'm aware of, because 99% of apps don't need that kind of information. What is your use-case for retrieving such a list?

AFAIK, that function cannot return a list of file extensions for a given application. It is typically used the other way around - given a file type, it can return associated data, such as the application exe/command that will open the file.

Unfortunately, it is not so simple. There are many different ways for file types to be associated with an app. The Registry keys you are currently looking at (the ones starting with a dot) is just the beginning. Those are static verb registrations, and the most common approach. But there are other ways, too. Especially when you start taking into account things like dynamic registrations, Shell COM objects for File Type handlers and Context Menu handlers, etc. A lot can go on behind the scenes when the OS is asked to open an app associated with a given file.

In theory, pehaps. In practice, not likely. Using an interface makes for easier lifetime management. An anonymous procedure can capture variables, so they have to be stored somewhere that can follow the procedure as it's passed around. As long as someone has a reference to the procedure, the variables have to be maintained. So it makes sense for the implementation to use a separate object for that storage. And someone has to create that object, and more importantly destroy that object after everyone is done using it. Since Delphi doesn't have garbage collection, using a reference-counted interface makes sense. How would you propose doing it without using an interface? The only way that makes sense to me is a managed record with a manual reference count (but managed records didn't exist yet when anonymous procedures were introduced). In any case, just because an anonymous procedure is implemented using an interface does not mean you have to use it as an interface.

That is correct. Basically, an anonymous method is implemented as an interfaced object with an Invoke() method that matches the signature of the anonymous method. https://stackoverflow.com/questions/39955052/how-are-anonymous-methods-implemented-under-the-hood Not by Embarcadero, as it is an implementation detail of the compiler. But it is a well-known implementation that is documented on numerous sites/blogs.

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.