program begin end. // comments?

My Job Is To Meet Expectations

2014-11-11T01:06:00.000+01:00

This is a reply to the article Your Job Is Not to Write Code by +Laura Klein.

It IS my job to write code. That code has to meet the expectations of the end users, the product manager (PM), the Quality Assurance Manager (QM), the support team, and myself.

The PM has to set the bar. Functionally and performance wise. If the PM leaves it up to me to decide what the code should run on, on what kind of hardware, that PM is not filling the role. The PMs are the ones that set the targets.

In a proper development team, it is NOT the developers job to test that the code runs on all variants of hardware. This is where you have testers, and a PM and a QA Manager (QM) that define the bar of what is acceptable function and performance in accordance with the specification you created.

The developer may be given his/her own test machine which can be used for “worst case” scenarios, but it is the test team that has to validate on a decent sample set of environments.

I might be a hired hand, and probably do not know all there is about the trade that the software is developed for, nor do I know the clients or how they actually use the software. Over time, I might learn this, but only as far as the PM lets me.

It is my job to think of the what-if’s. Actually, writing code is all about what-if’s. However, it is the specifications that decide the scope of the what if’s.
Should I recognize different number formats? Date formats? International characters? Right to left text? What should the default value be when a calculation fails due to a division by zero? What should the correct behavior be when a criteria is not met? All these things are about specifications defined by the PM according to the needs of the clients.

When I “check in code”, I should NEVER EVER check it into production. I should push it to a proper staging environment, and write roll out documentation, then the test team should roll it out on a test environment, validate that it works, refine documentation and then hand it to the support team for rollout to production.

If the PM did not ensure that there is proper QA, it is that PM that is responsible for the shitty code in production. If the product doesn't do what the customer expects, it’s the PM that did not write proper use cases and proper specifications and operational parameters, and it would be the PM that did not ensure that the QM had created the necessary test cases and functional specifications.

My skill is not customer management. My skill is not necessarily to know the business that the client is in. My skill is to transform various degrees of incomplete specifications into something that resembles what the customer wants, within reasonable time, and with a reasonably high quality.

The PMs are the ones that defines what the customer wants.
The QMs decide if what I wrote, meets that definition.
The support team will be the ones that verify that the definition actually was complete and correct.

Good software meets expectations. Good software is a process. Good process depends on team work. Team work depends on a certain degree of separations of roles. Roles are defined by responsibilities.

My role as a developer is to write code that meets expectations.

In some companies, these roles may boil down to just a few people — or even just a single individual. The roles are still there. The responsibilities are still there.

If the CEO doesn't understand or care about these roles and allot the necessary time and/or resource — that company will be fighting fires, playing blame games, and losing clients.

Sincerely,
Your Developer
Lars Fosdal

2014-08-15T09:25:00.000+02:00

The Google+ Delphi Developers Community has reached 3300 members, as well as 800+ members in the Delphi iOS & Android Community. The Delphi Component Directory also carries posts about component updates. FYI, there is a C++Builder Developers group as well, where Brett Wilton is primus motor

In case you have withdrawal symptoms from the EMBT official forums, you know where to find us ;)

Please note that the Delphi groups are strictly for development related discussions, and that if you have a need to vent about prices, EMBT, policies, or other non-technical issues, you should post in this group instead.

Google+ Delphi Developers Community: 2400 members and wishlist for 2014!

2013-12-09T13:44:00.003+01:00

In January, the Google+ Delphi Developers Community will have it's one year anniversary. With 2400 members, as well as 300+ members in the Delphi iOS & Android Community and the Delphi Component Directory, I really appreciate and enjoy the posts and discussions about my favorite tool!

As you know, in the Yule time it is not unusual to send off a wish list to Santa, so here are my wishes for Santa (+David Intersimone) and the Code Elfs at Embarcadero for 2014.

Make 2014 a year for improving what exists!

It has been said before, but I cannot help but repeat my burning desire for having the list of "old sins" significantly shortened, instead of even more new features. Many posts during 2013 has been about performance issues or missing implementations, and to mention some: Generics weirdness, threading related issues, efficiency of generated code, lack of newer Windows APIs, lack of ready made wrappers for Android Java APIs, IDE memory management and debugger/emulator stability, IDE features such as code insight and error insight which behave erratically, ...I'll stop myself here ;)

Make 2014 a year for engaging the communities!

We have a lot of awesome people making awesome fixes, improvements and workarounds for known Delphi issues. I would love to see these people be given some love from EMBT and their excellent work adopted and integrated into Delphi. We also have the open source efforts for creating regression tests for the Delphi libs, and it would be awesome if this effort would be adopted and supported by EMBT.

To sum it up:
2014: No new platforms and lots of fixes!

That was my wish list.
What would be your Xmas wishlist for Embarcadero?

Welcome to the Delphi iOS & Android Developers Community on Google+!

2013-10-10T15:55:00.002+02:00

The Google+ Delphi Developers Community sprung another sibling!
Feel free to join up with the Delphi iOS & Android Developers Community.

