The Problem

Effectively, “records with methods” treat all record “const” elements as “var“, even when they shouldn’t, and effectively ignores the compiler option “assignable constants”. Witness the following record:

[delphi]type
   TRec = record
      Field : Integer;
      procedure IncMe;
   end;
…
procedure TRec.IncMe;
begin
   Inc(Field);
end;[/delphi]

Then the compiler will happily allow you to do:

[delphi]const MyNullRec : TRec = (Field: 0);
…
MyNullRec.IncMe; // watch me, I’m magic!
WriteLn(MyNullRec.Field); // will write 1 ![/delphi]

…it will also accept…

[delphi]procedure Myproc(const r : TRec);
begin
   r.IncMe; // modified whatever r as if it had been a var
end;[/delphi]

…and that as well…

[delphi]type
   TMyClass = class
      private
         FRec : TRec;
         procedure SetRec(const aRec : TRec);
      public
         property RW : TRec read FRec write SetRec;
         property RO : TRec read FRec;
   end;
…
var myClass : TMyClass;
…
// everything’s as it should be there
myClass.RO := aRec; // gives an error
myClass.RW := aRec; // uses SetRec
// but that compiles to…
myClass.RO.IncMe; // modifying a read-only property !
myClass.RW.IncMe; // modifies and bypasses SetRec ![/delphi]

It would “compile” even if the getter was a function returning a record… or just in about any case, really.

And of course you can cascade all the above in a real-world case, so you end up with weird side-effects and really hard-to-track down bugs.

Besides bug, that also raises the issue of usability of records like TPoint and other simple vector/matrix types, as properties of objects. As long as they did not have methods, you would have to use the setter to modify such a property, so the objects had guaranteed notification of a position change f.i., with methods being able to magically mutate the records, you no longer have that guarantee. And adding all the baggage so that a TPoint can be owned and notify its owner of a change would be over-the-top, wouldn’t it?

What’s Missing

Two syntax elements are missing:

• the ability to specify if a method is mutating the record or not, ie. if it should get “Self” as a “var” or as a “const“, so that you can make the above behavior explicit, and the compiler can emit errors when it’s not appropriate
• the ability to mark a record as mutable/immutable, to further remove the ambiguities

Ideas for such a syntax, in explicit form, and reusing existing keywords:

[delphi]type
   TRec = record
      Field : Integer;
      var procedure IncMe; // mutating
      const function ToString : String; // non-mutating
   end;[/delphi]

Modifiers in Pascal (except “class“) usually follow the declaration, but “var” and “const” can’t, as they could be ambiguous with the declaration of a following constant/variant. So if reusing those, rather than introducing new keywords, they have to be in front.

Also you could mark a record as explicitly mutable or immutable, by prefixing it with “var” or “const”

[delphi]type
   TImmutableRec = const record
      Field : Integer;
      var procedure IncMe; // mark as explicitly mutating ?
      function ToString : String; // non-mutating by default
   end;
   TMutableRec = var record
      Field : Integer;
      procedure IncMe; // implicitly mutating
      const function ToString : String; // mark as explicitly non-mutating
   end;[/delphi]

For backward compatibility with existing records with methods, the implicit default would have to be “var record” as the records are currently all mutable.

With that extra information, the compiler could then perform proper checks and proper parameter passing, so the side-effects mentioned could happen only if you explicitly went for them, rather than by mistake as is currently the case.

Additionally, immutable records would implicitly have their fields as read-only everywhere outside the record constructor (which would then become truly useful as language syntax element). It might also be possible to extend the syntax to be able to declare explicitly immutable classes.

View Full Article 

+ You can select which components you want to compile and install
+ Once installed you can change the sources and relaunch the Setup to recompile
+ Relaunching the Setup you can also add/remove installed components and modify installation options
+ If Setup isn’t able to compile the packages you can check the DCC log
+ If you have a trial IDE you will be explicitly notified

Download Links:
M1
M2

This is a stable RealThinClient SDK release, polished and stress-tested to work reliably on Win32, Win64, MacOSX and iOS platforms:
* using Delphi 6 – XE: Win32 support
* using Delphi XE2 with the RTL / VCL: Win32 and Win64 support
* using Delphi XE2 with FireMonkey: Win32, Win64, Mac OSX and iOS support
- Mac OSX 10.6 or later required for Mac OSX development
- Mac OSX 10.6 or later with XCode 4.1 or later and an active Apple Developer program required for iOS development
Download Links:
M1
M2

The TSplitter divides the client area of a control (the one like TPanel or TForm accepting other controls) into resizable panes. Having the splitter between two aligned controls allows users to resize the controls at runtime.

Imagine two panels on a form. The first panel is aligned to the top of the form (Align property = alTop), the second panel fills the rest of the client area of the form (Align = alClient). Having a splitter (Align = alTop) control between them, when the user moves the splitter, it resizes the panels.

A Grab Bar?

Having complex screen designs, it is sometimes hard for a user to see if there’s a splitter between two controls. Ok, when the user passes the mouse pointer over the Splitter control, the cursor changes (to crHSplit or crVSplit) to indicate that the controls above/below or to left/right can be resized.

When there are lots of panels and UI elements that can be resized – there would be lots of splitters and the user would need to move the mouse over the splitter to see that there is a splitter actually there (as the default splitter painting does not “stand out” the splitter).

How about doing some custom splitter painting to draw something like a drag bar – so that splitters are more visible to the user?

