Code

Type-Inference in Generic Methods

Due to an interesting code example, behind which Kim Madsen first suspected a possible bug in the Delphi compiler, I took a closer look at the calling behavior of overloaded methods that also contain generic type parameters. I was surprised by the possible bug since I use overloads with combinations of generic and non-generic methods in current projects without any obvious errors.

Here is a simplified version of Kim’s code:

TFoo = class(TObject)
  public
    function DoSomething(SomeObject: TValue): string; overload;
    function DoSomething<T>(SomeObject: T): string; overload;
  end;

TBar = class(TObject)
end;

//...

var Foo := TFoo.Create;
var Bar := TBar.Create;

Foo.DoSomething(Bar);

Which of the two possible variants of DoSomething should be called by Foo.DoSomething(Bar)?

At a first glance, I was inclined to say that the non-generic variant, i.e. function DoSomething(SomeObject: TValue): string; should be called, since after all no type parameter is specified and therefore the first variant matches best.

But in fact, the generic, second variant is called. I initially suspected “TValue” of “blocking” the overload resolution here, since TValue is actually an “artificial” RTTI.driven type.

Stefan Glienke came up with the correct hint:

Generic parameters are actually optional and the type is automatically inferred by the type of the variable that is passed. This “type inference” takes precedence over overload resolution and thus produces a better match than the “TValue” method.

Type-inference of generic methods is documented here btw.

So the following code actually calls a generic implementation, although no type parameter is specified in the call:

function DoSomething<T>(SomeObject: T): string;
//...
Foo.DoSomething(Bar); //<T> is inferred from "Bar"

Here is a Gist with full code to try:

https://gist.github.com/omonien/24b9b4ba64d46bdfa478615e8e9b0ae6

Embarcadero to Sponsor Open Source Projects

With the upcoming RAD Studio 10.4 Sydney, Embarcadero will launch a sponoring program for open source libraries.

There are essentially two basic requirements:

  • The project must be published on Github
  • The project must be in Delphi or C++Builder code and work with 10.4

The sponsoring is explicitly not only limited to “warm words” but financial support is also promised. I assume that you won’t get rich from it, but they explicitly ask for a development plan and the costs involved.

In the following Google Document you will find all details:

https://docs.google.com/document/d/e/2PACX-1vRSZwkszUzgFeEFyZXS2Q6N88XDz6JpdiJxxLXktRGUTWzHcR6zyRRXprAH-dqSl91gW-HfeaxUWtGc/pub

Signing Windows Delphi Applications

FireMonkey apps for iOS and Android are automatically signed during the deployment process in Delphi – this is especially important for iOS apps and was therefore implemented in the Delphi IDE.

For Windows applications (no matter if 32 or 64 bit) there is no signature option in Delphi. This might lead to many Delphi apps being distributed unsigned. However, this is no longer recommended for Windows 10 or later, because the “SmartScreen-Filter” introduced with Windows 10 blocks “untrusted” applications by default. An unsigned application (EXE) is per se “untrustworthy”, because its origin cannot be verified.

Read More

Firemonkey TMemo Scrolling

When you add lines to a TMemo in Delphi Applications, then you might want to scroll to the very end of that particular Memo, so that the newest lines are kept in view.

In FireMonkey it’s as easy as just calling GoToTextEnd:

procedure TFormMain.AddLog(AMessage: string);
begin
  Memo1.Lines.Add(AMessage);
  Memo1.GoToTextEnd;
end;

You might notice though, that when you clear the Memo at certain times, the scrollbars may get out of sync. To avoid that, you need to call ProcessMessages right after “clear”. Apparently the scrollbars get confused, when you add lines directly after clear command, because the actual position needs to be rendered first (which the ProcessMessages does).

procedure TFormMain.AddLog(AMessage: string);
begin
  if Memo1.Lines.Count > 100 then 
    begin
      Memo1.Lines.Clear;
      Application.ProcessMessages; //without this, scrollbars will show wrong size/position
    end;
  Memo1.Lines.Add(AMessage);
  Memo1.GoToTextEnd;
end;

MVVM Anwendungen mit Delphi und nicht gegen Delphi

Im folgenden Video meines Youtube-Kanals eine Einführung zum Thema MVVM Anwendungen mit Delphi. Wichtige Motivation ist für mich, dass ich soviel Delphi wie möglich verwende, also eben nicht anfange, alles von Hand im Source-Editor hinzuschreiben.

Hinweis: Das Video versteht sich als erste Einführung in das Thema MVVM mit Delphi. Selbstverständlich gibt es noch eine ganze Reihe von Dingen, die man optimieren und ausbauen kann. Weitere Schritte werde ich hier in noch folgenden Beiträgen skizzieren.

Das Video ist in Deutsch.




Wir benutzen Cookies um die Nutzerfreundlichkeit der Webseite zu verbessen. Durch Deinen Besuch stimmst Du dem zu.