The Delphi Developers Community is a relatively whine free place to discuss our programming challenges, and has just passed 2200 members, and our new iOS and Android offspring focuses on the finer details of getting the most out of the FireMonkey mobile platform - already have 125 people participating.

Then there is the growing Delphi Component Directory, where a steady flow of posts are highlighting the good stuff we may need to solve our challenges.

There even is a place to vent your anger with Delphi and Embarcadero without detracting focus from solving programming issues. If you need to rant and rage - people are all ears in Unit Number 5.

RAD Studio XE5 Easter Egg

2013-09-26T14:19:00.005+02:00

I am the curious kind, so armed with experience from earlier versions and the will to do a little experimentation, I brought up this photo:

Within RAD Studio XE5, do Help|About
Hold down the Alt-key and type TEAM
Double-click in the scrolling list of names

Click to enlarge - I can see Marco Cantù :)

Also posted to the Google+ Delphi Developers Community

Android Application Events

2013-09-12T10:54:00.001+02:00

There are a few differences between a Windows App and an Android App that puzzled me initially. Why doesn't my application get FocusChanged Activate/Deactivate or Close when switching between or terminating apps on Android?

In this post I also test out Google+'s new support for embedding G+ posts in blogs and web pages.

A Delphi Component Directory on Google+

2013-08-13T13:27:00.003+02:00

Now that Delphi Developers Community is inching towards 2000 members, the component update posts are perhaps not taking over, but there certainly is a bit more activity.

So - I decided to make another crowd sourced community for sharing components and resources. I hope my fellow Delphi developers will add posts about their components as well as web sites, blogs or communities, so that we can grow this into a useful and up-to-date Delphi Component Directory.

A great way to kickstart it, is that you post a link to your favorite component or component vendor, after you have checked that it hasn't already been posted. Select the right component group, or suggest a new group, and add tags for platform (#vcl, #firemonkey, #ios, #android) or other features.

Delphi Developers on G+ has passed 1500 members

2013-04-19T09:38:00.000+02:00

With Blogger's ability to +mention people, and now also sharing the blog comments on Google+, I'd say that you would have a hard time finding something that can beat it the Google+/Blogger combo for impact. Perhaps this can reignite the Delphi blogosphere, as it has never been so easy to create content and reach a targeted audience.

So, why don't you put on your writer's hat, write about your Delphi experience, and share it with us at the Delphi Developers Community?

The G+ Delphi Community just hit 700 members!

2012-12-18T00:47:00.002+01:00

I am thrilled to see that there really is a Delphi Community out there.
If you make third party components, I'd like to see you post about them there. Perhaps not as a sales pitch, but a little information what they can do and how they may help a Delphi user.

Please, join up at the Google+ Delphi Developer community :)

Brgds,
Lars F.

New Delphi Developer Community on Google+!

2012-12-07T10:33:00.002+01:00

Google just added Communities to Google+, so if you are a G+ addict like myself, you are very welcome to the new open Delphi Developer community :)

Google+ Delphi User Groups

2011-11-08T21:23:00.001+01:00

A suggestion for self-curating the Delphi content on Google+! Why? Because although we all are lovable developers, we can only handle that many photos, reshares and caturday gifs!

Using Google+ allows us to have a unified comment system, and a loosely coupled Delphi community where you can actually pick and chose among who you want to follow.

Here is how:

Step 1: Create your Google+ Delphi Page. With Google+ adding pages, we now can self-curate our content. This means that each of us can create our own Delphi page, which can be used to promote our blog posts, or our Delphi musings directly in the page stream. Note that we would need to refrain from posting caturday gifs, or reshares of the events of all world+dog on our Delphi page.

Step 2: From your Delphi Page, Follow the Delphi User Group and/or Firemonkey User Group pages This will make your page visible to other Delphi users, assuming you also complete step 3.

Step 3: Ensure that you show in public on your Delphi page profile that you follow the page(s) above. This because a Google+ page will NOT show you as a follower, unless you follow it in public.

Step 4: Pick the pages and/or users you want to follow from the User Group pages. As people publicly add (i.e. follow with) their Delphi pages, the user groups will automatically grow the list of available pages and visible for all.

Step 5: Enjoy a "spam free" Delphi circle!

Step 6: Optionally, reshare your old personal Delphi posts on your Delphi page.

The generic Delphi and Firemonkey user groups are just a start. Anybody can create their own topic-centric User Group page as well.

If you want to help grow the Delphi community:
Create your own Delphi page, and follow the User Groups!

Compile time ordered vectors

2011-11-08T12:13:00.000+01:00

I would like to have support for ordering content of a constant array at compile time.

I would like to have optimized lookup function for such an ordered constant array (binary search, hash index, etc, - whatever fits the purpose) to check if a variable has a match in the ordered constant array. The code generator could inline the lookup function if so was desired.

I guess you can say that I am looking for something like the "in" keyword for sets, but extended to work with any constant array (string, array of enumerable, array of number, or array of other constants such as class type references).

A specification syntax could look something like:
  <arraytype> = {ordered {ascending | descending}} Vector<T>

Implicit methods associated with the type:
  Vector<T>.Contains(const element: T):Boolean;
  Vector<T>.ContainsAny(const array of T):Boolean;
  Vector<T>.ContainsAll(const array of T):Boolean;
  Vector<T>.Include(const element: T);
  Vector<T>.Exclude(const element: T);

Example declaration:
type
  TMyType = ordered ascending Vector<Char>;
const
  InvalidChars : TMyType = ['\', ':', '.', '(', ')']; // I don't want to worry about order here

Example of use:
  if InvalidChars.Contains(SomeCharacter) then ...

Today, I can create singleton objects that are ordered as part of the initialization code, but it becomes a lot of micro management code which isn't optimized for call performance, instead of easy to use code like "element in set" style code.

Blog++ / Google+ Delphi Circle

2011-10-25T09:07:00.000+02:00

I just connected my Blogger ID to my Google+ account, and according to the update at the Blogger site, I'll be getting access to the new G+ integration stuff as it is rolled out. Can't wait to see G+ as the commenting system! I also tried out the new dynamic template, and you can see it live on the "Tools and Books" section, but that is not quite ready for prime time use yet. I like my gadgets and syntax highlighting... speaking of - I think I lost the booklist :( *sigh*

BTW: I already have over 200 people in my Google+ Delphi circle. Look me up at plus.lars.fosdal.com and drop me a comment to be circled!

A Windows 8 / Win RT Application in Delphi!

2011-10-03T18:23:00.000+02:00

Thom Gerdes @ Embarcadero just posted about his first Delphi / XAML application for Windows 8 and WinRT on Google+. https://plus.google.com/101466385048851863100/posts/26z7Pk9Hipo Blatant plug: If you have not signed up for Google+ yet, you should!

A Delphi road map preview from the new product manager.

2011-09-21T13:53:00.002+02:00

While we wait for a Delphi roadmap, a "roadmap preview" is available from the new RAD Studio product manager.

Frequent and regular FireMonkey updates
A Next Generation Delphi Compiler with multiple hardware/OS targets
Next Generation RAD C++ Compiler with multiple hardware/OS targets
64bit RAD C++
Delphi and C++ iOS support
Expanded Mobile UI and Device support like Location, Camera, Accelerometers etc
Delphi and C++ ARM Support
Extended iOS Support
Android Support
Win8/Metro Support - Intel and ARM

See May the road(map) rise with you for more.

Off-season easter egg hunt

2011-09-12T10:12:00.001+02:00

In the Rad Studio XE2 "Help|About" dialog - the good old Alt-TEAM shortcut Easter egg still works, and brings out the list of RAD Studio team members. But - are there other eggs as well? (Yeah, I am that childish ;) )

Forms and Data Entry Validation - Part 1

2011-09-02T11:33:00.000+02:00

This is not an article about LiveBinding. I was once hoping it was going to be, but instead it has become an alternative to LiveBinding. If anything, it is about compile-time binding and quality assuring the data input from of your users.

Forms, forms, forms...

How many forms have you created? Chance is - quite a few - and what do they have in common? If people type rubbish, your data becomes rubbish. So - what do you do? You validate the input to prevent rubbish getting into the system. You do... don't you? Sure you do!

When do you validate it? When someone clicks Submit or OK? Right - then you have to go through the input, field by field, and first ensure that what the user typed in actually is understandable in the current context - such as no funny characters in an integer - and sometimes you have to check the values against each other for logical states. If someone said they took three melons, their combined weight should at least be bigger than zero, and blue shirts don't go well with pink pants, and what else not.

If the user typed in rubbish - you have to inform him or her so that it can be corrected.

Been there, done that

There is a certain amount of logic in this scene that we keep recreating scaffolding for. Stuffing things into listboxes, formatting and filling in the values, validation of numbers and dates, converting enumerated types into strings (and back again). If you want the dialog to be slick - you might even want to validate as you go, which means eventhandlers for focus changes, keys pressed, UI items clicked, dropped down and selected, also adding to all the scaffolding code.

Some time ago, I had to create yet another dialog. Lines and lines of housekeeping code that surround the real validation logic. And naturally I don't have to be clearvoyant to foresee numerous more such dialogs, as it is a major part of writing applications that deal with configuration, input and control.

So - I thought to myself - can I spend a little time now, and save a lot of time later? Dangerous, innit, thinking like that... suddenly you could find yourself writing a framework, and we all know what happens to frameworks, right? They turn to endless amounts of code written with good intentions of handling the unexpected, covering functionality you won't ever need, and at some point collapse on themselves to become a black hole of sketchily documented (since noone updated the docs as new features got added) , and hastily changed (since you always are in a hurry for that extra functionality) code. And when someone else misread your framework intentions and applied it like a hammer to a screw - it just doesn't end well.

Narrowing down the scope

Hence - Sticking with the KISS principle, I have decided to try to make it independent of other libraries, and limit what I implement to basic functionality while attempting to allow for future expansion.

I am going to create a TInput<T> that wraps a GUI control. To put it simply - a TInput that points to a specific TEdit, and takes care of stuffing values from the variable and into the GUI control, and vice versa. The job of that TInput<T> is the present the value correctly, and to ensure that what ever is written into that TEdit, can be converted into an integer.

I will also create a TInputList that is a collection of TInput<T>s, that will have the job of going through the list to fill the controls, to validate the contents, and finally - if all input is syntactically correct - semantically validate the input for logical correctness.

Some of the code that I will present here, is probably centric to the type of data that I work on. For me, an input form will typically wrap an object with a set of properties that reflect a row or set of related rows in a database. Why am I not using data aware controls? Mostly because the applications we create actually can't write to the database themselves, except through calling stored procedures that perform more magic before, during, or after the data has been written. For that reason, the TInputList will be a TInputList<T>, and the TInputList<T> will have a property Current:T that I can populate, and each TInput<T> will know that it is member of a TInputList<T>, so that it can kick of the necessary actions for stuff to get validated.

[kom-pli-kei-tid]

By now you have probably thought to yourself: TEdit? What about the other controls?

Because there are a number of input types, and a number of controls, and these make a number of combinations. TEdit/Double, TEdit/Integer, TEdit/String, and TEdit/Enum is already a list, and I haven't even mentioned TComboBox yet,- so it is obvious that TInputList<T> has to be polymorphic.

This brings us to the first part of complicated - creating a set of generic and polymorphic classes. Generics in Delphi XE still don't to well with forward declarations, and to create polymorphic parent/children lists, it really helps to be able to forward declare.

After some consideration, I have chosen to use an abstract class without generics as my inner base class. TAbstractInput will know nothing about the data type we want to work with, nor will it know anything about the control type. All TAbstractInput will do, is define the virtual abstract methods that will be our type agnostic operators or verbs and queries, if you like. Hence, our TInputList will use TAbstractInput as its element type.

/// <summary> TAbstractInput defines the bare minimum base class for our list of inputs <summary>
  TAbstractInput = class abstract
  private
  protected
    function GetEdited: Boolean; virtual; abstract;
    procedure SetEdited(const Value: Boolean); virtual; abstract;
    function GetEnabled: Boolean; virtual; abstract;
    procedure SetEnabled(const Value: Boolean); virtual; abstract;
    function ControlValueIsValid:Boolean; virtual; abstract;
    function VariableValueIsValid:Boolean; virtual; abstract;
    procedure FillControl; virtual; abstract;
    procedure FillVariable; virtual; abstract;
    procedure SetDisabledState; virtual; abstract;
    procedure SetErrorState; virtual; abstract;
    procedure SetNormalState; virtual; abstract;
    procedure SaveNormalState; virtual; abstract;
    procedure Setup; virtual; abstract;
  public
    procedure Clear; virtual; abstract;
    procedure Update; virtual; abstract;
    function Validate: Boolean; virtual; abstract;
    property Edited: Boolean read GetEdited write SetEdited;
    property Enabled: Boolean read GetEnabled write SetEnabled;
  end;

From the outside of the list, we need TInput<T> that expose the correct type that we want to access, so that will be our outer base class type - which knows how to set and get the value, and hence the class that we use to reference an input field.

/// <summary> TInput<T> defines the input wrapper as we want it to be
  /// visible from the outside of our list of controls</summary>
  TInput<T> = class abstract(TAbstractInput)
  private
    FOnCanGetValue: TGetValue<Boolean>;
    procedure SetOnCanGetValue(const Value: TGetValue<Boolean>);
  protected
    function GetValue:T; virtual; abstract;
    procedure SetValue(const Value:T); virtual; abstract;
    function CanGetValue:Boolean; virtual; abstract;
  public
    property Value:T read GetValue write SetValue;
    property OnCanGetValue: TGetValue<Boolean> read FOnCanGetValue write SetOnCanGetValue;
  end;

Please note that this is a simplified view of TInput<T> class.

Inside TInputList, I will subclass TInput<T> again, and add knowledge of the controls. In fact, I will create several subclasses that handle type conversions for each data type and control type, but instead of having the user instantiate all these different class types - I will add factory methods to the TInputList instead.

Here are some excerpts from the declaration of TInputList and the basic control wrapper.

/// <summary> TInputList is a wrapper for all our input controls. </summary>
  TInputList<IT:class, constructor> = class(TList<TAbstractInput>)
  ... 
  public
    type
      /// <summary> This is our core input control wrapper on which we base wrappers for specific controls </summary>
      TInputControl<TCtrl:class; SVT, CVT> = class(TInput<SVT>)
      private
        FController: TInputList<IT>;
        FControl: TCtrl;
        FValue: SVT;
        ...  
      end;
  end;

Properties and Binding

This is the second part of complicated. Will I be using the XE2 LiveBinding? No. IMO, LiveBinding uses the least desirable method to bind a property for setting and getting. I lamented this in my previous article, Finding yourself in a property bind. In my opinion, LiveBinding is a good idea that is implemented in the wrong way, and in it's current form will be vulnerable to property and variable name changes during refactoring. In addition, it appears that LiveBinding is not quite mature yet. Then there is the fact that XE and older, doesn't have LiveBinding.

After some experimentation, I came to the conclusion that even if it appears to be more elegant to use visitors or observers and RTTI binding, I will get more flexibility, readability, and maintainability by using anonymous methods.

Anonymous methods allow me to do manipulation of the value before it is set/get, and allow the setter/getter events to have side effects. It also ensures that all references are validated compile-time. It will not guarantee protection from referencing the wrong properties and variables, but they will at least be of the right type, and actually exist.

Since my primary development platform is Windows, I am a VCL developer - and when I started this little project, I had only VCL in mind. However, as the code matured, I found that I might want to be able to use this for FireMonkey as well. That still remains to be seen as FireMonkey still smell of Baboon.

Still, the core logic is platform agnostic, and the VCL bits are separated into a unit of their own.

Here is an excerpt from the VCL implementation with complete declarations.

TInputListVCL<IT:class, constructor> = class(TInputList<IT>)
  public
    type
      TInputControlVCL<TCtrl:TWinControl; SVT, CVT> = class(TInputList<IT>.TInputControl<TCtrl, SVT, CVT>)
      protected
        procedure ControlEnable(const aState:Boolean); override;
        function ControlEnabled:Boolean; override;
        procedure ControlSetFocus(const aFocused:Boolean); override;
      end;

      /// <summary> Basic wrapper for a TEdit </summary>
      TEditTemplate<SVT> = class abstract(TInputControlVCL<TEdit, SVT, String>)
      private
        FNormalColor: TColor;
      protected
        procedure SetControlValue(const Control:TEdit; const v:String); override;
        function GetControlValue(const Control:TEdit): String; override;
        function ControlValueAsString:String; override;
        procedure SetErrorState; override;
        procedure SetNormalState; override;
        procedure SaveNormalState; override;
        procedure SetDisabledState; override;
      public
        procedure Clear; override;
        procedure Setup; override;
      end;

      /// <summary> TEdit wrapper for editing a string </summary>
      TEditString = class(TEditTemplate<String>)
      protected
        function ConvertControlToVariable(const cv: String; var v:String; var ErrMsg:String):Boolean; override;
        function ConvertVariableToControl(const v:String; var cv:String):Boolean; override;
      end;

      /// <summary> TEdit wrapper for editing a float </summary>
      TEditDouble = class(TEditTemplate<Double>)
      private
        FDecimals: Integer;
      protected
        procedure SetDecimals(const Value: Integer); override;
        function GetDecimals:Integer; override;
        function ConvertControlToVariable(const cv: String; var v:Double; var ErrMsg:String):Boolean; override;
        function ConvertVariableToControl(const v:Double; var cv:String):Boolean; override;
      end;

      ...

  end;

Putting it to use

This will be covered in part 2. Until then, don't forget to try out RAD Studio XE2 and join the RAD Studio World Tour presentations!

RAD Studio XE2 is RTM

2011-09-01T10:44:00.002+02:00

The wait is over. If you have bought XE with Software Assurance, your SA Upgrade notice will be arriving shortly. If you want to try it out NOW, you can already download the 30-day trial editions.

Delphi XE2 Architect 30-day trial:
https://downloads.embarcadero.com/free/delphi

RAD Studio XE2 Architect 30-day trial:
https://downloads.embarcadero.com/free/rad_studio

Please note that the trial editions does not contain the command line compiler and VCL source code, as well as some third party offerings. You may want to install the trial editions in a VM, just as a precaution.

Until you got it installed, you might find pleasure in reading about the new release here: http://docs.embarcadero.com/products/rad_studio/, and perhaps in particular this section: What's new in Delphi and C++Builder XE2.

This is a major release, with a lot of new features, so should you stumble upon a problem during your trial - please report any issues you find at http://qc.embarcadero.com

While you are at it, you should also sign up for the RAD Studio XE2 World Tour event near you.

In the Nordic countries:

Edit: Just had to add Andreano Lanusse's XE2 ad image:

RAD Studio XE2 - VCL and FireMonkey (FMX) first glance comparison

2011-08-25T14:43:00.001+02:00

Published with permission from Embarcadero.

When you start out a new simplistic GUI project in VCL or FireMonkey (FMX) in XE2, you will notice a few differences from older Delphi versions. XE2 introduce consistent use of unit scope prefixes. The Windows related units are grouped under the Winapi prefix, and the VCL units under VCL. FireMonkey has been given the short prefix FMX.

As you can see - the basic generated skeleton code is quite similar between the two frameworks.
Apart from referring different framework units, the resource include statement is also different: "*.dfm" vs "*.fmx".

The skeleton code

unit MainUnitVCL;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs;

type
  TFormVCL = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  FormVCL: TFormVCL;

implementation

{$R *.dfm}

end.

This is a FireMonkey HD project.

unit MainUnitFM;

interface

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Dialogs;

type
  TFormFM = class(TForm)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  FormFM: TFormFM;

implementation

{$R *.fmx}

end.

The designer

The designers are fairly similar between the frameworks, but there are differences.
The good old VCL

The new FireMonkey designer:

If you are wondering what's up with the drab grey look, you can relax. This is the designer look, not the run time look. FMX adopts to the theme of the OS it is running on - so it will look like a Windows app on Windows, and as a OSX app on OSX.

The form properties

Let's take a quick look at the properties of the standard form.

We are clearly not in Kansas anymore. FMX is a completely different framework, and it has been designed with cross platform in mind, unlike VCL which was designed to wrap Windows controls. This means we can look forward to learning new tricks, which some of us will view as a plus, while others will sigh and mutter something about things being better before.

Porting a project from VCL to FMX is more work than recreating the form in the FMX designer, hooking up the new event handlers, and pasting in code from the VCL project.

I added some standard controls to both forms.

Design time

VCL

FMX

Run time

VCL

FMX

Source code

VCL

unit MainUnitVCL;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  TFormVCL = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    Label1: TLabel;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  FormVCL: TFormVCL;

implementation

{$R *.dfm}

procedure TFormVCL.Button1Click(Sender: TObject);
begin
  Memo1.Lines.Add(Edit1.Text);
  Label1.Caption := IntToStr(Memo1.Lines.Count);
end;

end.

FMX

unit MainUnitFM;

interface

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Dialogs, FMX.Edit, FMX.Layouts,
  FMX.Memo;

type
  TFormFM = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    Label1: TLabel;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  FormFM: TFormFM;

implementation

{$R *.fmx}

procedure TFormFM.Button1Click(Sender: TObject);
begin
  Memo1.Lines.Add(Edit1.Text);
  Label1.Text := IntToStr(Memo1.Lines.Count);
end;

end.

As you can see - although similar in many ways - there are many differences between VCL and FMX. One example: TLabel.Caption is no more. TLabel.Text is the correct property under FMX.

Then there is the glaring fact that FMX HD will build for OSX as well as both 32 and 64-bit Windows :) Alas - since I don't have a Mac, I can't show you the OSX version.

