The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,856 other followers

Archive for September 23rd, 2020

Delphi XE6 .. 10.1 Berlin truncating non-VCL-control texts to 256 characters when styled

Posted by jpluimers on 2020/09/23

As of Delphi XE6, the VCL also styles non-VCL controls, but this truncates the texts to 256 characters, for instance in non-balloon hints. This is fixed in Delphi 10.2 Berlin, by making the buffer dynamic and switching obtaining those texts from using GetWindowText to sending a WM_GETTEXT message.

A fix for Delphi XE6..10.1 Berlin is at gitlab.com/wiert.me/public/delphi/DelphiVclStylesAndHintText, with many thanks to Stefan Glienke who based the patch on the ones used in Spring4D. I think they are similar to the ones in [Archive.is] VCL Fix Pack 1.4 | Andy’s Blog and Tools.

The Old New Thing explains the difference between GetWindowText and WM_GETTEXT inΒ [WayBack] The secret life of GetWindowText – The Old New Thing. TL;DR:

GetWindowText strikes a compromise.

  • If you are trying to GetWindowText() from a window in your own process, then GetWindowText() will send the WM_GETTEXT message.
  • If you are trying to GetWindowText() from a window in another process, then GetWindowText() will use the string from the “special place” and not send a message.

So for your own process, it does not matter asΒ GetWindowText usesΒ WM_GETTEXT.

–jeroen

Related:

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development, The Old New Thing, Windows Development | Leave a Comment »

Must read post when using Git on line endings: What’s the best CRLF handling strategy with git? – Stack Overflow

Posted by jpluimers on 2020/09/23

Start with this must read post:Β cross platform – What’s the best CRLF handling strategy with git? – Stack Overflow.

Then read all the links in that answer, especially

Then see if you agree with my conclusion:

use aΒ .gitattributes file to steer line ending conversions on a per-repository base.

I usually try to have git not mess with any line endings: check-out as-is, check-in as is.

Historically this has been a mess (not limited to, but prevalent on Windows installations), not just because core.autocrlfΒ has been superseded by core.eol, so below are some links that will help.

TL;DR

Always execute these after installing git:

git config --global core.autocrlf false
git config --global core.eol native

If needed, repeat in the current repository:

git config --local core.autocrlf false
git config --local core.eol native

Finally verify the settings with git config --list --show-originΒ (via [WayBack] Where does git config –global get written to? – Stack Overflow)

Note

The git config listΒ will show equals signs. Do NOT use these when setting values: that will silently fail.

So these fail:

git config --global core.autocrlf=false
git config --global core.eol=native

git config --local core.autocrlf=false
git config --local core.eolnative

Despite the output when listing on a machine that already had these values et:

git config --list | grep -w 'core.autocrlf\|core.eol'
core.autocrlf=false
core.eol=native
core.autocrlf=false
core.eol=native

References

  • [WayBack]Β Dealing with line endings – User Documentation
  • [WayBack]Β Git – gitattributes Documentation: text:
    • core.autocrlfΒ overridesΒ core.eol
    • Unsetting theΒ textΒ attribute on a path tells Git not to attempt any end-of-line conversion upon checkin or checkout.
    • IfΒ core.safecrlfΒ is set to “true” or “warn”, git verifies if the conversion is reversible for the current setting ofΒ core.autocrlf. For “true”, git rejects irreversible conversions; for “warn”, git only prints a warning but accepts an irreversible conversion.
  • [WayBack]Β Git – gitattributes Documentation: end of line conversion
  • [WayBack]Β Source: Git – git-config Documentation: core.eol
  • [WayBack]Β Source: Git – git-config Documentation: core.autocrlf
  • [WayBack]Β Source: Git – git-config Documentation: core.safecrlf
  • [WayBack] line endings – Why should I use core.autocrlf=true in Git? – Stack Overflow
  • [WayBack] newline – How line ending conversions work with git core.autocrlf between different operating systems – Stack Overflow 
    •                  | Resulting conversion when       | Resulting conversion when 
                 | committing files with various   | checking out FROM repo - 
                 | EOLs INTO repo and              | with mixed files in it and
                 |  core.autocrlf value:           | core.autocrlf value:           
