Remy Lebeau

That should be easy enough to account for, using Random(16) to generate 4 random bits that can be shifted into the UInt64's bits 0, 31, 32, and 63 which the shifted Random(MaxInt) values will never fill in, eg: var Num, Bits: UInt64; Num := (UInt64(Random(maxInt)) shl 32) or UInt64(Random(maxInt)); Bits := UInt64(Random(16)); Num := Num or (Bits and 1); Num := Num or ((Bits and 2) shl 30); Num := Num or ((Bits and 4) shl 30); Num := Num or ((Bits and 8) shl 60);

That makes no sense. {$ZEROBASEDSTRINGS} is local to the unit only. Its use depends on whether YOU want to access YOUR strings inside YOUR unit using 0-based or 1-based indexes, The IDE settings have nothing to do with that.

(Low|High)(string) were introduced in XE3, the same version that introduced {$ZEROBASEDSTRINGS} and TStringHelper.

That is easy enough to account for by using Low(String), eg: var s: String; c: Char; ... c := s.Chars[ZeroBasedIndex]; s[Low(s)+ZeroBasedIndex] := ...; Low(s) will be 0 for {$ZEROBASEDSTRINGS ON}, and 1 for {$ZEROBASEDSTRINGS OFF}.

FYI, Embarcadero was considering making Delphi strings immutable in the NEXTGEN compilers, but they ultimately decided against that.

You do know that is no longer necessary starting with RAD Studio 10.4, don't you? Embarcadero has moved mobile platforms away from ARC memory management for objects, and has done away with all of the NEXTGEN compiler features, which includes 0-based string indexing on mobile. Mobile now defaults to 1-based indexing, just like desktop platforms. If you really want to continue using 0-based string indexing, you can use {$ZEROBASEDSTRINGS ON}, or TStringHelper.

Updated plans for C++Builder were posted in July 2020: https://blogs.embarcadero.com/c-builder-and-platforms-support/

Assuming the calling convention of the DLL function is stdcall, then the correct PInvoke declaration in C# would be as follows: [DllImport("my.dll", CharSet = CharSet.Ansi)] static extern bool Mostra_Msg (string Parmsg); Alternatively: [DllImport("my.dll")] static extern bool Mostra_Msg ([MarshalAs(UnmanagedType.LPStr)]string Parmsg);

That applies to SHFileOperation(), but not to IFileOperation. You would have to either: - call CopyItem() for each desired source file individually. - call CopyItems() for the whole list of desired files.

Yup, and here we are, months after the initial 10.4 release, and already into a new 10.4.1 release, and Embarcadero still hasn't stated one way or the other if they are even working on a Community Edition or not, let alone an ETA for it.

What is on the Cards exactly? When a UI has to display a lot of elements that start hindering performance, that is when I start considering either redesigning the UI to use different higher-performant controls, or switching to owner-drawing as much as possible to reduce resource usage.

Yes. On Android, maybe, maybe not. ISAPI is IIS-specific, and support for ISAPI has been dropped from PHP. So, if you can execute the PHP CGI executable AND redirect its STDIN/STDOUT on Android, or if you can find a FastCGI processor that works on Android, or if you can compile the PHP core library (or 3rd party implementation) directly into your app, then you might have a chance.

For the same reason that an updated IDEFixPack hasn't been released for 10.4.x yet - because Andreas doesn't have an active paid license for the IDE anymore, and Embarcadero hasn't released a 10.4.x Community Edition yet. See this topic:

There was a recent discussion related to this topic in the AToZed Indy forum: Process PHP with TIdHTTPServer

Which is funny, given that the syntax for helpers actually supports inheritance, but Delphi allows it only in class helpers, not in type/record helpers. FreePascal proves inheritance can work in all three kinds of helpers (just not in Delphi mode, for compatibility reasons).

Here is another idea - instead of flashing the Button itself, place it inside a Panel whose borders appear slightly beyond the Button's edges, and then flash the Panel as needed. Or, create an alpha-blended overlay window, place it over the Button, and then hide/show the window as needed.

Not yet. Updating the existing scripts to make sure they work properly is one thing. Adding new scripts for new IDEs is another, it is just one more headache to maintain. But if you want to provide some scripts, I'll look at them.

Not by default, but you can manually enable the BS_OWNERDRAW style on it, and then intercept WM_DRAWITEM messages sent to it. Then you can make it look however you want. Or, simply use a different Button control that supports custom coloring, like TBitBtn (which already has the BS_OWNERDRAW style) or TSpeedButton.

Have you tried TortoiseGit yet?

Yup, that is the one I use, too.

My goals for Indy 11 include adding use of LIBSUFFIX on the packages, changing the structure of the source folders, and reducing the steps needed to compile and install the packages. A few years ago, Embarcadero sent me a document listing the available commands that GetIt had implemented at the time (I'm assuming the same set of commands still applies today). There are CompileProject and InstallPackage commands listed in that document.

Yes, do not use TObject::Free() in C++, use the native delete operator instead. The delete[] operator is for freeing arrays allocated with the new[] operator, so the generated code is definitely wrong in that regard. A general rule of thumb is: allocator ->deallocator new -> delete (single item) new[] -> delete[] (array of items) (m|c|re)alloc() -> free() (C runtime) I also question the expert's decision to set the component's Owner to NULL, but without knowing what the expert actually does and what its input is, I could not say for sure if that is correct or not.

At one point, yes, to work around a bug in old versions of DCC32 related to the unit's use of the Zlib object files. There is a comment about that issue at the top of the Indy 9 version of IdCompressionIntercept.pas (though this version has a more detailed comment about it). I don't know if that bug is still an issue anymore, but the DCC32-based batch scripts still compile IdCompressionIntercept.pas separately (the MSBuild-based batch scripts do not).

Indy stopped using batch scripts altogether for Delphi installations after D2009, in favor of IDE-based installations. Indy does use MSBuild for C++Builder XE2+ installations. I didn't write the old DCC32-based batch scripts, or the updated MSBuild-based scripts. MSBuild was first introduced in D2007, but it likely wasn't until XE2 that use of it caught on. Or maybe XE2 was just the oldest version that Malcolm Smith (who wrote the MSBuild-based scripts) could support at the time. I don't know. I just maintain them. I'm not against migrating the 2007-XE batch scripts to MSBuild, but I have no way to validate/test them myself. But the ultimate goal is to move Indy away from using the batch scripts at all, for either Delphi or C++. The installation needs to be more streamlined (my goal for Indy 11) so that Indy can eventually be migrated to GetIt.

Actually, I did have a backup at the time (a RAID1 NAS), but a bad firmware upgrade of the NAS server corrupted both HDD's filesystem, rendering them both unmountable. And I haven't had the time or money to get them recovered professionally yet. Now I have a new non-RAID NAS for my current backup, but it doesn't have any of my old files on it, only the files that were on my laptop at the time, and that wasn't everything that was in the original backup. And then that laptop died unexpectedly awhile back ago, so now I'm on a new laptop, and it has only my recent documents and latest Indy code on it, that is about it. No compiler, no IDE, no VMs. Any help is appreciated. In what way? Although, *Delphi* installations really should not be using the batch scripts at all, compiling and installing directly from within the IDE is preferred. It is *C++Builder* installations that still need the batch scripts.