How do the form resources look?

VCL

object FormVCL: TFormVCL
  Left = 0
  Top = 0
  Caption = 'FormVCL'
  ClientHeight = 337
  ClientWidth = 635
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'Tahoma'
  Font.Style = []
  OldCreateOrder = False
  PixelsPerInch = 96
  TextHeight = 13
  object Label1: TLabel
    Left = 8
    Top = 8
    Width = 31
    Height = 13
    Caption = 'Label1'
  end
  object Button1: TButton
    Left = 536
    Top = 294
    Width = 75
    Height = 25
    Caption = 'Button1'
    Default = True
    TabOrder = 0
    OnClick = Button1Click
  end
  object Memo1: TMemo
    Left = 8
    Top = 24
    Width = 498
    Height = 265
    Lines.Strings = (
      'Memo1')
    TabOrder = 1
  end
  object Edit1: TEdit
    Left = 8
    Top = 296
    Width = 498
    Height = 21
    TabOrder = 2
    Text = 'Edit1'
  end
end

FMX

object FormFM: TFormFM
  BiDiMode = bdLeftToRight
  Caption = 'FormFM'
  ClientHeight = 400
  ClientWidth = 600
  Left = 0
  Top = 0
  Transparency = False
  Visible = False
  StyleLookup = 'backgroundstyle'
  object Button1: TButton
    Position.Point = '(496,363)'
    Width = 80.000000000000000000
    Height = 22.000000000000000000
    OnClick = Button1Click
    TabOrder = 1
    StaysPressed = False
    IsPressed = False
    Text = 'Button1'
    Default = True
  end
  object Memo1: TMemo
    Position.Point = '(8,24)'
    Width = 473.000000000000000000
    Height = 321.000000000000000000
    TabOrder = 10
    WordWrap = False
  end
  object Label1: TLabel
    Position.Point = '(8,8)'
    Width = 120.000000000000000000
    Height = 15.000000000000000000
    TabOrder = 11
    Text = 'Label1'
  end
  object Edit1: TEdit
    Position.Point = '(8,360)'
    Width = 473.000000000000000000
    Height = 22.000000000000000000
    TabOrder = 12
    ReadOnly = False
    Password = False
  end
