As a Delphi developer, you don’t get around objects. Creating and freeing them is an essential part of every Object Pascal based application. But now here comes a random guy telling you that you made your whole life a serious mistake at object management! Unbelievable, but hear me out, because you are going to thank me later on.

As you probably already know an object variable is essentially a pointer to the address where the memory for your instance is reserved. So creating an object returns the address and freeing an object marks the reserved memory as “not in use anymore”, but the object variable still contains the address to where the object originally was. And here comes the horror of object management in Delphi!
When you forget to nil the variable after freeing than you don’t know if it’s still valid, but that’s not even the worst that could happen. Imagine you have a business application where it’s critical that everything runs perfectly, but then out of nowhere your objects returns a number you can’t explain. It’s nothing you have ever seen and no one in your company can help you. Even worse; you can’t replicate the bug, but your customer/the user still gets this bug from time to time corrupting his data. I will leave it to your imagination what can happen when you have a 1 instead of a 0 in an application that decides between life and death.
But why can something like that happen just because I forgot to nil an object after freeing it?

The thing is that your program doesn’t care if the reserved memory of your object is valid or not. When it’s able to get what it wants, then it’s happy even if the memory got reserved and overridden by another instance.
This typically results in the well known access violation of reading/writing at address 80070010 (or something similar) and when you see something like this you really should freak out! This is obviously a bug where the application tries to access the memory of an object that got freed and it’s a miracle you accidentally found this because it’s completely random (well, not really random, but depending on your application you can interpret it as random) if this access violation happens.

Hint: An easy way to differentiate between a null-pointer access violation and an access violation because of freed memory is by looking at the address. When the address is a really small number (something like 00000004) then it’s a null-pointer access violation. Otherwise, it’s an access violation because of freed memory.

But how can I fix this memory madness?!
— Random stranger on the Internet

Forget the idea of using .Free! Yeah, it’s the time of object oriented programming, but no one wants bugs or write two lines of code when they can just write one.
So instead of writing

Object.Free;
Object := nil; // <- considering you even wrote this line

Just write

FreeAndNil(Object)

 

The thing is that FreeAndNil does nothing more than checking if your object is <> nil and if it is it calls .Free and sets it := nil.

Conclusion

So here is my advice; use FreeAndNil all the times when it’s possible. It’s not going to change the logic but help you find bugs before you deliver them out.

 

TL;DR

Use FreeAndNil(Object) instead of Object.Free to prevent data corruption and bugs that are gonna break your mind!

Ever wanted to use some fancy Unicode emotes in your Delphi application? Well good luck with that, because the RichEdit controls are using a library that’s so old it even supports Windows 95! An OS that had no support for more than 16 years (support ended December 31, 2001)!

So why isn’t embarcadero also dropping support for that and use a library for at least Windows XP (let’s be serious, enough people are still using it). The reason probably would be because either way embarcadero want’s to still support it (like Windows 3.11) or because Microsoft doesn’t offer really good alternatives.

So let’s look at the possibilities Microsoft gives us here; Looking at the MSDN-Page about the RichEdit-Control (https://msdn.microsoft.com/en-us/library/windows/desktop/bb787873(v=vs.85).aspx) we can see that it’s documented from version 1.0 (Windows 95) up to 4.1 (Windows XP), but aren’t there any other versions? I mean Microsoft can’t seriously not have updated their RichEdit-Control since Windows XP, right? They have! But not for everyone! If you want to use a version higher than 4.1 you would need Microsoft Office.

This is obviously not a solution having Microsoft Office as requirement for your application and embarcadero probably thinks the same way. So what are your solutions? Use the latest version you can use without worrying about too much! In this case it would be version 4.1 which also supports Unicode.

Getting RichEdit 4.1

To enable support for RichEdit 4.1 in your RichEdit-controls you need to load the library and tell your control to use another version:

unit UnicodeRichEdit;

interface

uses
  Vcl.Controls, Vcl.ComCtrls;

type
  TUnicodeRichEdit = class(TRichEdit)
  protected
    procedure CreateParams(var Params: TCreateParams); override;
  end;

implementation

uses
  System.Classes;

procedure TDSUnicodeRichEdit.CreateParams(var Params: TCreateParams);
begin
  inherited;
  // Tell the RichEdit control to use 4.1
  CreateSubClass(Params, 'RICHEDIT50W');
end;

var
  FRichEditUnicodeModule: HMODULE;

initialization
begin
  // Load the library
  FRichEditUnicodeModule := LoadLibrary('MSFTEDIT.DLL');
  if FRichEditUnicodeModule &amp;lt;= HINSTANCE_ERROR then
  begin
    raise Exception.Create('Could not load library "MSFTEDIT.DLL"!');
  end;
end;

finalization
begin
  // Free the library
  if FRichEditUnicodeModule &amp;lt;&amp;gt; 0 then
  begin
    FreeLibrary(FRichEditUnicodeModule);
  end;
end;

end.

Installation

A complete package ready to install is also available at GitHub: https://github.com/delphi-sucks/DSUnicodeRichEdit

  1. Download the latest version from https://github.com/delphi-sucks/DSUnicodeRichEdit/archive/master.zip
  2. Open the project-file “src/DSUnicodeRichEdit.dpk”
  3. Install it (right click on the project in the project overview and “Install”)
  4. Go to Tools > Options > Delphi Options > Library
  5. Add the path to the src folder to the Library-Path (repeat this step for every platform you want to use this component with)

Conclusion

It’s a bit tricky but with a small amount of code you can have Unicode emotes in your RichEdit control and also enjoy the old new features of version 4.1. If you are concerned about reliability then don’t worry; After a long period of use in a production environment I had no single error. You only have to consider that you need to have at least Windows XP otherwise it won’t run.

 

TL;DR

Have RichEdit-controls with Unicode support by using the DSUnicodeRichEdit package.

Wouldn’t it be nice if you could just make your Delphi IDE a bit more nice to look at? Well, when working with Delphi every day you really need something to get your thoughts of the frustration. So here is my recommendation for you!

The Ita-IDE plugin gives you the ability to set a custom background in the editor, so you have always something nice to look at.

Ita-IDE

 

Notes

You need to have at least Delphi XE2 to install it without modifying the source code.

It’s compatible with the newest version (at the time of writing) Delphi 10.2 Tokyo.

Installation

  1. Grab a copy of the source from github.com: https://github.com/lynatan/Ita-IDE-Plugin
  2. Open the project and install it as a plugin
  3. Done!

Configuration

To personalize the background just go to the settings at “Tools > Ita IDE Options”. There you can set your own image (better use one with a transparent background otherwise it will look weird), set the size, position and transparency.

 

TL;DR

Set a custom background with the Ita-IDE plugin.