XE Plus Pack – Release 11

Release 11 of XE Plus Pack is now available for all supported IDE versions (Delphi XE, Delphi XE2, Delphi XE3). XE Plus Pack and XE2 Plus Pack now include all features available in XE3 Plus Pack. Release 11 features: Visual Forms can now support multiple projects in the same location. Note: Existing projects with Visual Forms active will need to be rescanned. Added new commands to the Project Managers’ File Actions menu item. Open With… Open with Notepad Improved Mouse Scrolling of the designer surface for VCL applications. Minor UI enhancements to dialogs within Visual Forms expert. Fix issue with the replace capture dialog not displaying the image to use. Add “Capture Form” command to a forms context menu so it is even easier to update a form within the Visual Forms view if automatic updating is not active. Support Resolution guidelines being displayed in the FireMonkey designer.
Read More

Are you eligible?

A couple of weeks ago, I implemented a new EDN feature which may have gone unnoticed by many of you. When you log into Member Services, you will now see a new ‘My eligible field tests’ option in the navigation bar to the left.
When you click on this, it will show you a list of […] … 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

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 – http://jed-software.com/blog/?p=699 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

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