end

FMX is made for scaling, and it also have numerous other nifty features such as rotation.

Summary

This was just a very shallow outline of some of the differences between VCL and FMX, but it is perhaps enough food for thought to make you realize that you most likely will have to put some effort into moving from VCL to FMX. In some cases, you can get away with minor adjustments, but when it comes to sophisticated GUI - or stuff that is based on Windows functions - you will need to rewrite parts of your code.

Don't forget to visit http://www.embarcadero.com/world-tour to register for the RAD Studio XE2 World Tour event near you!

RAD Studio XE2 - Breaking out of 32-bit Windows

2011-08-24T10:46:00.002+02:00

Published with permission from Embarcadero.

The Embarcadero RAD Studio XE2 World Tour is upon us.

The features are shiny! The reviews will be rave! As a Delphi developer, your favorite toolbox is about to get a massive upgrade that you don't want to miss!

Click on the banner up top or down at the bottom of the blog to sign up for an event near you.

One of the new features is cross platform support.

On the long awaited end - your new Delphi will be able to do your old Windows 32-bit platform, and now also will compile your VCL applications to native 64-bit. Note that VCL will still be Windows Only. You may have to do a little fixing to your code, as Integer still is 32-bit but Pointer is 64-bit - so those old Pointer(Integer) casts will have to be reworked.

The most exiting feature of XE2 is that you can create GUIs for other platforms as well!
To enable this - Embarcadero nabbed the guy behind VGScene and DXScene and created FireMonkey - a whole new GUI framework that supports Windows, OSX and iOS in Delphi XE2, and that will (warning - speculation) very likely add support for other OS platforms in future versions of RAD Studio.

FireMonkey apps are cross platform - but they come in various flavors - so you still have to make a conscious choice about where to start...

Over the coming days I predict heavy blog activity with a lot to read about the new RAD Studio XE2 release, but in the mean time - make sure to sign up for the RAD Studio XE2 World Tour events!

Weird code snippet #2: Generic Double Linked List

2011-07-14T13:17:00.001+02:00

They say Generics and pointers don't mix.

type
  PMyThing<T> = ^TMyThing<T> // [DCC Error] E2508 type parameters not allowed on this type
  TMyThing<T> = record
     Thing: T;
  end;

Ok, they don't. But there is a loophole!

type
  TMyThing<T> = record
    Thing: T;
    NextThing: ^TMyThing<T>;
  end;

Why this is allowed, I don't know. Just like I don't really understand why the first one is forbidden. There is probably some good explanation for it.

Still - it can be fun breaking the rules!

unit GenericDoubleLinkedList;

interface
uses
  Classes, Generics.Defaults;

