The Wiert Corner – irregular stream of stuff

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

  • My badges

    Mastodon

  • Twitter Updates

  • Pages

  • All categories

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

    Join 1,854 other subscribers

Archive for the ‘Delphi’ Category

« Previous Entries
Next Entries »

DPI aware Vcl applications and use Vcl Styles

Posted by jpluimers on 2020/01/28

For my link archive: [WayBack] Do you want to produce DPI aware Vcl applications and use Vcl Styles?… – Kiriakos Vlahos – Google+

Source at [WayBack] pyscripter/VCL.Styles.DPIAware.pas at master · pyscripter/pyscripter · GitHub

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »

If your tool depends on others, at least search for them…

Posted by jpluimers on 2020/01/23

If you auto-configure, then at least try searching the tools you need:

[WayBack] Yeah right Delphi 10.2 Tokyo (for which the shortcut – unlike the Berlin one – does not contain the word Tokyo), they are right on the Windows PATH wher… – Jeroen Wiert Pluimers – Google+

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »

Delphi developer switching to C# – Stack Overflow

Posted by jpluimers on 2020/01/23

Another blast from the past. I’ve been using many development environment all my live, so I have been using .NET very early on allowing me to make a good comparison: [WayBack] Delphi developer switching to C# – Stack Overflow.

I have a broad toolbox because we’ve never lived in a “silver bullet” era: any problem needs a combination of tools to solve them. Having a broad toolset allows you to pick and choose more easily. Mastering the different tools however requires a lot of effort and time. You really need to love this profession to put that energy in it.

I heavily use both for software development.

Development speed of server apps (web apps, web services, windows services) is much higher in .NET.

Development speed of business apps (pure Windows UI) is much higher in Delphi.

Development of sexy apps is a pain in both environments.

A few things you should know:

  • Learning the .NET framework will take a lot of time: it is huge, but contains a lot of gizmos (some gems are really well hidden).
  • Don’t lose yourself in following all new trends at once: generics, lambda, LINQ, each are nice, but grasping them all at once is only for a few of us
  • For web apps, skip WebForms, but learn ASP.NET MVVC (yes, the Ruby guys were right after all); learn HTML 5 and JavaScript too.
  • For sexy Windows apps, learn WPF, but be prepared for a steep learning curve (designer, and framework are radically different)
  • Don’t get a too sexy UI: it costs you a disproportional amount of time while your users are waiting for functionality
  • Like the market has been bashing Delphi since version 1, the market is bashing SilverLight too
  • Skip WinForms; if you need something like WinForms, then Delphi is way more productive (even more so if you have an existing Delphi VCL codebase).
  • WPF is just as thread-friendly as the VCL or WinForms (read: neither of the 3 is thread friendly)
  • Don’t perform rewrites of your Delphi stuff in .NET (or for that matter any other 1:1 rewrite from platform A into platform B): it is a waste of your time.
  • Threading and synchronization are a pain in all development environments. The pain is not so much in the general stuff (the Concurrent Collections in the .NET 4 framework helps, as do the Delphi OmniThreadLibrary), but in getting the final details and exception cases right is the real pain.
  • Garbage collection does not mean that you won’t leak memory: it means that you won’t leak when your app terminates, but while it runs the leaks are way harder to detect (boy, I wish I had the FastMM memory monitor for .NET)

–jeroen

Posted in .NET, C#, Delphi, Development, Software Development | 3 Comments »

Delphi / Visual Studio build events: xcopy exit code 9009; ensure your PATH indeed includes the Windows directories

Posted by jpluimers on 2020/01/22

If you ever get an exit code 9009 from xcopy like the one below, then try using the full path to xcopy. It should be there, it should not matter, but it does if someone changed your path.

[Exec Error] The command " xcopy ....\Shared\DLL\FastMM\FastMM_FullDebugMode.dll .\Win32\Debug\ /y&& xcopy ....\Shared\DLL\OpenSSL\libeay32.dll .\Win32\Debug\ /y&& xcopy ....\Shared\DLL\OpenSSL\ssleay32.dll .\Win32\Debug\ /y&& xcopy ....\Shared\DLL\gRPC\nghttp2.dll .\Win32\Debug\ /y&& xcopy ....\Shared\DLL\gRPC\sgcWebSockets.dll .\Win32\Debug\ /y" exited with code 9009.

Preliminary solution: replace xcopy    with C:\Windows\System32\xcopy.exe .

Final solution: look with Process Explorer and Process Monitor what the exact environment PATH is. It should include C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;

If it does not, then find out what is changing your path.

Related:

–jeroen

Posted in .NET, Delphi, Development, Software Development | Leave a Comment »

The intrinsic factory pattern that every Delphi programmer uses

Posted by jpluimers on 2020/01/22

A blast from the past: my 2009 answer to [WayBack] What Design Patterns do you implement in common Delphi programming? – Stack Overflow which is still very much relevant today.

TL;DR

Every Delphi programmer uses the factory pattern as it is an intrinsic part of how components at design time work.

So he were go:

Only a minority of the Delphi developers knows that every Delphi developer uses a Factory pattern (delphi.about.com has an example in “regular” Delphi), but then implemented using virtual Create constructors.

So: time to shed some light on that :-)

Virtual constructors are to classes like virtual methods are like object instances.

The whole idea of the factory pattern is that you decouple the logic that determines what kind (in this case “class”) of thing (in this case “object instance”) to create from the actual creation.

It works like this using virtual Create constructors:

TComponent has a virtual Create constructor so, which can be overridden by any descending class:

type
  TComponent = class(TPersistent, ...)
    constructor Create(AOwner: TComponent); virtual;
    ...
  end;

For instance the TDirectoryListBox.Create constructor overrides it:

type
  TDirectoryListBox = class(...)
    constructor Create(AOwner: TComponent); override;
    ...
  end;

You can store a class reference (the class analogy to an object instance reference) in a variable of type ‘class type’. For component classes, there is a predefined type TComponentClass in the Classes unit:

type
  TComponentClass = class of TComponent;

When you have a variable (or parameter) of type TComponentClass, you can do polymorphic construction, which is very very similar to the factory pattern:

var
  ClassToCreate: TComponentClass;

...

procedure SomeMethodInSomeUnit;
begin
  ClassToCreate := TButton;
end;

...

procedure AnotherMethodInAnotherUnit;
var
  CreatedComponent: TComponent;
begin
  CreatedComponent := ClassToCreate.Create(Application);
  ...
end;

The Delphi RTL uses this for instance here:

Result := TComponentClass(FindClass(ReadStr)).Create(nil);

and here:

// create another instance of this kind of grid
SubGrid := TCustomDBGrid(TComponentClass(Self.ClassType).Create(Self));

The first use in the Delphi RTL is how the whole creation process works of forms, datamodules, frames and components that are being read from a DFM file.

The form (datamodule/frame/…) classes actually have a (published) list of components that are on the form (datamodule/frame/…). That list includes for each component the instance name and the class reference. When reading the DFM files, the Delphi RTL then:

  1. finds about the components instance name,
  2. uses that name to find the underlying class reference,
  3. then uses the class reference to dynamically create the correct object

A regular Delphi developer usually never sees that happen, but without it, the whole Delphi RAD experience would not exist.

Allen Bauer (the Chief Scientist at Embarcadero), wrote a short blogarticle about this topic as well. There is also a SO question about where virtual constructors are being used.

Let me know if that was enough light on the virtual Create constructor topic :-)

This resulted in this interesting comment by Kenneth Cochran:

Factory pattern implementations in other languages use ordinary static functions (or class functions for pascalites). As such they are capable of returning null(nil). A Delphi constructor, like the nameless constructors in other languages, will always return an object reference unless you raise an exception. You are free, of course, to use a class function just as easily if the need arises.

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »

Delphi, compiler intrinsics and generic type matching

Posted by jpluimers on 2020/01/21

For my link archive in case I ever need to do Delphi generic type matching on intrinsic types. This will be tricky as you can have typed types like [WayBack] type TDate = type TDateTime since the early Delphi ages.

[WayBack] Hi, by using compiler intrinsics, is it possible to check if a generic type parameter is an unsigned integer? – Malcon X Portela – Google+

It will probably come down to fast intrinsic type mapping and slower typed type mapping.

The above WayBack link contains the most important bits of the Google+ post:

Malcon X Portela, Delphi Developers, 2 Jan 2018

Hi, by using compiler intrinsics, is it possible to check if a generic type parameter is an unsigned integer? I have the following code:

function TChecker<T>.CheckIsUnsigned: Boolean;
begin
  if GetTypeKind(T) = tkInteger then
  begin
  if SizeOf(T) = 4 then
  begin
    // TODO: Check if it is an unsigned 32-bit integer
    Result := True;
  end else if SizeOf(T) = 2 then
  begin
    // TODO: Check if it is an unsigned 16-bit integer
    Result := True;
  end else
  begin
    // TODO: Check if it is an unsigned 8-bit integer
    Result := True;
  end;
  end else
  begin
    Result := False;
  end;
end;

The code should return True only if the ‘T’ generic type parameter is an unsigned integer. I remember that +Stefan Glienke posted here some code that can do this trick, however, I am not able to find that now.

Thanks!

Malcon X Portela+1

Hi +Jeroen Wiert Pluimers, my answer can be a bit disappointing, sorry :( Some time after writing this question here, I just realized which for the things I was originally trying to do, being signed or unsigned would not change anything on the final result hehehehe :D But from this amazing project https://github.com/d-mozulyov/Rapid.Generics (entire credits goes to Dmitry Mozulyov for the magic), it is possible to write the check to the generic type parameter in order to identify if it is a 32-bit/64-bit signed or unsigned number.

LTypeData := PTypeInfo(TypeInfo(T)).TypeData;

case GetTypeKind(T) of
  tkInteger:
  begin
    {case LTypeData.OrdType of
      otSLong: Writeln('32-bit signed');
      otULong: Writeln('32-bit unsigned');
    end;}
    // the above code does the same thing
    if LTypeData.MaxValue > LTypeData.MinValue then
    begin
      Writeln('32-bit signed');
    end else
    begin
      Writeln('32-bit unsigned');
    end;
  end;
  tkInt64:
  begin
    if LTypeData.MaxInt64Value > LTypeData.MinInt64Value then
    begin
      Writeln('64-bit signed');
    end else
    begin
      Writeln('64-bit unsigned');
    end;
  end;
end;

The [WayBack] Rapid.Generics project is indeed cool, but unmaintained and has no unit tests. The main code is in some [Wayback] 30k lines Rapid.Generics.pas unit with some cool ideas and implementations. Hopefully people will find time to integrate some of the ideas there into basically the only well maintained Delphi generics library Spring4D.

A big limitation might be that the code is Delphi XE8 and up only, whereas Spring4D supports older Delphi versions.

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

Delphi: A few notes on tracking down a use-after free related issue involving interfaces crashing inside System._IntfClear.

Posted by jpluimers on 2020/01/20

A few notes on tracking down a use-after free related issue involving interfaces.

The crash message is like this:

Project UseAfterFreeWithInterface.exe raised exception class $C0000005 with message 'access violation at 0x004106c0: read of address 0x80808088'.

Two things here:

An important note first

Basically any memory value in an exception starting with $8080 and sometimes even $80 should raise suspicion: it usually means a use-after-free case.

You see these errors with FastMM and not with the memory manager as [WayBack] delphi • View topic • Problem with FastMM and D7 explains:

Read the rest of this entry »

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | 8 Comments »

Tweaking4All.com – Topics – Delphi – How to change the font of a hint window

Posted by jpluimers on 2020/01/19

[WayBack] Tweaking4All.com – Topics – Delphi – How to change the font of a hint window: Delphi THintWindow are odd, as you cannot set the Vcl.Forms.HintWindowClass before uses it to initialise the hint window in the Application instance from the initialisation section in the Vcl.Forms unit.

The only way to change it is to:

  1. Set the HintWindowClass to a new class
  2. Toggle the state of Application.ShowHint

So the duplicate line below is no accident:

  HintWindowClass := TMyHintWindow;
  Application.ShowHint := not Application.ShowHint;
  Application.ShowHint := not Application.ShowHint;

References:

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »

Drawbacks for separating TDS/TD32 symbol information in separate file for your Delphi applications? What about Visual Studio?

Posted by jpluimers on 2020/01/15

A while ago this interesting question came by: [WayBack] Delphi XE2 has got the Linking option “Place debug information in separate TDS file” … Does this have any adverse effects for Win32 Delphi executables? – Thomas Mueller (dummzeuch) – Google+

The answer is “no”.

By about mid 2018, the same holds for Visual Studio and PDB symbol information.

Delphi

Since long ago (I think about Delphi 2), the Delphi debugger understands TDS (historically also known as TD32) Turbo Debugger Symbol Information which can be either in the .EXE or in a separate .TDS file with the same name and directory as the .EXE.

Many other tools also know how to get the symbols from either place, see for instance TD32-TDS-SYMBOL-INFORMATION.

The advantage of keeping it in the EXE is that it is easier to ship to clients. Unless you do not want the clients to have it. Then it is easier to separate it in a file.

David Heffernan raises an important point though, as many people confuse these two topics:

  • the presence of Debug Symbols
  • the code generation of extra run-time checks and debug-assistance (like stack frames)

This is caused by both of the above usually being enabled in DEBUG mode and disabled in RELEASE mode.

However, nothing prevents you from generating the Debug Symbols in RELEASE mode, and they can highly help track down customer problems.

This is David’s comment:

There’s a common myth that “debug builds” perform worse than “release builds”.

Whether or not debug information is generated is completely independent from the performance of the code.

Visual Studio

For a long time, EXE files generated by Microsoft Tools could only include .DBG symbol information, but no .PDB symbol information.

[WayBack] executable – Embed .pdb debug symbol information into an .exe file in Visual Studio – Stack Overflow. Especially read the comments about:

–jeroen

Posted in Debugging, Delphi, Development, MAP Symbol Information, Software Development, TD32/TDS Symbol information | Leave a Comment »

Delphi Datasnap: How to know the name of the methods called by client in delphi datasnap server?

Posted by jpluimers on 2020/01/14

A great tip from [WayBack] Hi, need help regarding Datasnap. How to know the name of the methods called by client in delphi datasnap server? – sujansiddhi – Google+ that I needed a few months ago:

Walter Prins:

Inside TDSAuthenticationManager.OnUserAuthorize, inspect the EventObject.MethodAlias property. (Obviously once the method is actually called you implicitly know the methodname.)

This was introduced in Delphi XE:

–jeroen

Posted in Delphi, Development, Software Development | Leave a Comment »

« Previous Entries
Next Entries »