Jump to content

jbg

Members
 View Profile  See their activity

  • Content Count

    69

  • Joined

  • Last visited

  • Days Won

    26

Posts posted by jbg

  1. Posted

    TEncoding has a GetBytes() method that accepts PWideChar and PByte. Unfortunately it is "strict protected". So you would have to derive a class from TUTF8Encoding and then use that. Alternatively you can use the LocaleCharsFromUnicode system function.

      

      ByteCount := TEncoding.UTF8.GetByteCount(S);
  Buf := GlobalAllocPtr(0, ByteCount);
  if ByteCount > 0 then
    LocaleCharsFromUnicode(CP_UTF8, 0, PChar(S), Length(S), MarshaledAString(Buf), ByteCount, nil, nil);
  GlobalFreePtr(Buf);

     

    Example for a derived TUTF8Encoding class: 

    type
  TUTF8EncodingEx = class(TUTF8Encoding)
  public // make the PWideChar/PByte methods public
    function GetByteCount(Chars: PWideChar; CharCount: Integer): Integer; override;
    function GetBytes(Chars: PWideChar; CharCount: Integer; Bytes: PByte; ByteCount: Integer): Integer; override;
    function GetCharCount(Bytes: PByte; ByteCount: Integer): Integer; override;
    function GetChars(Bytes: PByte; ByteCount: Integer; Chars: PWideChar; CharCount: Integer): Integer; override;
  end;

{ TUTF8EncodingEx }

function TUTF8EncodingEx.GetByteCount(Chars: PWideChar; CharCount: Integer): Integer;
begin
  Result := inherited GetByteCount(Chars, CharCount);
end;

function TUTF8EncodingEx.GetBytes(Chars: PWideChar; CharCount: Integer; Bytes: PByte; ByteCount: Integer): Integer;
begin
  Result := inherited GetBytes(Chars, CharCount, Bytes, ByteCount);
end;

function TUTF8EncodingEx.GetCharCount(Bytes: PByte; ByteCount: Integer): Integer;
begin
  Result := inherited GetCharCount(Bytes, ByteCount);
end;

function TUTF8EncodingEx.GetChars(Bytes: PByte; ByteCount: Integer; Chars: PWideChar; CharCount: Integer): Integer;
begin
  Result := inherited GetChars(Bytes, ByteCount, Chars, CharCount);
end;



begin
  ByteCount := TEncoding.UTF8.GetByteCount(S);
  Buf := GlobalAllocPtr(0, ByteCount);
  if ByteCount > 0 then
    TUTF8EncodingEx(TEncoding.UTF8).GetBytes(PChar(S), Length(S), Buf, ByteCount);
  GlobalFreePtr(Buf);
end;

     

    • Like 1
    • Thanks 1

  2. Posted · Edited by jbg

    You can use the IDE's "process" for the JCL and JVCL but then you have to

    1. Build 4 JCL runtime packages and add their source path, library path and resource path (*.obj) to the IDE's settings
    2. Repeat step 1. for Win64
    3. Build and install up to 10 JCL Designtime package (the IDE plugins/experts)
    4. Build 28 JVCL runtime package and add their source path, library path and resource path (*.obj) to the IDE's settings
    5. Repeat step 4. for Win64
    6. Build and install 28 designtime package
    7. Repeat all steps for each installed Delphi version and skip the Win64 step if a Delphi version doesn't support it.

     

    And that is for one person. If you are in a team and have only one Delphi version installed then the multiplier is the size of your team.

     

    UPDATE: And not to forget. You need to compile the packages in the correct order because they depend on each other.

    • Haha 1

  3. Posted

    1 hour ago, Dave Novo said:

    per this post, it seems that many of the optimizations from IDEFixPack were ported to Delphi 10.4.2, but not the compileOnly (which is perfect for us BTW).

    https://blogs.embarcadero.com/delphi-10-4-2-compiler-speed-improvements/

    I wouldn't say "many". I would say "a hand full". But marketing is something else. None of the additional features was added. Actually only the patches that give the most performance boosts in usual cases were applied. (But reading the IDEFixPack source code isn't easy as it is a lot of assembler code)

  5. Posted

    You set the ColorMenu.Style to msOwnerDraw but then you don't implement the OnDrawItem and OnMeasureItem. So your menu items have a width of 0px and a height of 16px. And nothing is painted anyway because OnDrawItem is not assign. The "example form" creates its own style painter TJvXPColorMenuItemPainter and assigns it to ColorMenu.ItemPainter.

     

    So this is not a bug but a handling error.


      

    procedure TEditorMainForm.FormCreate(Sender: TObject);