type
  TLinkVisitor<T> = reference to procedure(const Item: T);

  TDoubleLinked<T> = record
    Value: T;
    PrevLink: ^TDoubleLinked<T>; // Hey, it compiles!
    NextLink: ^TDoubleLinked<T>;
    constructor Create(aValue:T);
    function Add(aValue:T): TDoubleLinked<T>;
    function HasNext:Boolean;
    function Next: TDoubleLinked<T>;
    function HasPrev:Boolean;
    function Prev: TDoubleLinked<T>;
    function First: TDoubleLinked<T>;
    function Last: TDoubleLinked<T>;
    procedure ForEach(const Proc: TLinkVisitor<T>);
  end;

  procedure Test(const Log:TStrings);

implementation

{ TDoubleLinked<T> }

constructor TDoubleLinked<T>.Create(aValue: T);
begin
  Value := aValue;
  NextLink := nil;
  PrevLink := nil;
end;

function TDoubleLinked<T>.Add(aValue: T): TDoubleLinked<T>;
var
  p: ^TDoubleLinked<T>; // But this one is not assignment compatible
begin
  p := AllocMem(SizeOf(TDoubleLinked<T>)); // Make space
  p^ := Self;      // Copy current value to allocated block
  Value := aValue; // Set self to new value
  p.NextLink := @Self;
  if Assigned(p.PrevLink) // Fix up previous nextlink
   then Pointer(p.PrevLink.NextLink) := Pointer(p);
  Pointer(PrevLink) := Pointer(p);  // Point back to old value
  Result := Self;
end;

function TDoubleLinked<T>.HasPrev: Boolean;
begin
  Result := PrevLink <> nil;
end;

function TDoubleLinked<T>.Prev: TDoubleLinked<T>;
begin
  Result := TDoubleLinked<T>(PrevLink^)
end;

function TDoubleLinked<T>.HasNext: Boolean;
begin
  Result := NextLink <> nil;
end;

function TDoubleLinked<T>.Next: TDoubleLinked<T>;
begin
  Result := TDoubleLinked<T>(NextLink^)
end;

function TDoubleLinked<T>.First: TDoubleLinked<T>;
begin
  Result := Self;
  while Result.HasPrev
   do Result := Result.Prev;
end;

function TDoubleLinked<T>.Last: TDoubleLinked<T>;
begin
  Result := Self;
  while Result.HasNext
   do Result := Result.Next;
end;

procedure TDoubleLinked<T>.ForEach(const Proc: TLinkVisitor<T>);
var
  Node: TDoubleLinked<T>;
begin
  Node := First;
  Proc(Node.Value);
  while Node.HasNext
  do begin
    Node := Node.Next;
    Proc(Node.Value);
  end;
end;

procedure Test(const Log:TStrings);
var
  List, Node : TDoubleLinked<String>;
