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 http://cc.embarcadero.com/item/28214 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

Customizing EurekaLog

EurekaLog 7 offers many ways for customizing behaviour and visual appearance (error dialogs).

Important Note: please see most recent version of this documentation here.

You can use one or more of the following methods (all methods are listed starting with most high-level/easy-to-use to low-level/hard-to-use):

  1. EurekaLog options:
    1. Static options
    2. Dynamic options:
      1. Variables
      2. Filters
  2. Coding:
    1. Changing options at run-time
    2. Custom attributes
    3. Events
    4. Subclassing
    5. Low-level handlers
    6. Modifying code of EurekaLog itself

Important Note: please see most recent version of this documentation here.

EurekaLog options

EurekaLog options is the most simple way to affect on EurekaLog. They were specifically designed for that purpose. Most customizations can be done by using options.

Static options

EurekaLog stores per-project configuration in options file for your project (it’s .dproj/.cbproj for new Delphi/C++ Builder versions). Each time you build your project with EurekaLog – these options are inserted into final .exe file (or DLL). Then EurekaLog’s code can use these options at run-time.

Therefore, you can set options during design-time – and they will be accounted when application is run. In other words, EurekaLog project options works exactly as standard project options dialog.

To view/edit options – you must first open a project in your IDE. Then you should use “Project”/”EurekaLog options” menu command:

Opening EurekaLog options dialog for current project

(You can also invoke this command if you don’t have opened project, but then you’ll edit default options for each new project).

The dialog itself is similar to project options dialog from Delphi/C++ Builder:

EurekaLog project options dialog
(click to enlarge/zoom in)

You can see options categories on the left part (TreeView). Click on any category or sub-category to view and/or change options inside this category.

With this dialog you may change EurekaLog behaviour – to save bug report to disk or not, and where to save it, and what will be inside bug report, and should it be sent to you (as developer), and many other things.

Options are preset to fulfil common needs of developers. As you may guees, not always these “common needs” is what you specifically need in your own project. So we suggest you just to walk through options dialog to get yourself familiar with available options and alter them as you need. Each options has a detailed description in our help system. Yes, F1 works, if you’ve installed local help files during installation of EurekaLog (which is by default). But you may always visit our online help. Moreover, each option has short explanation in the hint. Just hover option’s control with mouse cursor and wait a little:

Popup hint with explanation of the option under the mouse cursor
(click image to enlarge/zoom in)

Conclusion:

  • + easy to use, no coding is necessary
  • options are static (i.e. set at design time)

Dynamic options

There are two additional features to mitigate “static” negative effect of options (see above).

Variables

Environment variables are a set of dynamic named values that can affect the way running processes will behave on a computer. They can be said in some sense to create the operating environment in which a process runs. For example, an environment variable with a standard name can store the location that a particular computer system uses to store temporary files – this may vary from one computer system to another. A process which invokes the environment variable by (standard) name can be sure that it is storing temporary information in a directory that exists and is expected to have sufficient space.

You can use environment variables in any text values in your project settings. You can insert variable by using “Variables” window. Variable is inserted as special tag. When you run your application at run-time, any variable value will be replaced with actual value, which is calculated at run-time.

For example, if you set your folder for saving bug-report to “%APPDATA%\MyBugReports” then your bug reports will be saved to C:\Users\UserName\AppData\Roaming\MyBugReports\ or C:\Documents and Settings\UserName\Application Data\MyBugReports – depending on real value of %APPDATA% variable at run-time.

Note: variables names are case-insensitive.

When you’re in your EurekaLog project options (see above), you can click on “Variables” button at dialog’s bottom:

“Variables” button in EurekaLog project options
(click to enlarge/zoom in)

Click on this button and you will see such window:

“Variables” dialog

“Copy” button will close the window with copying selected variable into clipboard. Alternatively: you can just double-click on variable in the list.
“Close” button will close the window without any action.

Suggested action’s sequence:

  • Open “Variables” window.
  • Select variable that you want to use.
  • Click “Copy” (or double-click variable). Dialog will be closed.
  • Paste variable name from clipboard (Ctrl + V or Shift + Ins) to target setting’s edit box.

Note: this dialog suggests you only build-in special pseudo-variables (those with names started with “_”) and commonly used variables. However, you can use any environment variable (even if it’s not listed in this dialog).
Note: you can also use relative file paths. For example, any path which starts with . (dot) will be relative to your current executable (regardless of actual current folder, which may be changed, say, by system open dialog). For example, “.\BugReport.el” means file in the same folder as your executable.

See more:

So, while variables is an easy way to add some dynamic behaviour to EurekaLog options, their powers are limited. There may be no variable for your specific need or it may be not applicable to desired options (such as checked/unchecked option kind).

Filters

Exception filter is a filter which can alter EurekaLog’s behavior based on some properties of exception. It is a easy way to customize EurekaLog on per-exception basis without writing code.

Usually exceptions are identified by exception’s class name (such as ‘Exception’, ‘EAccessViolation’, ‘EStreamReadError’, etc.). You can also identify exception by source location. And you can identify exception by its type (handled or unhandled). Once exception is identified – you can change handler for it (none, RTL or EurekaLog), dialog class (to any of existing dialog classes), override error message or set action (restart or terminate). Remember, that you can also use environment variables.

Exception filters are applied before processing exception. Filters are applied in order from top to bottom. First matched filter is applied.

Example of 3 exceptions filters added to options

Most typical usage for exceptions filters include:

  • Completely ignore particular exception type. This is useful for such exceptions as EAbort. You may use similar exception types in your code, so now you can use exception filters feature to completely hide such exceptions. Set handler to “none”. No error dialog will be shown. No bug report will be created.
  • Excluding certain exceptions from EurekaLog’s processing. For example, when disk free space is low and you try to create or write a file – an exception about insufficient disk space will be raised. You usually want this exception to be shown as error to the end user (so he/she can free some disk space and retry the operation), rather than generating bug report (and optionally sending it to you). That’s because this exception is not a bug in your code, there is nothing to fix. So you may create filter for such exceptions (they are called “expected” exceptions). Set handler to RTL, and this exception will be handled as usual (by showing error message), but no EurekaLog work will be done for it (no EurekaLog error dialog, no bug reports, etc.).
  • Some exceptions (such as access violation) are low-level. Their message contains some technical information, but it’s completely useless for most users (which are not programmers). Seeing such “cryptic” error messages may be confusing (“gosh, what should I do with it? Is it even a error? Or it asks me something that I don’t understand?”), so it may be useful to hide them. It’s better to show more user-friendly message like “Sorry, there was a error in application. Please, let us know about this problem and restart application.” Such message is far more descriptive. It explains what happenned (an error) and what to do (report to developers and restart application). You may create exception filters for such exceptions, set handler to “EurekaLog” and override a error message. You may additionally enable termination/restart features for these exceptions. Note: message override affects only error message in visual dialogs. Bug reports always contain information about original exception (with original error message).

There may be other use for exception filters (just use your imagination). But the above are the most popular ones.

Note: exceptions filter can also be created from code (see below).

Coding

While the above methods do not require writing code and provide some degree of dynamic changes at run-time, they are still limited and not suitable for custom, not common cases. So, when you have specific need that can’t be satisfied by the above – then you’ll have to write some code.

Changing options at run-time

One of the simplest customizations is changing EurekaLog options from the code. ExceptionLog7 unit declares global function CurrentEurekaLogOptions. This function returns TEurekaModuleOptions class (which is declared in EClasses unit), which contains properties corresponding to EurekaLog’s options. I.e. almost each property (that you can change in EurekaLog project options dialog) is presented as property in TEurekaModuleOptions class. For example, you may write a program which is able to work either as Win32 service or as GUI front end – depending on the way it was launched. You probably want to have differnt bug reports for each of this mode. And Win32 service can’t have visual error dialogs. Obviosly, this can’t be solved by setting options at design-time, since trigger event happens at run-time. So, you setup common options at design time and write such code, which sets the differences:

uses
  ETypes, EClasses, ExceptionLog7;

...

initialization

  if IsWin32Service then
  begin
    CurrentEurekaLogOptions.OutputPath := '%APPDATA%\MySoftware\Win32Service\';
    CurrentEurekaLogOptions.ExceptionDialogType := edtService;
  end
  else
  begin
    CurrentEurekaLogOptions.OutputPath := '%APPDATA%\MySoftware\GUIFrontEnd\';
    CurrentEurekaLogOptions.ExceptionDialogType := edtMSClassic;
  end;

end.

Note: some options (such as build options) affects compilation stage. Thus, they can’t be changed at run-time when file was already compiled.
Note: some options (such as leaks control) requires special rules for setting up. That’s why they are controled with other means, not with options class. However, 90% of options can be freely changed via this class.
Note: needless to say that you may use environment variables and exception filters from code too. You can alter exception filters via CurrentEurekaLogOptions.ExceptionsFilters property.

CurrentEurekaLogOptions is a global function which contains default options for your application in run-time. It affects all exceptions and all threads. Typically, you alter these options at startup (either in initialization section of some unit or in begin/end of .dpr file).

Often there is need to alter option only for some exceptions. EurekaLog provides additional feature for this: events and event hanlders.

Custom attributes

New Delphi and C++ Builder IDEs offer extented RTTI with support of custom attributes. EurekaLog is able to use custom attributes to alter behaviour for exception types. This is similar to exception filters. Using exception filters is simple, but sometimes it’s not very convenient. So, instead you can define EurekaLog behaviour right when you declare exception classes (this code will be ignored if there is no EurekaLog installed).

Custom attributes are declared in EClasses unit. The following attributes are declared:

type
  EurekaLogHandler = class(TCustomAttribute)
  strict private
    FHandler: TFilterHandlerType;
  public
    constructor Create(Value: TFilterHandlerType);
    property Handler: TFilterHandlerType read FHandler;
  end;

  EurekaLogMessage = class(TCustomAttribute)
  strict private
    FMessage: String;
  public
    constructor Create(Value: String);
    property Message: String read FMessage;
  end;

  EurekaLogAction = class(TCustomAttribute)
  strict private
    FAction: TFilterActionType;
  public
    constructor Create(Value: TFilterActionType);
    property Action: TFilterActionType read FAction;
  end;

  EurekaLogDialog = class(TCustomAttribute)
  strict private
    FDialog: TExceptionDialogType;
  public
    constructor Create(Value: TExceptionDialogType);
    property Dialog: TExceptionDialogType read FDialog;
  end;

Here is a sample on how to use them:

type
  // ETestException will be ignored by EurekaLog and it always will be handled by your application
  [EurekaLogHandler(fhtRTL)]
  ETestException = class(Exception);

  // Exception message will be replaced
  [EurekaLogMessage('Sorry, there was an error.')]
  ECustomMessage = class(Exception);

  // Switch dialog to EurekaLog-Detailed style 
  [EurekaLogDialog(edtEurekaLogDetailed)]
  EDialogException = class(Exception);

You get the idea – when you declare exception type, you can add attributes to it. Each attribute will modify EurekaLog behaviour for exceptions of this class only. This works the same as exception filters (actually, internally custom attributes just creates new filter rule).

To learn more about custom attributes – visit RAD Studio help.

Events

EurekaLog’s event is similar to standard Delphi/C++ Builder events, such as OnClick for TButton. Event handler is callback procedure or method, which you regiter for some event. EurekaLog will call your event handler (i.e. your code) each time this event occurs. There are many events available. Most commonly used are OnExceptionNotify and OnExceptionAction.

Note: each event handler is declared as both method or procedure. You can use either option, there is no difference between method and procedure, so you can use whatever you want.

There are two ways of registering your code as event handler. The most simple way is to use TEurekaLogV7 component. This component is similar to standard TApplicationEvents component. Just drop it on the form and assign handlers by using “Events” page in Object Inspector:

TEurekaLogV7 component on the form and one event hanlder assigned

While this is very simple way, you should be awared that your event handlers will be registered as long as host form lives. Thus, your event handler will not be invoked for events during initialization/finalization of your application. For this reason:

  • While there is no limitation on TEurekaLogV7 components in one application and no restrictions on the form (it can be main form and any child/auxilary form), we recommend to use main form as host for TEurekaLogV7 component whenever possible.
  • We recommend using component only for such events that depends on your host form. For example, event hanlder may add currently opened document to bug report. Such event handler is best registered with component. We don’t recommend using component for more generic event handlers. Use code registration (see below).

Note: registering event handler via component will create/use event handler as method of the object (i.e. form), not as callback procedure.

Second method to register event handler is to call RegisterEventName function, where Name is a name of event. For example, you may use such code:

unit Unit1;

interface

...

implmenetation

uses
  EEvents;

// Some your routine to add a message to application log
procedure AddToLog(const AMessage: String);
begin
  ...
end;

// Your handler for OnExceptionNotify event
procedure MyHandler(const ACustom: Pointer; AExceptionInfo: TEurekaExceptionInfo; var AHandle: Boolean; var ACallNextHandler: Boolean);
begin
  if AExceptionInfo.ExceptionClass = 'EMyException' then
  begin
    AddToLog(AExceptionInfo.CallStack.ToString);
    AHandle := False;
  end;
end;

initialization
  
  RegisterEventExceptionNotify(nil, MyHandler);

end.

This sample event handler will log call stack of each exception of EMyException type, and it will disable EurekaLog’s processing for these exceptions.

As you can see – you need to write all code by yourself (i.e. handler registration and procedure header/prototype). All events are declared in EEvents unit.

Note: you may unregister registered event handler by using UnregisterEventName function, but it’s not required.

That’s almost all for events and event hanlders, but we must discuss one more important thing. Once exception is raised, EurekaLog options are captured from CurrentEurekaLogOptions function. Each exception is accompanied by TEurekaExceptionInfo class, which contains property and options for each exception. Further changes in CurrentEurekaLogOptions will not affect already raised exceptions. Threfore, your changes of CurrentEurekaLogOptions inside any event handler for exceptions will have no effect for current exception. It will affect only future exceptions. To change options of current exceptions – use Options property of TEurekaExceptionInfo class. For example:

unit Unit1;

interface

...

implmenetation

uses
  EEvents;

// Your handler for OnExceptionNotify event
procedure MyHandler(const ACustom: Pointer; AExceptionInfo: TEurekaExceptionInfo; var AHandle: Boolean; var ACallNextHandler: Boolean);
begin
  // The same as exception filter for EMyException which changes dialog to "EurekaLog" style
  if AExceptionInfo.ExceptionClass = 'EMyException' then
    AExceptionInfo.Options.ExceptionDialogType := edtEurekaLog;
end;

initialization
  
  RegisterEventExceptionNotify(nil, MyHandler);

end.

The similar concern is applied for many other objects in EurekaLog. Such as dialogs, send engines, log report builders, call stack classes, etc. They all have Options property, which is captured from their “parent” or CurrentEurekaLogOptions if there is no “parent”.

To summarize:

  • Event hanlders offer you unlimited ability for customizing EurekaLog, but only within certain points of interest (i.e. events). You can’t alter whole processing logic by using only event handlers.

Subclassing

When event handlers are not enough, you need to override parts of EurekaLog’s code to fulfil your needs. For example, if you want to alter icon in error dialogs or replace dialog as whole, if you want to change processing (exchange order of saving bug report and sending it), etc. or if you want to extend EurekaLog (like add new dialog or new send method) – then you can’t use event handlers, because there is no event for that. But what you can do is to replace or extend EurekaLog’s code with your own.

High level code of EurekaLog is done as classes. Therefore, if you need to alter minor point in EurekaLog (adjust it a little), then you may create your own class as child class to standard EurekaLog class, override some virtual method, write your own bevahior code, call inherited method to get standard behaviour, and so on. I.e. the usual things that you may do with tree of classes. Or you may write your own class completely from scratch (inheriting from base abstract class).

Note: please note that (unlike events) EurekaLog classes are constantly evolving. There are new methods and features introduced as time passes. Therefore your code that uses subclassing may need to be adjusted for new EurekaLog versions.

For that reason classes are described much less in documentation than other methods. Because they are used much rarely and changes more often. To study what you can do with classes you will have to read interface sections of units with declaration of classes. There you can see class inheritance, interesting methods to override, etc. You can do this even in EurekaLog’s editions without full source code. We provide headers for your reference.

The common rule is: if class can be only one (like log builder class), then class type is registered via global class variable. All you have to do is to write your own class and assign it to variable during initialization. Otherwise, if there may be various classes (like dialogs or send engines), then you have to create your own class, register it in global list via various RegisterSomething functions (they are declared in the same place as base abstract classes), and switch EurekaLog to use your class via options.

Let’s see some code examples to make things clear.

Example #1: replacing dialog icon.
EurekaLog offers you feature to use generic error icon or icon of your application for error dialogs. However, you may want to use some other icon for that. There is no such feature in EurekaLog, but you can easily fix that with such code:

unit Unit1;
 
interface
 
// ...
 
implementation
 
uses
  EBase, ECore, EModules, EListView, EDialog, EDialogWinAPIMSClassic;
 
{$R *.dfm}
 
// To test our customization code
procedure TForm1.Button1Click(Sender: TObject);
begin
  raise Exception.Create('Error Message');
end;
 
type
  // Our child class - inheriting from standard TMSClassicDialog 
  TMSClassicDialogCustom = class(TMSClassicDialog)
  private
    FCustomIcon: HBITMAP; // our new icon
  protected 
    // Init/done:
    procedure WindowInit; override;
    procedure WindowDone; override;
    // Replacing icon drawing:
    function Paint(const ADC: HDC; const ARect: TRect): Integer; override;
  end;
 
{ TMSClassicDialogCustom }
 
procedure TMSClassicDialogCustom.WindowInit;
var
  Ico: HIcon;
begin
  inherited;
 
  Ico := LoadIcon(HInstance, 'CUSTOMICON');
  FCustomIcon := IcoToBmp(Ico, GetStockObject(WHITE_BRUSH), 32, 32);
end;
 
function TMSClassicDialogCustom.Paint(const ADC: HDC; const ARect: TRect): Integer;
begin
  Result := inherited;
  DrawBmp(ADC, FCustomIcon, MonitorLeft, MonitorTop, 32, 32);
end;
 
procedure TMSClassicDialogCustom.WindowDone;
begin
  DeleteObject(FCustomIcon);
  inherited;
end;
 
initialization

  if IsEurekaLogInstalled then
  begin
    // You have to register dialog before using it:
    RegisterDialogClass(TMSClassicDialogCustom);
    // Once registered - now you can use it in options:
    CurrentEurekaLogOptions.ExceptionDialogType := TMSClassicDialogCustom.ClassName;
  end;

end.

Obviosly, this code replaces icon for one particular dialog type (MS Classic style). If you want to alter icon for several classes, then you have to write more your own child classes.

Example #2: replacing content of bug reports.
Recently we got a request from a customer. They use their own system to collect and sort bug reports generated by EurekaLog. Previosly they worked with EurekaLog 6, but then upgraded to EurekaLog 7. Bug reports from EurekaLog 7 has slightly different structure than reports from EurekaLog 6 (new fields and columns). Therefore, new format of bug report file breaks their old code. Of course, they can update/improve their code or… switch EurekaLog to produce bug reports in old format. This can also be useful if you’re migrating to EurekaLog from other exception tracers solutions (such as JCLDebug/JCLHookExcept, madExcept or Exception Magic). You can force EurekaLog to generate bug report in the format of your previous solution, so you won’t have to re-write other code. Obviosly, there is no such build-in feature in EurekaLog.

Here is a simple code that creates bug report in format of EurekaLog 6:

uses
  EConsts, ETypes, EClasses, ECallStack, EException, EEvents, ELogBuilder;
 
type
  // EurekaLog 6 format will be altered from default EurekaLog 7 format,
  // that's why we inherit from EurekaLog 7 builder class and 
  // replace only some methods
  TEurekaLog6Builder = class(TLogBuilder)
  public
    function CreateGeneralText: String; override;
    function CreateCallStackText: String; override;
  end;
 
{ TEurekaLog6Builder }
 
// Replace header of the bug report (to change "7" to "6" in header)
function TEurekaLog6Builder.CreateGeneralText: String;
begin
  Result := inherited;
  Result := 'EurekaLog 6' + Copy(Result, Pos(sLineBreak, Result), MaxInt);
end;
 
// Replace call stack (remove new columns)
function TEurekaLog6Builder.CreateCallStackText: String;
var
  Stack: TEurekaCallStack;
  Formatter: TEurekaBaseStackFormatter;
begin
  Stack := nil;
  try
    if CallStack  nil then
    begin
      Stack := TEurekaCallStack.Create;
 
      Stack.Assign(CallStack);
 
      Stack.Formatter.Assign(Options);
      Stack.Formatter.CaptionHeader := Options.CustomizedExpandedTexts[mtDialog_CallStackHeader] + EHeaderSuffix;
    end;
 
    Formatter := TEurekaStackFormatterV6.Create;
    try
      Formatter.Assign(Options);
      Formatter.CaptionHeader := Options.CustomizedExpandedTexts[mtDialog_CallStackHeader] + EHeaderSuffix;
 
      Result := CallStackToString(Stack, Options.CustomizedExpandedTexts[mtDialog_CallStackHeader] + EHeaderSuffix, Formatter);
    finally
      FreeAndNil(Formatter);
    end;
  finally
    FreeAndNil(Stack);
  end;
end;
 
// Rename .el files to old .elf files
procedure CustomizeFileNames(const ACustom: Pointer; AExceptionInfo: TEurekaExceptionInfo; const AFileType: TEurekaLogFileType; var AFileName: String; var ACallNextHandler: Boolean);
begin
  if AnsiLowerCase(ExtractFileExt(AFileName)) = '.el' then
    AFileName := ChangeFileExt(AFileName, '.elf');
end;
 
initialization

  // Register bug report builder:
  LogBuilderClass := TEurekaLog6Builder;

  // Register event handler for file names:
  RegisterEventCustomFileName(nil, CustomizeFileNames);

end.

This sample uses a combination of custom class and event handler to reach the desired goal.

Example #3: override original class.
Suppose that you want to alter original behaviour/class, but don’t want to create a new class (with new name), because this will require you to alter options as well. Instead, you want just to set up options at design time and provide altered behaviour at run-time.

For example, when you post bug to Mantis, a issue title is composed. EurekaLog does not provide way to alter it, because it’s used to identify tickets. You may want to alter it (say, by appending more info, so title becomes more descriptive). Here is how you can do that:

uses
  EConsts,
  ESend,
  ESendAPIMantis;

type
  // Trick: use the same class name as original class
  // You'll have to append unit name to class ident to avoid compiler confusion
  TELTrackerMantisSender = class(ESendAPIMantis.TELTrackerMantisSender)
  protected
    function ComposeTitle: String; override;
  end;

// This is a default implementation of the method, 
// you can replace it with arbitrary code
function TELTrackerMantisSender.ComposeTitle: String;
begin
  if BugAppVersion  '' then
    Result := Format('%s (Bug %s; v%s)', [BugType, BugID, BugAppVersion])   
  else
    Result := Format('%s (Bug %s)', [BugType, BugID]); 
  Log(Format('Title = ''%s''', [Result]));
end;

initialization

  // Register send class to be the first in the list.
  // Default class (by EurekaLog) will be listed later.
  // Any search for class by name will find our class, because it's listed first
  RegisterSenderFirst(TELTrackerMantisSender); 

end.

With this trick you don’t have to change options. You can just set options at design-time. The important part here is to register your class first, which is archived by using registering function with “First” suffix.

Note: please note that this is not recommended way to work with tickets in Mantis. We suggest you to create custom fields for your project (Mantis configuration). Fill custom fields with information (EurekaLog configuration). And show some of these fields in list of tickets (Mantis configuration). That way you will archive the desired effect (to see more info about each ticket in list), but also additionally gain some benefits: you will be able to sort/filter by custom fields, you will not break default EurekaLog tickets identification.

Example #4: a custom dialog.
You may be not satisfied by standard EurekaLog dialogs, so you may want to use your own dialog. Here is what you need to do: create class inheriting from abstract TBaseDialog class (EDialog unit), register it, and set ExceptionDialogType option. This example is similar to example #1. But this time we create dialog from scratch, we’re not using ready classes.

The following sample shows four new dialog classes. Actually, this is just a code from EurekaLog itself, but it’s short and simple to illustrate the point:

uses
  EDialog, EClasses, ETypes;

type
  // "Empty" dialog that does nothing at all
  TNullDialog = class(TBaseDialog)
  protected
    procedure Beep; override;
    function ShowModalInternal: TResponse; override;
  public
    class function ThreadSafe: Boolean; override;
  end;

  // MessageBox dialog
  TMessageBoxDialog = class(TBaseDialog)
  protected
    function ShowModalInternal: TResponse; override;
    procedure Beep; override;
  public
    class function ThreadSafe: Boolean; override;
  end;

  // A variant of MessageBox with more detailed message (with call stack)
  TMessageBoxDetailedDialog = class(TMessageBoxDialog)
  protected
    function ExceptionMessage: String; override;
  end;

  // "Default" dialog - dialog that invokes standard dialog (non-EurekaLog)
  TRTLHandlerDialog = class(TBaseDialog)
  protected
    procedure Beep; override;
    function GetCallRTLExceptionEvent: Boolean; override;
    function ShowModalInternal: TResponse; override;
  end;

{ TNullDialog }

procedure TNullDialog.Beep;
begin
  // does nothing - no beep needed
end;

// Main method: do nothing, return success
function TNullDialog.ShowModalInternal: TResponse;
begin
  SetReproduceText(ReproduceText);

  Result.SendResult := srSent;
  Result.ErrorCode := ERROR_SUCCESS;
  Result.ErrorMessage := '';
end;

// Indicate that we can be called from any thread (this should be False for VCL/CLX/FMX dialogs)
class function TNullDialog.ThreadSafe: Boolean;
begin
  Result := True;
end;

{ TMessageBoxDialog }

procedure TMessageBoxDialog.Beep;
begin
  // does nothing - beep is invoked by Windows.MessageBox in TMessageBoxDialog.ShowModalInternal
end;

// Main method 
function TMessageBoxDialog.ShowModalInternal: TResponse;
var
  Flags: Cardinal;
  Msg: String;
begin
  // Set default result
  Result.ErrorCode := ERROR_SUCCESS;
  Result.ErrorMessage := '';
  if SendErrorReportChecked then
    Result.SendResult := srSent
  else
    Result.SendResult := srCancelled;

  // Prepare message to show
  Msg := ExceptionMessage;
  if ShowSendErrorControl then
  begin
    Msg := Format(Options.CustomizedExpandedTexts[mtSend_AskSend], [Msg]);
    Flags := MB_YESNO;
  end
  else
    Flags := MB_OK;
  Flags := Flags or MB_ICONERROR or MB_TASKMODAL;
  if SendErrorReportChecked or (not ShowSendErrorControl) then
    Flags := Flags or MB_DEFBUTTON1
  else
    Flags := Flags or MB_DEFBUTTON2;

  // Call actual MessageBox and set result
  case MessageBox(Msg,
                  Options.CustomizedExpandedTexts[mtDialog_Caption],
                  Flags) of
    0: Result.ErrorCode := GetLastError;
    IDYes:
       Result.SendResult := srSent;
    IDNo:
       Result.SendResult := srCancelled;
  end;

  // Save error code/error message for failures
  if Result.ErrorCode  ERROR_SUCCESS then
  begin
    Result.SendResult := srUnknownError;
    Result.ErrorMessage := SysErrorMessage(Result.ErrorCode);
  end
  else
    SetReproduceText(ReproduceText);
end;

// Can be called from any thread
class function TMessageBoxDialog.ThreadSafe: Boolean;
begin
  Result := True;
end;

{ TRTLHandlerDialog }

// Indicate desire to invoke RTL handler
function TRTLHandlerDialog.GetCallRTLExceptionEvent: Boolean;
begin
  Result := True;
end;

function TRTLHandlerDialog.ShowModalInternal: TResponse;
begin
  SetReproduceText(ReproduceText);

  Result.SendResult := srRestart;  // means "call RTL handler"
  Result.ErrorCode := ERROR_SUCCESS;
  Result.ErrorMessage := '';
end;

procedure TRTLHandlerDialog.Beep;
begin
  // Does nothing - transfer work to RTL handler
end;

{ TMessageBoxDetailedDialog }

// This one is a bit more complex - we want to add call stack to error message.
// However, default form is not very readable with variable-width fonts.
// That's why first we need a way to format call stack in another way.

type
  // Our new formatter
  TMessageBoxDetailedFormatter = class(TEurekaBaseStackFormatter)
  protected
    function GetItemText(const AIndex: Integer): String; override;
    function GetStrings: TStrings; override;
  end;

// Forms one line of call stack
function TMessageBoxDetailedFormatter.GetItemText(const AIndex: Integer): String;
var
  Cache: TEurekaDebugInfo;
  Info: PEurekaDebugInfo;
  ModuleName, UnitName, RoutineName, LineInfo: String;
begin
  Info := CallStack.GetItem(AIndex, Cache);

  ModuleName := ExtractFileName(Info^.Location.ModuleName);
  UnitName := Info^.Location.UnitName;

  if UnitName = ChangeFileExt(ModuleName, '') then
    UnitName := ''
  else
    UnitName := '.' + UnitName;

  RoutineName := CallStack.ComposeName(Info^.Location.ClassName, Info^.Location.ProcedureName);
  if RoutineName  '' then
    RoutineName := '.' + RoutineName;

  if Info^.Location.LineNumber > 0 then
    LineInfo := Format(',%d[%d]', [Info^.Location.LineNumber, Info^.Location.ProcOffsetLine]) // Do Not Localize
  else
    LineInfo := '';

  Result := ModuleName + UnitName + RoutineName + LineInfo;
end;

// Formats entire call stack
function TMessageBoxDetailedFormatter.GetStrings: TStrings;
var
  ThreadID: Cardinal;
  I: Integer;
  Line: String;
  Stack: TEurekaBaseStackList;
begin
  if not Assigned(FStr) then
  begin
    FStr := TStringList.Create;
    FModified := True;
  end;
  if FModified then
  begin
    Stack := CallStack;
    CalculateLengths;
    FStr.BeginUpdate;
    try
      FStr.Clear;
      FStr.Capacity := Stack.Count;

      if Stack.Count > 0 then
      begin
        ThreadID := Stack.Items[0].ThreadID;
        for I := 0 to Stack.Count - 1 do
        begin
          if (Stack.Items[I].Location.Module  0) and
             (Stack.Items[I].Location.DebugDetail in [ddUnit..ddSourceCode]) and
             (Stack.Items[I].ThreadID = ThreadID) then
          begin
            Line := GetItemText(I);
            if (FStr.Count  Line) then
              FStr.Add(Line);
          end;
        end;
      end;
    finally
      FStr.EndUpdate;
    end;
    FModified := False;
  end;
  Result := FStr;
end;

// Append call stack to error message
function TMessageBoxDetailedDialog.ExceptionMessage: String;
const
  MaxLines = 15;
var
  Formatter: TMessageBoxDetailedFormatter;
  Stack: TEurekaBaseStackList;
begin
  {$WARNINGS OFF}
  // Abstract methods are intended here. It is like assert: they should not be called.
  Formatter := TMessageBoxDetailedFormatter.Create;
  {$WARNINGS ON}
  try

    if Assigned(CallStack) then
      Formatter.Assign(CallStack.Formatter);
    Formatter.CaptionHeader := '';

    Stack := nil;
    try
      if CallStack  nil then
      begin
        Stack := TEurekaStackList.Create;
        Stack.Assign(CallStack);
        while Stack.Count > MaxLines do
          Stack.Delete(Stack.Count - 1);
      end;
      Result := inherited ExceptionMessage + sLineBreak + sLineBreak +
                CallStackToString(Stack, '', Formatter);
    finally
      FreeAndNil(Stack);
    end;
  finally
    FreeAndNil(Formatter);
  end;
end;

As you can see, the central method here is ShowModalInternal. It does all the work. It’s abstract and must be overwritten in child classes. All other methods of TBaseDialog are virtual, but not abstract. They contain default behaviour. You can override them to alter behaviour, but you don’t have to. Base dialog class contains large number of helpers (methods and properties). All that dialog needs to do is to invoke these methods in right order. Therefore any child class can use powerful tools to quickly build new dialog.

Note: there is another abtract dialog class – TWinAPIDialog from EDialogWinAPI unit. It’s useful if you want to create new dialog based on direct WinAPI calls, rather than using ready functions or frameworks (VCL/CLX/FMX).

Important note: dialog class is responsible for almost whole exception processing. That’s because “dialog” don’t have to be visual. Think about Win32 service, system log, WER (Windows Error Reporting), etc. So, this is not always possible to distinguish between “error dialog” and “exception processing”. That’s why these concepts are both controlled by single “dialog” class. As we saw above, a major method for visual dialog is ShowModalInternal method. But real entry point is Execute method. Default implementation goes like this:

function TBaseDialog.Execute: TResponse;
var
  CanSaveReport: Boolean;
begin
  try
    SaveCurrentEnvironment;
    try
      // Preparation
      SetupFileNames;
      FDuplicate := CalcDuplicatedException(FCanSend);

      // Saving bug report
      if not Restarted then
      begin
        SetReproduceText('');
        if DeleteLogAtVersionChange then
          DeleteOldLog;
        MakeScreenshot;
        AddCustomData;
        if PresaveReport and SaveLogFile then
          SaveBugReport; // Pre-save to get log in case of crash in dialog
        Beep;
      end
      else
        FSaved := (PresaveReport and SaveLogFile);

      // Actually visible part:
      Result := ShowModal; // invokes ShowModalInternal with events and error handling

      // Restart dialog? 
      // E.g. User clicked on "see more" link, 
      // so we need to change MSClassic -> EurekaLogDetailed
      if Result.SendResult = srRestart then
        Exit;

      // Save bug report
      CanSaveReport := SaveLogFile and
                       (
                         Succeeded(Ord(Result.SendResult)) or
                         (Result.SendResult = srCancelled) or
                         (not PresaveReport)
                       );
      if CanSaveReport then
        SaveBugReport; // Re-save to update changed fields (like reproduce text)

      if Succeeded(Ord(Result.SendResult)) and CanSend then
      begin
        PrepareFilesForSend;

        Result := SendBugReport;

        if Failed(Ord(Result.SendResult)) then
        begin
          if CopyLogInCaseOfError then
            CopyReportToClipboard;
          if SaveCompressedCopyInCaseOfError then
            SavePackedCopy;
        end
        else
        if DeleteLogAfterSuccessfulSend then
          DeleteCurrentLog;

        ShowSendResult(Result);
        if CanSaveReport then
          UpdateSendInformationInLog(Result.SendResult);
      end
      else
      begin
        DoEventExceptionAction(ExceptionInfo, atSendCancelled);
        if CanSaveReport then
          UpdateSendInformationInLog(srCancelled);
      end;

    finally
      RestoreCurrentEnvironment;
    end;

    CheckTermination;
    if Options.CustomFieldBool[difTerminateApplication] then
      TerminateApplication;
  except
    on E: Exception do
    begin
      Result.ErrorCode := ERROR_GEN_FAILURE;
      Result.ErrorMessage := E.Message;
      Result.SendResult := srUnknownError;
    end;
  end;
end;

As you can see, there is the whole processing of exceptions: saving bug report, displaying dialog, updating bug report with new values (e-mail/steps to reproduce), sending report, restarting application. You rarely need to alter this method, rather you will override methods which are called by it. This method is shown here just to illustrate the point that dialog controls more than just visual behaviour.

As final words on subclassing – here is the list of classes, units and functions for this (as of EurekaLog 7.0.02):

  • Base dialog class: EDialog.TBaseDialog.
  • Dialog class registration: EDialog.RegisterDialogClass.
  • Base send engine class: ESend.TELUniversalSender.
  • Send engine class registration: ESend.RegisterSender.
  • Base debug information provider class: EClasses.TELDebugInfoSource.
  • Debug information provider registration: EDebugInfo.RegisterDebugInfoSource.
  • Base call stack class: ECallStack.TEurekaBaseStackList.
  • Default call stack class: ECallStack.EurekaCallStackClass.
  • Specific call stack classes: ECallStack.TracerMethodsClasses.
  • Base log builder class: ELogBuilder.TBaseLogBuilder.
  • Default log builder class: ELogBuilder.LogBuilderClass.
  • Base hung detection thread class: EFreeze.TFreezeThread.
  • Default hung detection thread class: EFreeze.FreezeThreadClass.

Low-level handlers

Classes are used by high level code in EurekaLog. Sometimes customizations of high level code is not enough. Luckily, EurekaLog 7 offers you a way to change almost anything. Low level points for customizations are presented by global variables of procedural types. These procedural variables are invoked by EurekaLog, and it points to EurekaLog code by default. You may write your own code and write pointer to it into these variables.

Note: these global variables are not documented and never will be. You can use them on your own risk.

Here is the list of available low-level customization possibilities:

  • EInject unit:
    • EventUnhandledExceptionFilter
    • EventExceptProc
    • EventExceptClsProc
    • EventExceptObjProc
    • EventRaiseExceptionProc
    • EventGetExceptionStackInfoProc
    • EventGetStackInfoStringProc
    • EventCleanUpStackInfoProc
    • EventExceptionDispatcher
    • EventIndyThreadHandleException
  • EExceptionHook unit:
    • _IsUnexpected
  • ELowLevel unit:
    • _InitDoneErrorHandler
    • _SafeExecLog
    • _ConsoleLogger
  • EHook._GetSymbolAddr
  • EBase unit:
    • _InternalError
    • _RaiseExpected
    • _OnPanic
  • EAppType unit:
    • _CustomMessageBox
    • _GetMainWnd
  • Almost all routines in EMemLeaks and EResLeaks units.
  • EThreadsManager unit:
    • _GetRealAddresses

There are some other points to override default handlers, but they are almost useles for customizations, since they are used for very specific EurekaLog’s needs.

The most important thing about low level handlers is that the initialization order is important. It’s highly not recomended to alter these variables during actual work of your application. You should modify handlers only during initialization/finalization process. It’s also strictly recommended to save previous handler before installing your own handler and revert it back (uninstall) on finalization.

Modifying code of EurekaLog itself

When nothing else helps – you can alter source code of EurekaLog. Of course, it’s possible only if you have edition with full source code (all other methods of customizations listed above are applicable for any edition of EurekaLog).

You can alter EurekaLog code to absolutely every behavior that you want. Then you need to recompile it for these changes to take effect. See also: how to recompile EurekaLog.

Please note that any upgrading or reinstalling EurekaLog will overwrite EurekaLog files, thus your customizations will be lost (unless you made a backup). You’ll have to re-implement all customizations each time you upgrade EurekaLog. For this reason use this method as last resort measure only. Prefer the above discussed methods whenever possible. If you still has to modify EurekaLog sources – please, let us know why you do that. We can add your customizations in EurekaLog, so you won’t need to re-insert them into source code each time you upgrade (of course, this is only possible if your customizations has some value for other developers).

Read More

Read More

DataSnap in the Cloud

Last weekend I spoke at the Delphi Tage in Heidelberg about DataSnap In The Cloud and I promised to provide the referenced data for download. So here it is: DataSnap in the Cloud (PDF) The slides from the presentation. I omitted those slides serving transition effects only. FishFacts (Project) The modified FishFacts project. The console application project is called FishFactsServer.  It contains the changes to make it work with SQL Database in Azure as well as the patched Data.DBXMSSQLMetaDataReader.pas (XE2) to make it work with SQL (Azure) Database. Azure Cloud Service The Azure Cloud Services Project. You have to copy the FishFactsServer.exe into the WorkerRole folder after compilation and before making the package. DbDemos SQL Script SQL Script for DbDemos Database. Executing this script in SQL Managment Studio will create and populate the complete dbdemos database in a format suitable for SQL (Azure) Database.  
Read More

Flotsam and Jetsam #64

Jim McKeeth was kind enough to interview me for the The Podcast at Delphi.org.   It was fun to do.  In a previous Flotsam and Jetsam, I mentioned that I had received as gift an ASUS RT-N16 and loaded it with the TomatoUSB firmware.  So far, it’s been working great – I really like it.  The reason I did it was to be able to have better control over the Quality of Service so that I could install an Ooma Telo  Well I have done so, and am quite pleased.  I paid the $40 to have my number changed over.  It took about ten days, and now I am running the Ooma as my house phone.  I got the Ooma Telo from Amazon for $150 (a special price, apparently, as the price appears to have gone up), and paid $40 for the number transfer.  I have cancelled my phone service from Comcast, saving about $50 a month.  That means that the Ooma Telo will pay for itself in four months, and save me a pretty good chunk of change going forward.   And here’s a fun thing about the Ooma – I can take my home phone with me.  If I say, take a trip to my folks house, I can bring the Ooma, plug it in, plug in a phone, and I have my “house”  phone there wherever I am.  I don’t know why I find that amusing.  One concern I had was the fact that if the power goes out,  my phone goes out.  But that’s true for my Comcast phone as well, though it would take a while for the battery to wear out.  In addition, we live in a development with lots of neighbors, and we have cell phones.  And lots of people are starting to get rid of their house phones all together, so that turns out to be a minor concern for me anyway. Alas – Barry Kelly has moved on from Embarcadero. His contributions to Delphi are many and lasting.  I don’t know if I’ve ever met a smarter person, frankly. He’s also just a very interesting guy generally.  Good luck to you, Barry. I won’t be the first Delphi book on LeanPub.  Currently available is Parallel Programming with OmniThreadLibrary by Primož Gabrijelčič.  (You did catch that I am writing a book, right?) There are some pretty cool goodies that you can get if you buy RAD Studio XE3 right now, including a FireMonkey grid from the excellent folks at TMS Software.  It’s called the RAD XE3 Bonus pack. 
Read More

Devexpress will never support Firemonkey

After asking to staff at devexpress, they say will not support firemonkey while the API suffer of changes from Embarcadero.That are really bad news to developer express customers and in particular to Delphi users. Sadly, we will not see in years a DX crossplatafform version at all. Not strange, after all even the .NET version of devexpress don't work over linux or mac. I bet for the same lack of e**s to take risk and support users.I will have it in mind next time i click renew on my dx subscriptions, you see...
Read More

Making Sense of the Whole Delphi WinRT Thing

I'm not one of the "Low-Level" "Deep-Inside" Delphi smart guys. I'm just an average software developer who uses Delphi to create simple applications I sell to other average people. Oh, I learn a lot hanging around the smart guys but I seem to get lost when the discussions and comments take a deep dive. It's no doubt that Allen Bauer's post created quite a stir around the community and the new release of XE3. I've tried to make sense of all the buzz going back and forth but at one point it just got way over my head. Since I am just a Micro-ISV, I am looking for a simplistic answer to what this whole Delphi - WinRT crap is all about and I think I have figured it out. I posted this on the Delphi Developer group on Facebook: I've been trying to follow all the talk about what is going on with Delphi and WinRT ever since Allen Bauer's post went viral. I'm not as smart as most of you Delphi guys. Can someone please explain in very simplistic terms what it means when Delphi either can't or is excluded from creating WinRT apps? How does this effect a Micro-ISV like myself in terms of distribution and sales? I received this response... For example, you will probably not be able to sell your app through the MS Application Store, which could really hurt your exposure to prospective new customers. Okay. So I started googling Microsoft App Store and discovered a couple interesting tidbits. I started off reading a post by George Ou called ARM Battery Life Advantage Myth Lives On This lead me to a post by Steven Sinofsky called Collaborating to deliver Windows RT PCs Which lead me to another post by Steven Sinofsky called Building Windows for the ARM processor architecture Here is what I think is going on and how it effects me and you who sell software to the average consumer. Microsoft is leading a push to compete directly with the iPad. So, Microsoft invented a new operating system called WOA or Windows on ARM which in my opinion is a Reduced Instruction Set Computer. This new operating system is a subset of Windows 8 and will be available on the new WinRT PC's soon to be released. It sounds like WinRT PC's (I'd prefer they were called tablets) are a separate line of personal computers designed to compete directly with the iPad market. No disk drive, no expansion slots, one or two USB ports and completely mobile. Which requires a long life battery, hence the first post I sited above. These devices will be RISC (Reduced Instruction Set Computers) running the WOA which includes WinRT. This limits the applications to only those applications that conform to the WinRT subset of instructions. All other Non-WinRT PC's will come with a full blown Windows 8 OS in addition to the scaled down WOA running WinRT. This lets you run all the currently developed Windows Applications (those created using Delphi) and any of the new applications that conform to the WinRT subset of instructions. What does all this mean to you and I... Given that the WinRT PC's (I'd prefer they were called tablets) have a subset of the real Windows 8 OS, the only way to install software on these machines will be through the use of the Microsoft App Store. Since Microsoft controls this store they will make sure that any app in the store will run without problems on the new WinRT machines. The bottom line, we (Delphi developers) will still have a huge user base availabe to us. Not everyone will flock to these new WinRT PC's (I'd prefer they were called tablets). When EMBT finally does get the details worked out and makes it available to us... we can retool, recompile and look forward to a windfall of new WinRT customers. Enjoy - Semper FiGunny Mike
Read More

Flotsam and Jetsam #62

  • Okay, so it looks like the release of Delphi XE3 is imminent.  My friend Tim Del Chiaro (the Delphi Insider) has announce the World Tour for the release.  The official page is here.  Tim also mentions something about a new product “HTML5 Builder”.  That sounds interesting.
  • JT, the Product Manager for RAD Studio, has a blog post with more info. I’ve not dabbled much in mobile development yet, so the most interesting part was “by adding memory management features such as automatic reference counting” – that’s very intriguing.  This could add a whole new dimension to the great FreeAndNil debate
  • I’m always looking to sell stuff on ebay – so when I put in my new ASUS RT-N16 router, I thought I’d sell the old one.  Apparently, I’m not the only one doing that, as the router that Comcast gave me is worth only about 15 dollars, if that.  They are $40 at Amazon. Oh well.    I was hoping it was worth a bit more.  But hey, $15 is a lot of money, right?
  • I think I’ve said at least 453 times how much I love FinalBuilder.  So I’m always happy to pass along good news about what the folks at VSoft are up to.  Their latest is a very intriguing product called Continua CI, recently released in beta.  It’s a follow on to their FinalBuilder Server product.  I say “follow on” and not “upgrade” because it looks to be something quite a bit different and improved. Robert Love has a good write-up on it as well.    We here at Gateway Ticketing currently use Jenkins in concert with FinalBuilder, but if the licensing for Continua is favorable, it might be something for us to consider.  In any event, I always recommend looking at anything at all from the fine folks at vSoft Technologies.

Read More

Read More

Flotsam and Jetsam #61

I’ve never been a hardware or network geek, but after I read this post by Jeff Atwood about how easy it was to set up custom firmware on a router a few notches above the “cheap one they basically give you when you sign up for cable internet”, I thought that I might try it some day.  I put the Atwood-recommended Asus RT-N16 on my Amazon wish list, and lo and behold, my parents kindly gave it to me for my birthday in July.  I actually left it sitting on the shelf for a few weeks, unsure if I really wanted to use it until a friend at work told me about Ooma.  Ooma is a phone service that works over your internet connection.  It’s not true VOIP, but similar.  Once you buy the device and get it set up, you basically get free phone service (I guess you pay some taxes or something each month, but only like $4 or something).  The Ooma should save me $50 a month.  Nice.  Anyway, if you have an Ooma, you really need a router that supports Quality of Service so that your phone calls don’t get aced out when your 13 year old starts downloading some huge game or something.  So today, I broke out the router, and used these instructions to flash the firmware on the Asus router, and now I’m up and running with TomatoUSB.  Very cool.   My next step is to buy the Ooma box and get that set up.  I’ll keep you all posted, as I know that you are eager to be updated on every single little thing I do. You know, I just love all the stuff that the folks at DevJet are doing.  First, they are the impetus behind the Delphi Spring Framework, which as far as I am concerned you should treat like part of the Delphi RTL, as well as the really cool tool Documentation Insight.  Now they have release a new product that is the mirror to Documentation Insight – Documentation Generator.   You can pre-order it for 30% off, too.  What does it do?  Well, it takes all those great /// comments/documentation you wrote using Documentation Insight (which, by the way, is bundled with Delphi XE2) and turns it into online content.  For instance, here is the documentation for my HTMLWriter project.  And of course, all the documentation for the Spring4D project is online as well.  Nice. There are some interesting Delphi book projects in the works: According to Anders, Graeme Chandler is writing a FireMonkey ebook due out at the end of the month.  Not a lot of details, but intriguing. Chris Rolliston has written a book called Delphi XE2 Foundations and it’s for sale right now on Amazon.  There are two different editions, and here’s the Table of Contents.  Nick’s Opinion of the Week:  I think that if someone wants to open source their software, then they should do so.  And if they don’t want to open source their software, then they shouldn’t. And if you have a different opinion than the author of the software, then you should express it respectfully.  If your “advice” isn’t taken, then you should leave it be.  Just sayin’. 
Read More

Native controls for FireMonkey – the KickStarter project needs your help

FireMonkey does not mimic native controls perfectly, especially on OSX.  This is simply because all its controls are implemented fully in FireMonkey, and so all behaviour has to be coded - and it is very unlikely to ever get an implementation that is indistinguishable from the platform-native controls.  Platform-native is important. But, what if there was a library of native FireMonkey
Read More