Remy Lebeau

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.

True, though 437 does not map every byte (in fact, many bytes) to a Unicode codepoint of same numeric value. For this task (when I have needed to use it in the past), I would use codepage 28591 (ISO-8859-1) instead, which has bytes use the same numeric values as their codepoints. Agreed. More accurately, there is no conversion only when an AnsiString(N)-based string type is assigned to it, as it will simply inherit N as its current codepage, but it does perform a character conversion when a UnicodeString or WideString is assigned to it, and when it is assigned to another non-RawByteString string type. So, even if you were to use RawByteString, you still have to be careful with how you use it.

Do you have the same problem with TRichEdit?

All true. Understood. Because they bundle Indy pre-installed in every IDE release, and most users are more comfortable using the pre-installed version than going to SVN/GitHub to manually install a newer version. And because Embarcadero uses a private copy of Indy for their internal technologies that is not always separated properly from the public version, and so can cause conflicts with user-installed versions of Indy. And because Embarcadero does not update their shipped/private copies of Indy on every IDE release (although they did for 10.4). So making breaking interface changes (which I sometimes do, but I try to keep it minimal) in the public version of Indy is not always possible/feasible, without causing more trouble than it solves. That being said, my ultimate goal (which I have no ETA on) is to 1) get Indy 11 finished and released; 2) get Indy into GetIt; 3) maybe not have Embarcadero ship Indy with the IDE anymore, in favor of GetIt (if it works out). Once in awhile, Embarcadero contribute bug fixes (and occasionally ships breakages without me having reviewed their changes first). That is about it. Yes, of course Embarcadero, being the IDE/compiler vendor, doesn't have to care about their bundled 3rd party packages being backwards compatible, but of course Indy, as the 3rd party code, has to worry about that. Which sucks doubly so for me personally, because several times in the past few years, I have suffered total system losses (mostly due to hardware failures) that have lost me my main dev machine and backups, so most of my personal projects are gone, as well as most of my RADStudio VMs (and the ones that are left are expired betas). I borrowed a family member's laptop to carry on, but have no dev tools installed on it, So while I can make edits to source code in Notepad, I can't compile anything. And, to be quite frank, I just don't have the time or energy to try to setup a new dev environment right now. So, I do what I can with what I have to work with, but I know it is not good enough long term.

Have you tried saving the value of the Text property before changing the WordWrap property, and then re-assign the Text property afterwards?

What kind of crash exactly? This implies to me that you are not creating your JSON properly to begin with. Can you please show your actual code that is taking in user input and producing JSON from it? There is no way for us to tell you that, because you have not shown what you are actually doing yet.

Indy is not the only 3rd party component suite that doesn’t. What you are referring to is the LIBSUFFIX feature. And yes, Indy has not been updated yet to use LIBSUFFIX. That is on the TODO list for Indy 11 (https://github.com/IndySockets/Indy/issues/133), which is planned to include other package improvements, like reorganizing the source folders, simplifying the installation process, etc. The main reason why Indy does not use LIBSUFFIX yet is that I simply don’t have the free time to update all of the existing packages for all of the supported IDE versions, and no way to test such a change is working properly across multiple IDE versions (I’m the only volunteer left writing code for Indy, and I don’t really appreciate your blog calling me sloppy over this issue). But also, because Indy 10 predates when LIBSUFFIX usage became common, and because Indy is bundled with the IDE, so changing the package names will break existing projects. That is why I’ve been waiting for Indy 11 (or at least for a time when I am able to slip this change in between major IDE releases, when Embarcaderom is open to ship such a breaking change).