DataSnap analysis based on Speed & Stability tests

It’s not difficult to read and listen about the wonders of Embarcadero DataSnap technology around the world. I attended the Delphi Conference 2011 and 2012 in Sao Paulo, Brazil, after the release of versions of Delphi XE2 and XE3, and the words “performance” and “stability” are not spared when the subject is DataSnap. Apparently a […] … Read More

Read More

DataSnap analysis based on Speed & Stability tests

It’s not difficult to read and listen about the wonders of Embarcadero DataSnap technology around the world. I attended the Delphi Conference 2011 and 2012 in Sao Paulo, Brazil, after the release of versions of Delphi XE2 and XE3, and the words “performance” and “stability” are not spared when the subject is DataSnap. Apparently a […] … Read More

Read More

FireMonkey Style – TStyleTag (Part 2)

Part 1 – Along with the missing registration of TStyleTag, the following components cannot be used in styles without hand editing FMX or Style files. TFontObject TBrushObject I’ve updated the package to now register these missing style components so you can use them in custom styles. Download Package The change is straight forward if you have already downloaded and installed the previous package. The register procedure should now look something like this: procedure Register; begin   RegisterComponents('Shapes', [TStyleTag, TFontObject, TBrushObject]); end; NOTE: You may want to register them to a different palette location.  
Read More

XE3 Visual LiveBindings: Samples

Here is a summary of the samples which accompany my XE3 VLB posts.  The samples are grouped by Sourceforge locations. Observers (post) VclSampleObservableControls.dpk - Implements an observable TTrackBar LinkTrackbarToField.dpr - TObservableTrackBar project Actions (post) Navigate using actions and TSpeedButton Vcl\LiveBindingsActionsProtoProject.dpr Fmx\FmxLiveBindingsActionsProtoProject.dpr Vcl\LiveBindingsActionCDSProject.dpr Fmx\FmxLiveBindingsActionsCDSProject.dpr ListControls (post1, post2) ListBoxVCL.dpr - Link a TListBox to a field SimpleListView.dpr - Link a TListView to a field LiveViewColumns.dpr - Link a TListView to a field and fill multiple columns Lookups (post1, post2) LookupListBoxVCL.dpr - Configure TListBox as a lookup list LookupEditVCL.dpr - Configure a TLabeledEdit as a lookup control LookupLabelVCL.dpr - Configure TLabel.Caption as a lookup property Share This | Email this page to a friend
Read More

My Take on TypeScript

Microsoft has been keeping the renowned Anders Hjelsberg busy on a new language called TypeScript.  Typescript is an open-source project (using the Apache 2.0 license) that allows you to write a super-set of Javascript that allows for a stronger typing system.  You can watch Anders’ original launch presentation

I’ve said a million times that I’ve said a million times that Javascript is the new Assembler – that Javascript will become the thing that everyone compiles higher level code into.  You’ll write your web apps in a higher order language, and then compile them to Javascript for execution in the browser. 

I refuse to believe that any rational person actually likes to write Javascript, and as it is designed currently, it really isn’t a language for developing the kind of large-scale applications that people seem to be wanting to use it for.  In the deep, dark past, Assembler used to be all there was, and we created higher order solutions that compiled to assembler.  And in the same way, for a while, Javascript was all there is for the browser.  Now, however, we are beginning to see higher order languages being brought to bear to produce Javascript for us. 

If Javascript is the “new Assembler”, then the Browser becomes the “new operating system”.  The cool thing about that is that the “new OS” is ubiquitous.  Just about every computer in the world – computers running Windows, OS X, Linux, Unix, whatever – has a browser that runs Javascript.  That means your application can run on any computer.  That’s a very compelling idea.

You can actually do that today with Delphi using a very cool tool called Smart Mobile Studio.  There is also the Elevate Web Builder tool from Elevate Software.  Both have the same idea – leverage the power of Delphi to produce Javascript-based applications.  Pretty cool, really.

Anders talked to Scott Hanselman about Microsoft’s offering in the “Language to compile down to Javascript” arena in the latest episode of Hanselminutes.  Anders is always a good interview – I love a guy who thinks and speaks as clearly as he does.  (That’s why I always loved a Danny Thorpe presentation.  Danny is pretty quiet and mellow, but his talks were always so clear and well organized – every single word he said was worth listening to – that they were always excellent and enormously educational.  Anders is the same way….) He does a great job discussing the notion behind TypeScript.

Here are some of my thoughts on what Anders said and on TypeScript in general.

  • TypeScript seems to exist for two reasons – to make Javascript “tool-able” and scalable. 
    • First, the type annotations, classes, modules, and other enhancements exist to allow Visual Studio and other IDEs to do things like Code Completion (the RAD Studio term that Anders used in the podcast instead of Intellisense – I loved that.    ), refactoring, and other language-based features that modern IDE’s do.  Javascript doesn’t provide enough information to let development tools do all the things that we expect, but TypeScript does. 
    • Second, TypeScript is also a way to make Javascript scale. By providing the notion of typed classes and modules, you can create larger, well-organized TypeScript applications which then compile to Javascript.   TypeScript is a language ready to do the heavy lifting that Javascript cannot.
  • Since TypeScript is a super-set of Javascript, it follows that pure Javascript is valid TypeScript.  Anders points out that you can use your existing Javascript as is inside of TypeScript.  The idea, though, is that TypeScript becomes the language you’d use instead of Javascript because of all the tooling support, and because it can be used to build applications via modules (units, for you Delphi folks).    Typescript doesn’t have any runtime or virtual machine – it literally just compiles to Javascript. 
  • You can create an external declaration file to define the types in your *.js file, so that means that existing Javascript libraries like Node.js and jQuery.js can be “typed” and thus used in the TypeScript environment.  I think that is a pretty cool idea – and I’m sure that Microsoft will be delighted if the community follows their lead and “converts” the existing popular libraries.
  • Anders also points out that TypeScript puts a “dial” on the typing level of your code.  Pure Dynamic advocates can leave everything untyped, and the strong-typing zealots can type everything if they want, and the folks who want to type some things and not type others can do that if they want.  That’s a very interesting notion – a language with a variable level of type-safety.

Now one thing to note is that tools like Smart Mobile Studio and Elevate Web Builder offer pretty much all these features as well.  There isn’t any reason that Embarcadero couldn’t make Javascript be something that is output by the Delphi compiler.  Heck, there is even a project out there to get LLVM to produce Javascript.  TypeScript would integrate well into HTML5 Builder. Whatever higher-end language you want to use, it seems pretty clear to me that Javascript will be the thing our compilers will be producing in the not-to-distant future.

Are you going to give TypeScript a look, or are you more interested in the Delphi-to-Javascript solutions?  I’ll probably check out both.  Either way I have to use a different IDE, so I’m guessing I’ll lean towards the Delphi-based solutions.  Plus, I frickin’ hate curly braces. 

What do you guys think?

Read More

Read More

EvelateDB 2.11 Just Released – Supports XE3

ElevateDB 2.11 is now available for download. If you're an existing customer, then you should be receiving an email shortly with download instructions. You can view the release notes, including any breaking changes, on the download page before downloading.This release includes support for Embarcadero RAD Studio XE3 and a new package naming convention to make referencing the ElevateDB runtime packages easier for VCL/FireMonkey applications and other design-time 3rd party packages.News ReleaseElevateDBSemper Fi,Gunny Mike
Read More

XE3 Visual LiveBindings: Hiding and showing components

This post describes how to specify which components show on the LiveBindings designer.
Hide/Show Component Classes
To reduce clutter, the LiveBindings designer hides many classes of components. The default settings show most visual control classes and hide most non-visual components classes except for data sources.
The settings are in Tools/Options/LiveBindings:

If there is a component class that […] … Read More

Read More

XE3 Visual LiveBindings: Actions

LiveBindings actions are new in XE3.  If you are not familiar with actions, follow this link.  LiveBindings actions correspond to the buttons on the TBindNavigator such as First, Next, Edit, Post, and Delete.
Steps for creating a speed button which uses a LiveBindings action:

Drop a  TPrototypeBindSource on the form and add fields.  See this post.
Drop a  TActionList
Drop a TSpeedButton
In […] … Read More

Read More

XE3 Visual LiveBindings: Link controls to component properties

Simple controls can be linked to component properties.   TEdit is an example of a simple control.  TLabel.Text is an example of a component property.   Controls can be linked to most public properties of any component on a form.
Link controls to component properties in the LiveBindings designer
After a TEdit and TLabel are dropped on […] … Read More

Read More

FireMonkey 2 Under The Hood Changes: Properties

There is another change in FireMonkey 2 in RAD Studio XE3 which does not show up on the What’s New page, but which pays dividends in terms of performance, usability and extensibility: Refining component properties. The FireMonkey team has performed a comprehensive audit of all the component properties to re-examine whether each property should be published or not, whether the property’s default value is appropriate and whether it is published at the appropriate level of the component hierarchy tree. The result of this audit was a lot of little changes throughout the FireMonkey framework. When a component property is published (that is, is appears in a published section of a class declaration), then the property will appear in the form designer’s Object Inspector at design-time. It also means that the value of the property can also be stored in the form file (.fmx file). In RAD Studio XE3, many properties have been unpublished because their values were not relevant to the component and were not used by the component. By unpublishing these properties, it means that forms load more quickly because the runtime does not have to spend time reading and setting these property values. It also means that the Object Inspector is not littered with irrelevant properties, so the components are easier to use at design time. For properties which remain published, the team has made sure that the properties are generally not published in base classes. This means that developers and technology partners which make custom components can precisely determine the properties which should be published in their custom subclasses. This refinement helps FireMonkey become a more mature, more usable framework for cross-platform development. Share This | Email this page to a friend
Read More