[delphi]type
  TSplitter = class(ExtCtrls.TSplitter)
  private
    fMouseIn: boolean;
    property MouseIn : boolean read fMouseIn;
    procedure CMMouseEnter(var AMsg: TMessage); message CM_MOUSEENTER;
    procedure CMMouseLeave(var AMsg: TMessage); message CM_MOUSELEAVE;
  protected
    procedure Paint; override;
  end;[/delphi]

[delphi]

procedure TSplitter.CMMouseEnter(var AMsg: TMessage);
begin
  fMouseIn := true;
  Refresh;
end;

procedure TSplitter.CMMouseLeave(var AMsg: TMessage);
begin
  fMouseIn := false;
  Refresh;
end;

procedure TSplitter.Paint;
var
  R: TRect;
  X, Y: integer;
  DX, DY: integer;
  i: integer;
  Brush: TBitmap;
  dTo : integer;
begin
  //inherited NO
  //Beveled property = FALSE (never mind what has been set)

  R := ClientRect;
 
  Canvas.Brush.Color := Color;
  Canvas.FillRect(ClientRect);

  X := (R.Left+R.Right) div 2;
  Y := (R.Top+R.Bottom) div 2;
  if (Align in [alLeft, alRight]) then
  begin
    DX := 0;
    DY := 3;
  end
 else
  begin
    DX := 3;
    DY := 0;
  end;

  Brush := TBitmap.Create;
  try
    Brush.SetSize(2, 2);
    Brush.Canvas.Brush.Color := clBtnHighlight;

    Brush.Canvas.FillRect(Rect(0,0,1,1));

    if MouseIn then
    begin
      Brush.Canvas.Pixels[0, 0] := clBtnText;
      dTo := 9;
      dec(X, DX*4);
      dec(Y, DY*4);
    end
    else
    begin
      Brush.Canvas.Pixels[0, 0] := clBtnShadow;
      dTo := 4;
      dec(X, DX*2);
      dec(Y, DY*2);
    end;

    for i := 0 to dTo do
    begin
      Canvas.Draw(X, Y, Brush);
      inc(X, DX);
      inc(Y, DY);
    end;
  finally
    Brush.Free;
  end;

  //no raising of OnPaint
end;

[/delphi]

Upgrade Your Delphi Application Resizable User Interface In Seconds

New features

Exception handling added to Parallel.Async.
Task property added to the IOmniWorkItem interface.
Added TOmniValueObj class, a class wrapper for TOmniValue record.

read More

The other 2 changes are IDE and compiler performance optimizations. ErrorInsight caused my directory cache to reset itself for every DCU file the parser wants to read (ErrorInsight reinitialized the compiler for every file; that’s what happens if you have 1 compiler and multiple consumers). With version 4.9 the directory cache is only reset if the “consumer” changes.

The second performance patch removes the HelpInsight parser invocation in the main thread from the OnUpdate handler of the View/HelpInsight menu item’s action and puts it into the OnExecute handler. This solves a performance issue I experienced all the time when I opened a large project and pressed Ctrl+F12 (Search Unit) while the FormDesigner was active. The IDE stopped responding and parsed the whole application in the main thread (<= OnUpdate). Now the HelpInsight parser starts if you press Ctrl+Shift+H. And you can press ESC to cancel it.

Download D2007-XE2

As an example, instead of using the TObjectList type to have a list of any object types, from Delphi 2009, the Generics.Collections unit defines a more strongly typed TObjectList.

Simple Generics Type Example

Here’s how to define a simple generic class:
[delphi]type
  TGenericContainer<T> = class
  Value : T;
 end;[/delphi]

With the following definition, here’s how to use an integer and string generic container:

[delphi]

var
  genericInt : TGenericContainer<integer>;
  genericStr : TGenericContainer<string>;
begin
  genericInt := TGenericContainer<integer>.Create;
  genericInt.Value := 2009; //only integers
  genericInt.Free;

  genericStr := TGenericContainer<string>.Create;
  genericStr.Value := ‘Delphi Generics’; //only strings
  genericStr.Free;
end;

[/delphi] 

The above example only scratches the surface of using Generics in Delphi (does not explain nothing though – but above articles have it all you want to know!).

For me, generics were the reason to move from Delphi 7 / 2007 to Delphi 2009 (and newer).

this article is from:Understanding Generic Types in Delphi

While I was working on my favorite personal project I realised which the TWebBrowser embedded in one of my forms doesn’t look very nice when the vcl styles are enabled. So I decide write a fix.

My main goal was skin the scrollbars of the TWebBrowser component which by default uses the native windows look and feel.

Author Blog

Extend the Delphi VCL Styles

+ Added a Images property in the class TEditButtonEh (TDBEditEh.EditButtons[i].Images) of a TEditButtonImagesE type.

TEditButtonImagesEh = class(TPersistent)
published property NormalImages: TCustomImageList;
property HotImages: TCustomImageList;
property PressedImages: TCustomImageList;
property DisabledImages: TCustomImageList;
property NormalIndex: Integer;
property HotIndex: Integer;
property PressedIndex: Integer;
property DisabledIndex: Integer;
end;

Now it is allowed to draw Images from ImageList in EditButtons of Edit controls and columns of TDBGridEh. Images are drawn when TEditButtonEh.Style = ebsGlyphEh and TDBEditEh.EditButtons[i].Images.NormalImages is assigned.
Download Links:
M1