Jump to content

pyscripter

Members
 View Profile  See their activity

  • Content Count

    785

  • Joined

  • Last visited

  • Days Won

    42

Posts posted by pyscripter

  5. Posted · Edited by pyscripter

    The TitleBarPanel is used by the IDE.   I guess it was developed to resolve the problem with the disappearing/flickering controls of the IDE title bar (search, layout controls, etc.),    It can accommodate Toolbars (including the ActionMainMenuBar) and other controls, so you can place the main menu on the titleBar (see the sample app).   And to answer the original question, you would need to manually adjust the Titlebar colors every time there is a style change.  This is probably how the IDE styles its TitleBarPanel.   

     

    @Vincent Parrett I also do not like the overcrowding of TForm and other controls with rarely used properties.  (e.g. CustomHint that can be linked to a Balloon Hint all but abandoned - not DPI aware).

    • Like 2

  6. Posted · Edited by pyscripter

    Development of SynEdit at PyScripter has been moved to and merged with TurboPack SynEdit.  The focus of the development is to modernize the code base and enhance the functionality (sometimes at the expense of backward compatibility).  In addition to the earlier enhancements  and fixes two more features have been recently added:

    • Per-monitor DPI awareness
    • Support for Font Ligatures (new option eoShowLigatures)

     

    Fonts like Cascadia Code and Fira Code contain ligatures relevant to programming. See this article for details.  Are you using font ligatures?  Do you like them?

     

    See sample.  Thanks to vhanla for contributing the ligature support.

    • Like 7
    • Thanks 1

  7. Posted · Edited by pyscripter

    Project Magician is wonderful and a must for all Delphi programmers.   Thank you @Uwe Raabe.

     

    However I recently run into the following problem.   As I was debugging, whenever I tried to step into Vcl.Graphics the file would open and get marked as modified.  Moreover stepping into the code would not work.   Also when I opened Vcl.Graphics and some other files in the IDE, it would automatically marked them as modified.   I was puzzled.  I thought this was a new bug in the 10..4.1 Delphi IDE.  But it turns out this was due to a Project Magician, otherwise very useful option to "Clean Line Feeds" under global settings.  Vcl.Graphics has mixed line breaks in Delphi 10.4.1, so whenever it is opened in the IDE it would be automatically marked as modified since the mixed line breaks were detected and marked for fixing.    And then debugging is hampered + you get all these annoying messages about the IDE being unable to create a backup.

     

    One suggestion to @Uwe Raabe is that Delphi library files are excluded from line-feed cleaning.

  9. Posted · Edited by pyscripter

    4 hours ago, FPiette said:

    So I'm using CreateDeviceContext instead CreateHwndRenderTarget

    You can get a Device context from the Render Target.  I am using ID2D1DeviceContext5 which was introduced with the Creators Update.

     

    if Supports(RenderTarget, ID2D1DeviceContext5, DeviceContext5)

     

    And as I said you do not need (multiple) D2D Windows.  Just use standard forms and  one DCRenderTarget to use in the OnPaint event of the form or by overriding the Paint method of Controls.

     

    And in terms of speed D2DSVG renders 300 svgs to bitmaps in less than 15ms.

  10. Posted

    I have used D2D to draw SVG images (see https://github.com/EtheaDev/SVGIconImageList/blob/master/Source/D2DSVGFactory.pas) and the performance is very good!

    I found that Vcl.Direct2D was not worth the trouble and that it was easier to work directly with the D2D interfaces.   Also I preferred to use the DCRenderTarget as opposed to HWndRendertarget, since the former blends better with GDI and GDI+ applications.

      

    One issue I had was with hardware acceleration.

      

        if not Succeeded(D2DFactory.CreateDCRenderTarget(
      D2D1RenderTargetProperties(
        {$IFDEF GPUSupprt}
        D2D1_RENDER_TARGET_TYPE_DEFAULT,
        {$ELSE}
        D2D1_RENDER_TARGET_TYPE_SOFTWARE, // much faster in my desktop with a slow GPU
        {$ENDIF}
        D2D1PixelFormat(DXGI_FORMAT_B8G8R8A8_UNORM, D2D1_ALPHA_MODE_PREMULTIPLIED),
        0, 0, D2D1_RENDER_TARGET_USAGE_GDI_COMPATIBLE),
        RenderTarget))

    In the code above D2D1_RENDER_TARGET_TYPE_SOFTWARE avoids hardware acceleration and it was massively faster in a Desktop with a slow GPU.  You may want to try that.

  11. Posted · Edited by pyscripter

    8 hours ago, Stefan Glienke said:

    Loading an entire file into a TStringList is a bad way to begin with tbh yet often the most easy way because there are no nice to use alternatives out of the box.

    Agree.  In the old days (pre Unicode) I wrote the attached Strmtxt.pas (converts a stream to a text file).  It would need to be updated to work with recent versions of Delphi.  And it works great with buffered streams such as @David Heffernan's TReadOnlyCachedFileStream.  With that you could do something like:

      

      var Stream := TReadOnlyCachedFileStream.Create('c:\temp\t');
  AssignStream(Txt, Stream);
  
  while not EOF(Txt) do
  begin
    Readln(Txt,S);
    Writeln(MemoText, S);
  end;

     

    However when you build a text editor such as SynEdit, you typically load the whole file in memory.   In any case, the focus of this topic was the limitations of TStringList with regards to dealing with encodings, BOM and Line breaks.   It was not about what is the most efficient way to do text processing in Delphi.

     

    STRMTXT.PAS

    • Like 2

  12. Posted · Edited by pyscripter

    The most common way do text-processing in Delphi is to load a file into a TStringList and then process the text line-by-line.  Often you need to save the contents of the StringList back to the file.  The TStringList is one of the most widely used RTL classes.  However there are a number of limitations discussed below:

     

    a) No easy way to preserve line breaks on Load/Save

    TStringList does not make any effort to recognize the type of line breaks (LF, CR or CRLF) in the files it opens, let alone save that for use on saving.

     

    b) Information loss without any warning or any option for dealing with that.

    Internally TStringList uses unicode strings, but when you save its contents to a file using the default encoding (ANSI), this may result in information loss, without getting any warning or having any means for dealing with that.  TEncoding.GetBytes also suffers from that.

     

    c) No easy way to determine whether a file you loaded into a TStringList contained a BOM

    When you load a file (LoadFromFile method), the encoding of the file is stored but not the information about whether the file contained a BOM or not.  The WriteBOM property is only used when you save a file.

     

    d) Last but not least, no easy way of dealing with utf8 encoded files without a BOM

    The default text file format in Linux systems, in Visual Studio Code and other editors, as well as in languages such as python 3 is utf8 without BOM.  Reading such files with TStringList is problematic and can result in errors, because it thinks such files are ANSI encoded.  You could change the DefaultEncoding to utf8, but then you get errors when you read ansi files.  No effort is made to detect whether a file without a BOM contains utf8 sequences.

     

    Overall, it is desirable that, when you load a file using LoadFromFile and then you save it using SavetoFile, the saved copy is identical to the original.

     

    I am attaching a general purpose TStringList descendent that deals with all the above issues in case anyone has a use for that.

    XStringList.pas

    • Like 7

  14. Posted · Edited by pyscripter

    23 minutes ago, Darian Miller said:

     

    The new drop down inserts $(Auto)    Have you tried that text?

     

    Thanks Darian.  I did.  The problem only happens when you have a dpk file without a project file.  If the dpk file contains the new directive {$LIBSUFFIX AUTO} the IDE does not recognize that and thinks the actual suffix is "AUTO".

  15. Posted · Edited by pyscripter

    15 minutes ago, Remy Lebeau said:

    That is still a beta feature, and it doesn't work quite as well as everyone had hoped it would.  Maybe in the future, it will be better.

    I would like to add that if you change the default Windows page to 65001 and have pas files containing ASCII characters > 127  then your files will be messed up when you open them in Delphi.  Also if you build your Delphi projects you will get warnings or even worse produce erroneous executables without warnings.  Try to compile SynEdit for example.

     

    Having said that, this option is great for interacting with console applications and system processes and being able to at last handle unicode console input/output.

    • Like 1

  16. Posted · Edited by pyscripter

    Agree with all the above, except that UTF8String is an an AnsiString with a Code Page 65001 and is also Unicode compliant and incurs no conversion loss.  It is the default string type in FPC.  In Linux systems everything is UTF8.  And nowadays 65001 it can be set as the default code page in Windows.  

    • Like 3

  19. Posted

    LIBSUFFIX AUTO has been a much requested feature for ages.  The Delphi 10.4.1 announcement said:

     

    Quote

    Package AUTO libsuffix: packages can now have an automatic version suffix, instead of manually updating and specifying the right version suffix with each new release. (The compiler quietly supported this in 10.4, but full support for the feature in the IDE and package project settings is introduced in 10.4.1.)

    Sounded interesting so I decided to try that.  I first searched the documentation and found the following:

    Quote

    Note: In RAD Studio Sydney 10.4, the $LIBSUFFIX directive allows the use of an AUTO option. This option makes the compiler use the current release number for packages, it also allows to upgrade a package to a new release, with no need to update the libsuffix value.

     

    So I added {$LIBSUFFIX AUTO} to a package of mine say xyz.dpk  and the bpl file generated was indeed xyz270.bpl.   However I got an error message saying:

     

    Quote

    [Fatal Error] Can't load package xyzAUTO.bpl.
    The system cannot find the file specified 

    This much for "full support" for this feature.  :classic_angry:   Am I missing something??

    • Sad 1

  24. Posted · Edited by pyscripter

    57 minutes ago, Anders Melander said:

    If you care about speed use a SAX parser instead

    ... of TXMLDocument:classic_biggrin:.  Fully agree.

     

    MSXML contains a SAX reader/writer.  Delphi implementation examples at http://www.craigmurphy.com/bug/.

     

    XMLLite is a good alternative to SAX on Windows.  See the note about push and pull parsers.  Similar speed and much easier to program with.  And there is a Delphi wrapper (just a single unit to add to  your project).

  25. Posted · Edited by pyscripter

    18 hours ago, Javier Tarí said:

    If you are interested in performance, http://kluug.net (Ondřej Pokorný) has two excellent libraries; the freeware OmniXML and the commercial OXml. I'm user and customer of OXml

    OmniXML is included in Delphi, but I am not sure how it compares to the standalone one.

     

    If you look at the benchmarks of OXml you will see that if you access the library through Delphi XML and the OXml vendor  you would consume almost 10 times more memory and  5.7 times more CPU time compared to raw access.  The navigation time increases 32 times!! Which is exactly the point I was trying to make.

     

    image.thumb.png.b16fa4fd3de742a43be6cbd3b03603f5.png

×