Jump to content

aehimself

Members
  • Content Count

    1030
  • Joined

  • Last visited

  • Days Won

    22

Posts posted by aehimself


  1. Do not watch Task Manager to diagnose memory leaks. Windows often doesn't release the memory what the application is not using anymore but keeps it to speed up future memory allocations.

    I don't know if FastMM (ReportMemoryLeaksOnShutdown) will report a leak in a DLL, but you can request a trial of DeLeaker which will show you everything for sure.

     

    There's one thing for sure - there's no memory leak in System.SysUtils in the initialization / finalization section.


  2. TMS has a commercial package, you read more about it at https://www.tmssoftware.com/site/wupdate.asp

     

    I wrote my own, open source version which I am using in my main application for a while now and seems to do it's job properly. I attempted to build it up to be as versatile as possible but it's probably still a toddler compared with TMS when it comes to features, though.

     

    There's an example code on how to create an update file and how to update your application here:

     

    • Like 1

  3. We are developing a 20 year old application at work: over 1,5M LOC, 500-700 frames, couple thousands of units. Today we had a meeting with our teamlead where we successfully convinced him to allow the framework team to go for a full visual and codebase refactoring - effectively building it from the ground up once more; reusing mostly experience and tiny chunks of the original code (yeah, it's that bad).

     

    There are things what you can not delay any further. If this is what is needed to improve the coding experience devs will have to get used to the new model. It's for their own sake aswell, after all.

     

    With all that said, I'm fully aware that OP probably won't go in this direction. I'm leaving my remark here for future visitors, who might still be able to change their design seeing what the easy way can / will cause.

    • Like 2

  4. This is the method I ended up using:

    Procedure FixDateSeparator;
    Var
      Buffer: Array[0..2] Of Char;
    Begin
      If GetLocaleInfo(GetThreadLocale, LOCALE_SDATE, Buffer, 3) > 0 Then
      Begin
        FormatSettings.DateSeparator := Buffer[0];
        FormatSettings.ShortDateFormat := FormatSettings.ShortDateFormat.Replace(FormatSettings.DateSeparator, '/');
      End
      Else
        FormatSettings.DateSeparator := '/';
    End;

    It's a close copy to Delphi 11.2's GetLocaleChar implementation which will fix the buffer underrun in prior versions. Add a TFormatSettings parameter and call it with "fmt" before you call StrToDate.

     

    This is the good news. The bad news is, parsing strings as dates was heavily refactored in D11. If the above won't fix your problem, you'll have to start playing around.

    For me the date format was "yyyy. mm. dd." D10.4 was happy to parse "2023. 02. 07" but D11 required the final dot.

    • Thanks 1

  5. Precision-wise probably nothing, multimedia timers are supposed to be the closest you can get.

    It is transparent though (you can see what is happening under the hood) and it is a drop-in replacement for TTimer which means 0 code change is required.

     

    It's also good to leave a variety of options so OP and future visitors can choose their favorite flavor.

    • Like 1

  6. 9 minutes ago, Fr0sT.Brutal said:

    Otherwise you must use some kind of concatenating buffer/stream

    I wrote my helper class for this purpose, it can be used and abused as one feels like it:

    Maybe it worth to revisit that code, I don't remember what lurks within it's lines.


  7. You put your files wherever you like, just make sure you add those paths to the global / project settings.

    Copying them to the Lib is not a good idea so please don't do that 🙂

     

    Let's say you create a folder, C:\DelphiComponents and you start to put your components here. For example, you download ICS and extract it to C:\DelphiComponents\ICS directory.

    In Delphi, go to Tools -> Options -> Language -> Delphi -> Library. The easiest solution is to add the folder where all source files are to the Library path field in all platforms, in our example C:\DelphiComponents\ICS\Source.

     

    At this stage you are ready to install and use the components and you don't have to worry about DCU locations, as the component will compile from the source and compiled DCUs will be placed in the project's own .\$(Platform)\$(Config) directory.

     

    Basically,

     

    Library path: the place Delphi will look for a referenced file, can either be a pre-compiled DCU or a .PAS source file. DCUs should be compiled in Release configuration

    Browsing path: locations where the editor's Code Browsing will look for source .PAS files when navigating

    Debug DCU path: in case you have pre-compiled DCUs in Library path, you can specify the same DCUs but in Debug configuration. During debugging these will be used so you can step in and debug the components source

     

    My suggestion is you set your library path to the source of the component and forget about platforms and configs if you are unsure.

×