Jump to content

Remy Lebeau

Members
  • Content Count

    2719
  • Joined

  • Last visited

  • Days Won

    119

Everything posted by Remy Lebeau

  1. 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).
  2. Remy Lebeau

    Tbutton Flashing

    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.
  3. Remy Lebeau

    Indy package names

    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.
  4. Remy Lebeau

    Tbutton Flashing

    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.
  5. Have you tried TortoiseGit yet?
  6. Remy Lebeau

    "Simulating" a com port with data arriving

    Yup, that is the one I use, too.
  7. Remy Lebeau

    Indy package names

    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.
  8. Remy Lebeau

    What's the correct way to free an object in C++Builder?

    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.
  9. Remy Lebeau

    updated build script for Delphi 2007

    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).
  10. Remy Lebeau

    Indy package names

    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.
  11. Remy Lebeau

    Indy package names

    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.
  12. Remy Lebeau

    Workaround for binary data in strings ...

    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.
  13. Remy Lebeau

    Changing the WordWrap property of a TMemo runtime

    Do you have the same problem with TRichEdit?
  14. Remy Lebeau

    Indy package names

    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.
  15. Remy Lebeau

    Changing the WordWrap property of a TMemo runtime

    Have you tried saving the value of the Text property before changing the WordWrap property, and then re-assign the Text property afterwards?
  16. 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.
  17. Remy Lebeau

    Indy package names

    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).
  18. Then it seems to me that you are approaching this from the wrong angle. If the frontend is UTF-8, then it doesn't matter what the client enters, it will get transmitted as UTF-8, and stored as-is in the DB as UTF-8, and converted between UTF-8<->UTF-16 where needed. Both UTFs handle the entire Unicode repertoire without any data loss. So your issue has to be somewhere else. Either you are not processing your JSON correctly, or you are not sending the JSON back to the client correctly. You really should not be filtering out ANY characters at all, especially since UTFs and JSON support ALL Unicode characters. So I suggest you take some more time to really debug the issue deeper and find out exactly where the REAL failure point is, because it is likely not what you think it is. Which is perfectly fine, if the UI frontend and communication/DB backends are all using UTF-8 properly. The issue has to be somewhere else. Don't remove any characters at all.
  19. Agreed, that is odd to allow that range but not allow 161..255 as well. Certainly in Unicode strings, characters in the 0..255 range are well-defined. But in ANSI/MBCS strings, characters in the 128..255 (Extended ASCII) range are locale-specific. The numeric values of characters in that range vary between what Unicode defines and what different locales/charsets define. Most locales/charsets agree with Unicode only for characters in the 0..127 (ASCII) range, then they define whatever they need for characters 128..255. Beyond character 255, you need Unicode instead. Unicode codepoints #127..#160 (U+007F..U+00A0) are certainly valid in UTF-16, yes. But locale-based characters in the #128..#255 ($80..$FF) range in ANSI/MBCS strings usually map to different numeric values as Unicode codepoints.
  20. Remy Lebeau

    Variation of FormatDateTime(

    Which is exactly why you shouldn't rely on it. It depends on internal implementation details that could change one day in the future. Better to be explicit about the calculations so that if the implementation ever does change then the result will still work as expected.
  21. Remy Lebeau

    UCS4Strings

    https://quality.embarcadero.com/browse/RSP-31118
  22. Remy Lebeau

    Delphi 10.4.1

    Yes. This is clearly stated in the release notes: http://docwiki.embarcadero.com/RADStudio/Sydney/en/10.4_Sydney_-_Release_1
  23. Remy Lebeau

    ExtractFileDrive bug

    My app only deals with local files, not remote files. It accesses the file data using memory-mapped views, which are not coherent over remote connections. I hear what you are saying, but honestly that hasn't been an issue for my app yet. But I can see how PIDLs would not work for those.
  24. Remy Lebeau

    ExtractFileDrive bug

    In that case, yes, without some degree of parsing the path components and mapping them to something real to see if they map the same. Yes, it does. I've been using it for years. I have an app that displays files, tracking their PIDLs. If the user tells the app to open a new file, and its PIDL is already open, I jump to the existing display instead. It works just fine. It may not be the BEST approach, but it works. When I first wrote the code. the only approach I knew about was to convert both paths to their short 8.3 form and then do a simple string comparison. I later found the PIDL approach to be much more reliable, so that is what the app uses now. Later, I learned about the GetFileInformationByHandle() approach, but I never got a chance to update the code. So? The filesystem is part of that. Filesystem paths can be converted to PIDLs, the filesystem shell provider will map the folder and file components accordingly. Get the IShellFolder interface for the root Desktop namespace, pass both filesystem paths to its ParseDispayName() method (short paths, long paths, it doesn't matter), and it will ask the filesystem to parse them and provide absolute PIDLs, which will compare equal if they refer to the same file. Trust me, it works, I use it.
  25. Remy Lebeau

    UCS4StringToWideString broken?

    Not obvious to other people who are not familiar with UCS4String and how it works. It is not a common type most people work with. Agreed. Just like a lot of things in the documentation (or lack of). Sure, for purposes of just iterating and accessing characters, such as during conversions. I stated earlier why it exists at all - mainly so PUCS4Char() typecasts will be null-terminated. That allows the array to act more like a C-style string, just like native string types do. Of course, obviously.
×