...
begin
  ...
  ColorMenu.ItemPainter := TJvXPColorMenuItemPainter.Create(Self);
  BackgroundMenu.ItemPainter := TJvXPColorMenuItemPainter.Create(Self);

     

    • Thanks 1

  6. Posted

    43 minutes ago, Vincent Parrett said:

    Pity embarcadero don't ship map files for their bpl's - hmmm will log a qc for that - because as I dig deeper into my perf issues I end up in the weeds in rtl etc with func@xxx a lot. 

    They ship jdbg files with the BPLs and those are created with the JCL from the map files. So you can read them instead of the map file with the help of the JclDebug.pas (that also has a map file parser and a TD32 debug information parser).

     

    There are only two problems with that approach:

    1. The JclDebug API only has an "Address to ProcName/LineNum" function but doesn't give you access to the actual ProcNames and Lines lists. But you can change the code and access the private fields (TJclBinDebugScanner).
    2. The jdbg files for some files are from the debug build and don't match the actual release code (but that got a lot better in recent releases)  or they are from a broken Borland C++ compiler that generates map files with just wrong information (e.g. Delphi compilers).

  11. Posted · Edited by jbg

    TBytes suffers from being a dynamic array. If you set its length it will initialize the allocated memory with zeros. So if you allocate a TBytes array and then write data into it (from a file, other memory, socket) you don't need the zero-initialization because you overwrite them anyway. Unfortunately there is no "SetLengthUninitialized" function for TBytes that would get rid of the unnecessary ZeroMemory/FillChar call. I wrote my own function and patched all the TEncoding methods and use it in places were performance matter.

     

     

    I just saw that that was already mentioned in this thread.

  13. Posted

    The WebInstaller detection in IdeFixPack looks at a specific environment variable but that variable is also set of you start the IDE with Administrator rights or if some other program added the environment variable. (I don't remember what env-var it is and I don't the the source code at hand where I am right now)

     

    The WebInstaller detection code was removed in the last development snapshot:

    https://idefixpack.de/fixpack/dev

    But be aware that the development snapshot may crash the IDE more often as it is not tested.

    • Thanks 1

  14. Posted · Edited by jbg

    I have uploaded a new development snapshot for the (upcoming) IDE Fix Pack 6.5

    IDE Fix Pack Snapshot Download

     

    What's new:

    • Added: (IDE) Fix for RSP-23006: Edit controls in the ObjectInspector aren't clipped by the scrollbar anymore (10.3+)
    • Added: (IDE) The compile progress dialog is updated only every 80 ms now. And if a remote desktop session is detected it is only updated every 250 ms.
      The IDE compiler runs in the main thread, so every GUI update affects the compilation time.
    • Added: -x--jdbg compiler option extension that creates and attaches a jdbg-file.
      You don't need a detailed map file (-GD) anymore to create or attach a jdbg-file for the binary file.
      Attaching the jdbg PE section is done after the linker closed the binary file.
      -x--jdbg and -x--jdbg=1 create a jdbg-file
      -x--jdbg=2 attaches the jdbg data to the executable/dll/bpl.
      Question: "Why is the jdbg file smaller than my old file?" - Answer: "The old file was created with an older version of JclDebug.pas."
    • Added: -x--unitstats compiler option extension outputs unit filenames for units with "unitname in 'filename'" entries.
    • Added: -x-fvs compiler option extension also generates faster interface call stubs for virtual methods that are final or in a sealed class.
    • Added: Package compilation is a lot faster in the linker and cleanup phase.
    • Added: Faster ObjectTextToBinary (DFM) implementation by removing unnecessary string comparisons.
      This improves the linker's performance when it converts DFMs to resources.
    • Added: Faster map file creation by using a much faster Sort-By-Address implementation and a faster \n to \r\n converter.
    • Added: Faster unitname to unit filename resolving (unitname in 'filename')
      The compiler used a Byte as hash-value and a single linked list. The code is now replaced by a hash-map with a 32 bit hash-value.
    • Added: Faster compiler inline handling for projects with lots of units.
    • Added: The command line compiler uses a double linked unit list to remove and reorder items faster.
      The IDE compiler still uses the original single linked list because some other code in the IDE does something with it and I couldn't make it not crash.
    • Added: LoadString cache for compiler error/warning/hint messages.
      The compiler loads the warning/hint string and then decides not to show it. The cache prevents the compiler from calling LoadString too often.
    • Added: Some PAnsiChar/PWideChar RTL optimizations for the IDE and IDE Fix Pack.
    • Fixed: Compiler option extensions didn't work in dcc*.cfg and project.cfg files.
      Now you can specify -x-* options also in *.cfg files.
    • Fixed: Don't crash if a 3rdParty tool destroys the Castalia Clipboard Form.
    • Fixed: -x-cgo compiler option extension crashed the 10.3 compiler.
    • Removed: The "Exception catcher" patch for ErrorInsight is no more. It didn't have any functionality.

     

     

    • Like 4
    • Thanks 23

  15. Posted

    14 hours ago, Stefan Glienke said:

    Otherwise you get pro- and epilogue polluted with code that is not necessary in the majority of cases.

    At least it is not as performance damaging as preconditions. I remember the Indy project changed all the "if condition then raise" to something like "EIdException.RaiseIf(condition, ExceptionString-Concatenation)" in 2003/2004 and changed all that back because of the performance hit.

     

    And even in Java with a JIT-Compiler you shouldn't use preconditions if you don't know the effect it has: Somebody changed all the exception handling in a Base64 decoder to preconditions and the result was that converting a 500 MB file took hours instead of milliseconds. The garbage collector had to clean up all the strings that were created for every byte that was read and there were a lot of preconditions in the inner most loop.

  17. Posted

    This is no JclShell bug. It is a handling error. Your code mixes HotKey and ShortCut.

     

    THotKey.HotKey is not a (Windows) HotKey but a (Delphi) ShortCut. The IShellLink.GetHotKey function returns a (Windows) HotKey. Your "bug fix" code converts a HotKey to a ShortCut.

     

    If you look a the ComCtrls.pas TCustomHotKey class you'll see that the "HotKey: TShortCut" property's setter uses the private method ShortCutToHotKey to convert the specified ShortCut into a HotKey in order to send it to the HotKey-Control.

×