FireMonkey 2 Under The Hood Changes: PlatformServices

RAD Studio XE3 introduces the next evolution of the FireMonkey framework: FM2. The What’s New in FM2 page highlights a lot of the new features. I wanted to point out some under the hood changes that are also significant. Platform One of the key concepts at the base of a cross-platform framework is providing an abstraction of the runtime environment, the operating system and hardware. In the original release of FireMonkey in RAD Studio XE2, this abstraction was provided by an abstract class, TPlatform. Each supported platform (Windows, Mac OS X and iOS) had a concrete implementation of this abstract class and it was accessed via a global Platform variable. When the runtime platforms have similar features and capabilities, this approach is reasonable. As platform features start to diverge, however, this approach makes it difficult for a developer to know which parts of the abstraction are implemented on the runtime environment. This divergence was evident in the number of no-op implementations in the various platform units. PlatformServices In FM2, this abstraction has been significantly rewritten. Instead of a single abstract class, FM2 now has a registry of platform services, TPlatformServices (found in FMX.Platform.pas): TPlatformServices = class private FServicesList: TDictionary<TGUID, IInterface>; FGlobalFlags: TDictionary<string, Boolean>; class var FCurrentPlatform: TPlatformServices; class function GetCurrent: TPlatformServices; static; public constructor Create; destructor Destroy; override; class procedure UnInitialize; procedure AddPlatformService(const AServiceGUID: TGUID; const AService: IInterface); procedure RemovePlatformService(const AServiceGUID: TGUID); function GetPlatformService(const AServiceGUID: TGUID): IInterface; function SupportsPlatformService(const AServiceGUID: TGUID): Boolean; overload; function SupportsPlatformService(const AServiceGUID: TGUID; out AService: IInterface): Boolean; overload; property GlobalFlags: TDictionary<string, Boolean> read FGlobalFlags; class property Current: TPlatformServices read GetCurrent; end; This class allows services to be added and removed from the registry, with the methods AddPlatformService and RemovePlatformService, respectively. The functions SupportsPlatformService provide a way for developers to query the registry to determine whether or not a particular service is supported at runtime. These functions were written to be similar to the Delphi RTL Supports functions for working with Delphi interfaces. Services So what is a platform service? It is simply an interface which defines some functionality which may or may not be implemented on a particular runtime platform. For example, this is the definition of the IFMXApplicationServices interface which defines the basic operations expected of an Application object: IFMXApplicationService = interface(IInterface) ['{EFBE3310-D103-4E9E-A8E1-4E45AB46D0D8}'] procedure Run; procedure Terminate; function HandleMessage: Boolean; procedure WaitMessage; function GetTitle: string; end; The FireMonkey TApplication object uses this service to control the application. FireMonkey cannot do very much without this service, so an implementation is provided for every runtime environment. There are a number of other services which are not as essential. An on-screen keyboard is a good example. Functions to support an on-screen keyboard are provided by the platform service interface IFMXVirtualKeyboardService: IFMXVirtualKeyboardService = interface(IInterface) ['{BB6F6668-C582-42E4-A766-863C1B9139D2}'] function ShowVirtualKeyboard(AControl: TFmxObject): Boolean; function HideVirtualKeyboard: Boolean; function GetVirtualKeyBoardState: TVirtualKeyBoardState; property VirtualKeyBoardState: TVirtualKeyBoardState read GetVirtualKeyBoardState; end; To support the touch-oriented features of Windows 8, FM2 implements this service on the Windows platform. The service is not implemented for Mac OS X, however. Before a developer tries to use an on-screen keyboard, it is important to verify whether the service is supported or not, using code like this: if TPlatformServices.Current.SupportsPlatformService(IFMXVirtualKeyboardService) then Platform Growth and Advanced Uses Changing the platform abstraction to a registry provides a much more powerful and flexible mechanism which will allow FireMonkey to be implemented on more platforms (for example, those mentioned in the RAD Studio Mobile Roadmap). This mechanism provides a lot of power to developers to tailor applications to specific needs as well. For example, if a developer needs to provide an on-screen keyboard for a Mac OS X-based kiosk application, the developer can implement the IFMXVirtualKeyboardService interface and register it to get the FireMonkey support for on-screen keyboards. It is also possible to unregister a service that FireMonkey does implement and replace it with a new implementation of the service which is tailored to fit the needs of a specialized application environment. Share This | Email this page to a friend
Read More

Delphi XE3 Starter Essentials available for download

My Delphi XE3 Starter Essentials ebook (PDF) has just been made available for download for all registered Delphi Starter developers at This is the first of my XE3 ebooks, shortly followed by titles like Delphi XE3 Development Essentials, Delphi XE3 DataSnap Development, Delphi XE3 XML, SOAP & Web Services Development.
Read More