Jump to content

Sherlock

Moderators
  • Content Count

    1207
  • Joined

  • Last visited

  • Days Won

    25

Posts posted by Sherlock


  1. Given the complexity and the tendency of developers to always suggest some totally different approach :classic_biggrin:, here is my completely different suggestion. You seem to have the need to validate an e-mail address before storing it. How about sending a test mail before doing that. That way you get to birds with one stone: Verify the address, and get the permission to use it... a must have in Europe.

    • Like 1

  2. Well take a step back then. Do you know what you are doing? You are mixing two things here, maybe at first try this with just the important one and save the syntactic sugar of inline variables (which may still be buggy) for later:

    procedure TGISEngine.AddFilenames(const AFilenames: TGISFilesnamesSHP);
    var F: string; // I'm just guessing here, and maybe that is the compilers issue as well
    begin
      if (Length(AFilenames) > 0 ) then
        for F in AFilenames do
          if not FFilenames.Contains(F) then
            FFilenames.Add(F);
    end;

    Later on, you may read what the Docwiki has to say about the limited abilities the compiler has regarding type inference and discover their examples for inlines in for...in loops all have a type declaration.


  3. Just my two cents as a person who has been developing commercial software with Delphi for over 20 years now (where has all the time gone? sigh). Whenever there have been issues with the software, one thing turned out to be true: The DB was almost always the problem. That, or the way DB data was being handled. Rethinking table design and handling of DB-aware and not-DB-aware components have always done the trick.

     

    But feel free to produce a minimal reproducible example for the folks at Embarcadero, if you are 100% sure that Delphi is at fault.


  4. 8 minutes ago, omnibrain said:

    Perhaps we should add something like MadExcept. It's a shame that Delphi offers no inbuilt StackTrace at runtime.

    That is a good thing. Anything built into Delphi slowly decays due to lack of maintenance. Until one day it produces only errors and management has to decide wether to trash it or build something around it to try and fix it. Most prominent recent example: ErrorInsight fixed through LSP. Or the Parnassus tools...taking longer and longer to appear in GetIt with each new Delphi version.


  5. I see that F is indeed checked further up. I only considered the last quoted portion of code. As for the "tutorial" it is quite tedious to follow. I personally hate video tutorials, because they are always to slow when it does not matter and to fast when it does. A readable tutorial is worth so much more than that. Anyway... I recreated the project as stated in the video,I even copied your code, and it works without errors. You must have done something different along the line...especially since your screenshot somewhat differs from the video.


  6. Well, don't typecast without checking if the type fits. You need to check if F really is a TLayout and if child 0 really is a TLine. Something like:

    if F is TLayout then
      if TLayout(F).Children[0] is TLine then
        L:=TLine(TLayout(F).Children[0]);

    On the other hand you should only type cast when necessary. TFMXObject has a perfectly fine Children property no need to cast F into a TLayout.

     

    Check your entire code for these things and you should have eliminated one cause for the AV.

    • Like 1

  7. I admit it has been 10+ years since I looked into translation tools, but dxgettext was the least Delphi like with an inability to use resourcestrings. Multilizer and later on Sisulizer have been the tools of choice for me ever since. But I must admit I have not been needing localization tool in the past couple of years so my bias is very sure to be outdated.

×