The Wiert Corner – irregular stream of stuff

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

  • My badges

    Mastodon

  • 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,947 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

–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: