Remy Lebeau

Or, use the TDateTimePicker.ShowCheckBox and TDateTimePicker.Checked properties instead.

Close() doesn't free the Form unless you explicitly ask for that behavior in its OnClose event (and even that, that logic uses Release() internally). In 20+ years using Delphi, I've never run into an AV from closing a Form. If you are getting an AV when closing a Form then you are likely mismanaging your code that uses the Form.

Release() destroys the Form that it is called on. Whereas Close() merely closes (hides) the Form, allowing it to be reopened (shown) again at a later time if desired.

I would opt to simply eliminate J altogether: function IndexOfFirstNotOf(const s: string; Ch: Char): Integer; begin for Result := 1 to Length(s) do begin if s[Result] <> Ch then Exit; end; Result := 0; end; function RemoveZeroLeft(const s : String) : string; var i : integer; begin i = IndexOfFirstNotOf(s, '0'); if i > 1 then Result := Copy(s, 1, MaxInt) else if i = 1 then Result := s else Result := ''; // or '0' if needed end;

You can't manually implement the interface of an anonymous method. It is a compiler-generated type that you can't refer to. And it doesn't have a Guid assigned to it, so you can't query for it at runtime, either. All you can do is hold a reference to it. The compiler generates the necessary code to call its Invoke() when it sees user code trying to call the anonymous method. It is possible to manually call Invoke() directly (by declaring the interface manually, and then casting the anonymous method), but there is no good reason to ever do that. They could, and that shouldn't change anything at all, because user code shouldn't ever be calling Invoke() directly to begin with. Nobody is "manually implementing" the interface of an anonymous method.

In modern versions, IDE updates are released on GetIt. Simply check there if any updates are available for download.

Unfortunately no. Empty groups are not displayed, that is simply how Microsoft implemented it. So, the only option would be to add a blank item to the group just to keep it visible, and then remove that item later when it is no longer needed.

Depends on the context. The compiler thinks you are using J's value before you have actually assigned any value to J. Sometimes the compile makes a mistake on this, sometimes not, so it may or may not be a false positive. How are you actually using J exactly? Can you show that code?

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.