begin
  List.Create('One');
  List.Add('Two');
  List.Add('Three');
  Node := List;  // Bad idea
  List.Add('Four');
  Node.Add('ThreeAndAHalf');

  List.ForEach(
    procedure(const Value:String)
    begin
      Log.Add('List: ' + Value)
    end);

  Node.ForEach(
    procedure(const Value:String)
    begin
      Log.Add('Node: ' + Value)
    end);
end;

end.

The problem is that "List" is not a pointer, but the tail item of the list. Hence, a Delete procedure needs to take this into consideration.

Even worse, if you add a second Node variable to point to something in the list, that reference will not be fixed up after adding 'Four', and hence it will take the tail place of the list - for both references, effectively forgetting the 'Four' item.

So, although this was somewhat entertaining, a mix of Generics and pointers probably isn't something we should make use of.

Exercise for the reader: Implement the TDoubleLinked<T>.Delete; procedure.

End question: Why are we not allowed to declare pointers to generic types?

Weird code snippet #1: Pseudobinary case statement

2011-07-08T21:03:00.002+02:00

Curt Carpenter suggested a language addition for handing binary case logic.

That gave me this idea. Chalk it up as another weird code snippet from yours truly.

///<summary>> Convert array of booleans to a pseudobinary integer. 
///Good for up to 12 bits.</summary>
function BoolToInt(B: Array of Boolean):Integer;
var
  x : Boolean;
begin
  Result := 0;
  for x in B
  do begin
    Result := Result * 10;
    if x then Inc(Result);
  end;
end;

procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
var
  ch : Char;
begin
  ch := Lowercase(Char(Key));
  case BoolToInt([ssShift in Shift, ssCtrl in Shift, ch='a', ch='x', ch='c', ch='v']) of
    011000: SelectAll;
    010100: Cut;
    010010: Copy;
    110010: Clone;
    010001: Paste;
  end;
end;

A slightly more tongue in cheek example:

procedure SexistTestLogic(const Cute, Funny, Smart: boolean);
begin
  case BoolToInt([Cute, Funny, Smart]) of
     000: Avoid;
     001: Admire;
     010,
     011: Befriend;
     100: Tolerate;
     101: HandleWithCare;
     110: Adore;
     111: Marry;
  end;
end;

Finding yourself in a property bind

2011-06-14T16:24:00.000+02:00

From the wishful thinking department, I would love to be able to

var  
  Src: TSomeClass;
  MyObject : TBoundObject<Boolean>;
begin
  MyObject.Bind(Src, CompilerMagic(TSomeClass.SomeBooleanProperty));
end;

instead of

var  
  Src: TSomeClass;
  MyObject : TBoundObject<TSomeClass, Boolean>;
begin
  MyObject.Bind(Src, 'SomeBooleanProperty');
end;

Why? Because the first one is resilient to property renaming.
Until I can, I am stuck with using something similar to

var
  Src: TSomeClass;
  MyObject : TBoundObject<TSomeClass, Boolean>;
begin
  MyObject.Bind(Src,
    function (const Ref:TSomeClass):Boolean // reads the bound prop
    begin
      Result = Ref.SomeBooleanProperty;
    end,
    procedure (const Ref: TSomeClass; const Value:Boolean)  // writes the bound prop
    begin
      Ref.SomeBooleanProperty := Value;
    end);
end;

which actually has some benefits - such as being able to sanitize assigned values - but is way too verbose.

I wish...

Generics, Enumerated types and ordinal values

2011-04-08T17:02:00.006+02:00

I wish this was a solution post, but it is a frustration post. I trying to figure out how I can use Ord() to convert an enumerated type to integer or cast an integer to an enumerated type using generics type arguments?

uses
  SysUtils,
  TypInfo;

type
  TSomeEnumType = (TheFirst, TheSecond, TheThird, TheFourth);

type
  TEnumGen<TEnumType> = class
    class function Name(const Enum:TEnumType):String;
    class function Value(const Ordinal:Integer):TEnumType;
  end;

class function TEnumGen<TEnumType>.Name(const Enum: TEnumType): String;
begin
  Result := Format('%s.%s', 
    [GetTypeName(TypeInfo(TEnumType)), 
     GetEnumName(TypeInfo(TEnumType), Ord(Enum)) // <-- Bombs
    ]);
end;

class function TEnumGen<TEnumType>.Value(const Ordinal:Integer):TEnumType;
begin
  Result := TEnumType(Ordinal); // <- Bombs
end;

Unfortunately there is no "enum" delimiter that can be used to tell the compiler that Ord() and casting of integers should be allowed for generic enumerated type arguments.

Dataists: Ranking the popularity of programming languages - YALPC

2011-01-06T10:12:00.003+01:00

Yet Another Language Popularity Contest - Web site dataists had an article in december about the popularity of programming languages, using data from StackOverflow and GitHub to measure popularity. Delphi scored high on StackOverflow, but low on GitHub - which probably reflect on the SVN support in Delphi, making SVN more popular than Git for Delphi users. Note that the scales are by rank, and not by relative number of entries.