--------------------------------------------------------------------------------
File             | true       | input      | false | true       | input | false
--------------------------------------------------------------------------------
Windows-CRLF     | CRLF -> LF | CRLF -> LF | as-is | as-is      | as-is | as-is
Unix -LF         | as-is      | as-is      | as-is | LF -> CRLF | as-is | as-is
Mac  -CR         | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF    | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF+CR | as-is      | as-is      | as-is | as-is      | as-is | as-is
    • I explored 3 possible values for commit and checkout cases and this is the resulting table: 
      ╔═══════════════╦══════════════╦══════════════╦══════════════╗
β•‘ core.autocrlf β•‘     false    β•‘     input    β•‘     true     β•‘
╠═══════════════╬══════════════╬══════════════╬══════════════╣
β•‘   git commit  β•‘ LF => LF     β•‘ LF => LF     β•‘ LF => CRLF   β•‘
β•‘               β•‘ CR => CR     β•‘ CR => CR     β•‘ CR => CR     β•‘
β•‘               β•‘ CRLF => CRLF β•‘ CRLF => LF   β•‘ CRLF => CRLF β•‘
╠═══════════════╬══════════════╬══════════════╬══════════════╣
β•‘  git checkout β•‘ LF => LF     β•‘ LF => LF     β•‘ LF => CRLF   β•‘
β•‘               β•‘ CR => CR     β•‘ CR => CR     β•‘ CR => CR     β•‘
β•‘               β•‘ CRLF => CRLF β•‘ CRLF => CRLF β•‘ CRLF => CRLF β•‘
β•šβ•β•β•β•β•β•β•β•β•β•β•β•β•β•β•β•©β•β•β•β•β•β•β•β•β•β•β•β•β•β•β•©β•β•β•β•β•β•β•β•β•β•β•β•β•β•β•©β•β•β•β•β•β•β•β•β•β•β•β•β•β•β•
  • [WayBack] windows – Why does git keep messing with my line endings? – Stack Overflow
  • [WayBack] Mind the End of Your Line βˆ™ Adaptive Patchwork
  • [WayBack] Configuring how line-endings are handled by git – SCAPE – Confluence

–jeroen

PS: To look at the various local and global settings, readΒ Where does git config –global get written to? – Stack Overflow.

Posted in Development, DVCS - Distributed Version Control, git, Software Development, Source Code Management | Leave a Comment »

Can we truly assert that an array returned from a function is always a true copy?

Posted by jpluimers on 2020/09/23

The answer is no: [WayBack] Hi all, Can we truly assert that an array returned from a function is always a new true copy and that this is guaranteed to not change in between compil… – Ugochukwu Mmaduekwe – Google+

From PrimoΕΎ book and comment:

Primož Gabrijelčič

Depending on how you create this array.

For example, the following code outputs 42, not 17.

program Project142;

{$APPTYPE CONSOLE}

{$R *.res}

uses
System.SysUtils;

function Bypass(const a: TArray<integer>): TArray<integer>;
begin
Result := a;
end;

var
a, b: TArray<integer>;

begin
SetLength(a, 1);
a[0] := 17;
b := Bypass(a);
a[0] := 42;
Writeln(b[0]);
Readln;
end.

You can use `SetLength(arr, Length(arr))` to make array unique. Changing Bypass to the following code would make the test program emit 17.

function Bypass(const a: TArray<integer>): TArray<integer>;
begin
Result := a;
SetLength(Result, Length(Result));
end;

–jeroen

Posted in Delphi, Development, Software Development | 1 Comment »

 
%d bloggers like this: