DWScript now has database support classes built-in, these are based on a thin, interface-based layer, and can be used Delphi-side as well to get automatic memory management for simple DB access.

It currently supports mORMot SynDB and Universal InterBase, meaning it gets high performance native connectivity to SQLite, FireBird, Oracle, ODBC and OleDB (MySQL, MS SQLServer, MS Jet, AS400…).

Usage

Usage is very simple, for instance to connect to a local SQLite database and print two fields for a table:

var db := DataBase.Create('SQLite', ['d:\db\base.sql3']);
var query := db.Query('select fld1, fld2 from mytable where fld3=?', ['filter']);

while query.Step do
   PrintLn(query.AsString(0)+', '+query.AsString(1));
query.Close; // optional, only required if you need it closed ASAP

and to perform several queries in a transaction

db.BeginTransaction;
db.Exec('delete from mytable');
db.Exec('insert into mytable (fld1, fld3) values (?, ?)', ['hello', 'world']);
db.Commit;

The DataSet class supports classic EOF/Next iteration as well as the simpler Step iteration as in the previous example.

There are also JSON generation helpers, you can get a whole data set or a single record as JSON. This makes building ajax requests or even database “middle-ware” services simple.

Supporting other DB connectivity layers is quite simple, as you’ll see if you look in the source. SynDB & UIB were picked initially because together they offer high coverage of the usual suspects, and bring what are among, and maybe “the”, best in class performance and stability for Delphi DB connectivity these days.

Exemple: minimal web service

Those classes will be (are) used in leveraging the new “DWScript-returns-to-its-web-roots” Web Server (based on Synopse server). For instance in the DWS WebServer demo, you can make a minimal database “middle-ware” service with Windows domain authentication with just the following code:

case WebRequest.Authentication of
   WebAuthentication.None : 
      WebResponse.RequestAuthentication(WebAuthentication.Negotiate);
   WebAuthentication.NTLM .. WebAuthentication.Kerberos : 
      Print(DataBase.Create('UIB', ['dbServer:d:\db.fdb', 'login', 'password'])
                    .Query(WebRequest.QueryString)
                    .StringifyAll);
else
   WebResponse.StatusCode := 401;
end;

The above code will expect http requests with the sql as query string (ie. after the ‘?’ in the url). If the connection isn’t authenticated, it’ll ask for authentication. Note that Windows domain Single Sign On is supported by Chrome, Internet Explorer and FireFox (if you enabled it).

The query is run against a FireBird database hosted on another server, and the result returned as JSON. If the query fails for a reason or another, the client will get automatically get a 500 error code with the exception or error message. Oh, and the reply is compressed automatically if it’s larger than a couple hundred bytes.

And if you want to only serve on a secure connection, just add a check for WebRequest.Security, and you can then safely use extra or alternative authorization tokens or credentials.

Try this:

• Create a new FireMonkey HD application, before adding a check box and an action list to the form.
• Double click the action list and add an action to it; set the action’s AutoCheck property to True.
• Assign the action just created to the check box’s Action property.
• Double click the form to create a handler for its OnCreate event. In the handler, set the action’s DisableIfNoHandler property to False:

procedure TForm1.FormCreate(Sender: TObject);
begin
  Action1.DisableIfNoHandler := False;
end;

• Run the application; once showing, click the check box. Expected: its checked state is toggled. Actual: nothing happens
• In fact, toggling the check box does work, however you need to double click the control for this to work. This is patently a bug caused by the IsChecked property setter getting called twice in the course of a single mouse click

To fix the problem, you can at a pinch create a suitable interposer class. Doing that won’t be very ‘clean’ however because the IsChecked property setter isn’t virtual, so do this instead:

• Take a copy of FMX.Controls.pas, add it to your project, and open it up.
• Find your way to the implementation of TCheckBox.MouseUp.
• Ignoring the reams of ‘Live’Bindings support code, add a check for IsCheckedStored in front of IsChecked being toggled:

if IsCheckedStored then IsChecked := not IsChecked;

Update 2 for Delphi XE3 and C++Builder XE3 is available, the majority of bugs fixed on this update are related with C++ 64-bit compiler, the Update 2 bug fix list is available here.

If you have a previous version of XE3 installed, you must uninstall it. In case you installed Platform Assistant before, you also need to uninstall it.

Update 2 is available for download on the registered user page, visit the following links:

• Delphi XE3 Update 2 download
• C++Builder XE3 Update 2 download
• RAD Studio XE3 Update 2 download

Andreano Lanusse | Technology and Software Development
Follow me on Twitter: @andreanolanusse

We proudly present the Castle Game Engine 4.0.0 release! This is the greatest release of our engine ever for ObjectPascal developers interested in making their own games:

1. We introduce a high-level game API, to construct a fully-working 3D game really easy. This includes integrated units to manage levels, creatures (with smart AI), items, player, with inventory, management of 3D resources, easy 3D sound, flexible game data layout (you can use XML files to define a lot of things without touching game code), and so on.

   Of course, we use VRML/X3D for all the 3D models, so everything can be animated and interactive, and may use features like shadows, mirrors, shaders and such. See our demo 3D models (in particular, check new water/caustics/ demo inside, by Victor Amat, movie showing it is here).

   There are a couple new examples in engine sources. First of all, examples/fps_game/ is a must-see: it shows a complete working FPS game, with a lot of comments in the source code and data files.

   The engine is very flexible, you can derive new classes and override a lot of methods to customize behavior of everything in ObjectPascal. You can define new level logic, new creatures, new items, and finally you can also use basic 3D classes to easily create any 3D entities suitable for your game. You can also easily create your own viewports, scene managers, 2D controls, use 3D sound and much more. Everything is explained in the new tutorial.

2. We have a lot of new documentation to show you how to use the engine:

   • Tutorial - introduces most concepts of the engine, with example code snippets.
   • Classes overview (cheatsheet) - a quick ride through most important engine classes and ideas.
   • Guide to creating game data - how to create your 3D models using any 3D modeling software (like open-source Blender), and how to write various configuration files like resource.xml and level.xml.
   • As always, there is also a complete API reference.

3. The full list of changes is definitely too large to fit into a normal news item. In the past I usually tried to list all the important changes in a release announcement, but there's just too many things this time :) New engine units include CastleCreatures, CastleItems, CastleLevels, CastlePlayer, CastleMaterialProperties, CastleResources. There are also countless changes in the rest of the engine to make it better and more integrated. See the news from the whole 2012 year for a complete list of details.

   For developers upgrading from engine 3 version: all of our unit names are now prefixed with CastleXxx, see doc/naming_engine_4.0.txt document. So you will almost definitely need to fix your "uses" clauses. Aside from that, the engine is quite compatible with previous version. Of course please ask of the forum if you have any questions about upgrading code from engine 3 to 4 (or about anything else, for that matter :)

We also release a new 3.12.0 version of view3dscene, our VRML/X3D browser and viewer for other 3D model formats. The most important improvements are listed below. Note that improvements 1-8 are actually in the engine, instantly available for all the games/applications using our engine. But most users will probably observe them in view3dscene for the 1st time.

1. Navigating in Walk / Fly modes by mouse dragging.
2. Using 3D mouse devices.
3. Screen-space ambient occlusion (see menu "View -> Screen Effects" menu item, developers: try the ultra-simple TCastleAbstractViewport.ScreenSpaceAmbientOcclusion boolean property).
4. All screen effects cooperate now with multi-sampling (anti-aliasing).
5. UNIT statement from X3D 3.3 is implemented.
6. VisibilitySensor node is supported.
7. Many fixes to triangulating concave polygons.
8. X3D extension to force Phong shading.
9. New "Edit -> Lights Editor" feature.

Many thanks go to Jan Adamec for implementing the 1-3 features above (and more)! Our engine is used as VRML viewer for shareware Room Arranger.

All the other programs and data on our pages were updated to use/show new engine 4.0.0 version: The Castle 1.0.0 (finally!), malfunction 1.2.8, kambi_lines 1.1.7, view3dscene 3.12.0, rayhunter 1.3.4, glViewImage 1.4.1, glplotter 1.2.5, bezier_curves 1.1.9, glinformation 1.2.2, gen_function 1.0.5, demo models 3.2.0.

Back in the days I started programming, Micro Cornucopia was a wonderful magazine, so I’m glad that BitSavers scanned a few more issues and put them online today, a week after some great PDF scans: Turbo Assembler/Debugger (1993/1994), Borland C++/Object Windows Library (1993):

• Micro_Cornucopia_#40_Mar88.pdf
• Micro_Cornucopia_#41_May88.pdf
• Micro_Cornucopia_#45_Jan89.pdf
• Micro_Cornucopia_#46_Mar89.pdf
• Micro_Cornucopia_#47_May89.pdf
• Micro_Cornucopia_#48_Jul89.pdf
• Micro_Cornucopia_#49_Sep89.pdf
• Micro_Cornucopia_#50_Nov89.pd
• Micro_Cornucopia_#51_Jan90.pdf
• Micro_Cornucopia_#52_Mar90.pdf
• Micro_Cornucopia_#53_May90.pdf (final issue)

They covered a lot of languages (x86 and 68k assembly, C, C++, Turbo Pascal and many more), and very interesting hardware designs.

–jeroen

via: Index of /pdf/microCornucopia.

In the VCL, toolbar icons (glyphs) are set up using the TImageList component. In FireMonkey however, TImageList does not exist, and even TToolBar itself is half the component it is in the VCL – rather than manage its own buttons, it’s just a simple container control like TPanel. To add buttons to a FMX TToolBar, you therefore drop TSpeedButtons onto it; and to add glyphs to the buttons, you add a TImage control to each one. On the face of it this leads to a simpler situation that had with the VCL; on the other though, it causes maintenance hassles in non-trivial applications if the same glyph is supposed to be used by different buttons, or if you come to want to change the icon set to a different one, given each image must be changed separately.

Being bothered about this issue, I’ve found relief is at hand from the FireMonkey styling system though. Let’s see it in action:

• Create a new FireMonkey HD application.
• Drop a TSpeedButton onto the form, and clear its Text property. Next, add a TPanel (sic.) to the button. Since TSpeedButton won’t let you do this directly, reparent the panel by dragging its node onto the button’s node in the Structure pane (top left).
• Set the panel’s HitTest property to False, and its Align property to alClient. If you want to be able to drag the button around at designtime, set either the panel’s Padding property to (2, 2, 2, 2) or the button’s Margins property to (2, 2, 2, 2). Note the meaning of Padding and Margins is (weirdly) flipped round compared to the VCL – this is something I still haven’t got used to myself!
• Add a TLayout to the form, and set its Visible property to False.
• Add a TImage to the layout, load a suitable ‘Open File’ glyph into its Bitmap property, and set its StyleName to ‘FileOpenGlyph’. For ease of identification in the designer, set its Name property to ‘FileOpenGlyph’ too.
• Set the panel’s StyleLookup property to ‘FileNewGlyph’. Note you’ll have to type it, as the name won’t be in the drop-down list.

At the end of all that, you should have something like this:

How this works is that TPanel, as a styled control (TStyledControl descendant), gets its visual appearance from another control, or more exactly, a copy of another control – the ‘style’. This other control can be anything – all that is crucial is that its StyleName property is set to a value matched by the value of the StyleLookup property of the intended style subject(s).

Normally, custom styles are set up via a TStyleBook component. Using a style book means using the IDE’s FireMonkey style designer though, which is something only a programming masochist can enjoy. What isn’t so obvious is that you don’t actually need to use TStyleBook in the first place however – any control that has its StyleName property assigned will be available as a custom style. So, doing just that is what we did in the demo.

Now, we placed the source TImage on a hidden TLayout given we didn’t want it to be shown at runtime – setting its own Visible property to False wasn’t an alternative, since that would have caused the control it styled to be invisible at runtime too! However, it may be the case that you would prefer not to clutter a form with the source glyphs at all. In a VCL scenario, this would mean putting the application’s image lists onto a data module, but given TImage instances are controls, we can’t do that here. Instead, we need to put the glyph images onto a dummy form, auto-created but not ever visible. In my own case I had a further requirement: the ability to switch at runtime to a different glyph set. This was necessary because I’m looking to support both dark and light UI styles, and currently working with monochrome icons. While that may change later, there was no harm in ensuring everything would work if it didn’t.

So, continuing with the demo, add another form to the project, name it ‘StdGlyphsForm’, and save its unit as App.Glyphs.Std.pas. Then, go back to the first form, cut the TImage to the clipboard, then paste it onto StdGlyphsForm. Because we do not want the new form to become the application’s ‘main’ form in the VCL/FMX sense, do not have it auto-created in the normal fashion (Project|Options, Forms). Instead, it needs to be created explicitly when the application starts up, and directly (i.e., using TGlyphsForm.Create not Application.CreateForm).

Before we get to that though, let’s set up an alternative icon set to test with. To do that, save everything, then duplicate App.Glyphs.Std.pas via File|Save As…; save it as App.Glyphs.Alt.pas, then rename the form to AltGlyphsForm. After that, change the contents of the image, then add the original version of the unit (App.Glyphs.Std.pas) back to the project as well. In principle, we can now choose which icon set to use at runtime by instantiating the appropriate form class (StdGlyphsForm or AltGlyphsForm); if we wanted to then switch sets at runtime, we can just free the first glyphs form, instantiate the second, and ask all ‘normal’ forms to update their styling.

When targting OS X pursuing such a plan works fine, but when targeting Windows there’s a problem: specifically, at one point in FMX.Platform.Win.pas, Screen.Forms[0] is used in lieu of Application.MainForm when the latter cannot be guaranteed to be initialised yet. Because of this, the first form that gets created – regardless of how – becomes the ‘owner window’ for subsequent forms at the Windows API level. If the first form created were to be one of our glyph container forms, bad things will then result.

One way to get around this is to ensure the real ‘main form’ creates the glyph container. However, this assumes you have a ‘main’ form in the first place, which when targeting OS X especially isn’t necessarily the case. After fiddling about the problem, my preferred solution at present is to create the glyph container, move its contents to something else that isn’t a form too (just a bare TComponent instance will do), then immediately free it. So, let’s do that with the demo, wrapping the necessary code in a simple singleton type.

For this, add a new unit to the project, and call it App.Glyphs.pas. Then, copy the following code into its interface section:

uses
  System.Classes;

type
  TGlyphsStyle = (gsStandard, gsAlternative);

  GlyphsManager = record
  strict private class var
    FGlyphsOwner: TComponent;
    FGlyphsStyle: TGlyphsStyle;
    class constructor Initialize;
    class destructor Finalize;
    class procedure SetGlyphsStyle(Value: TGlyphsStyle); static;
  public
    class property GlyphsStyle: TGlyphsStyle read FGlyphsStyle write SetGlyphsStyle;
  end;

Next, make its implementation section look like this:

uses
  FMX.Types, FMX.Forms, FMX.Styles, App.Glyphs.Std, App.Glyphs.Alt;

class constructor GlyphsManager.Initialize;
begin
  FGlyphsOwner := TComponent.Create(nil);
  FGlyphsStyle := gsAlternative;
  SetGlyphsStyle(gsStandard);
end;

class destructor GlyphsManager.Finalize;
begin
  FGlyphsOwner.Free;
end;

class procedure GlyphsManager.SetGlyphsStyle(Value: TGlyphsStyle);
var
  Comp: TComponent;
  I: Integer;
  SourceClass: TComponentClass;
  Source: TComponent;
begin
  if Value = FGlyphsStyle then Exit;
  case Value of
    gsStandard: SourceClass := TStdGlyphsForm;
    gsAlternative: SourceClass := TAltGlyphsForm;
  else
    Assert(False);
    SourceClass := nil; //avoid compiler warning
  end;
  FGlyphsOwner.DestroyComponents;
  Source := SourceClass.Create(nil);
  try
    for I := Source.ComponentCount - 1 downto 0 do
    begin
      Comp := Source.Components[I];
      FGlyphsOwner.InsertComponent(Comp);
      if Comp is TFmxObject then
      begin
        TFmxObject(Comp).Parent := nil;
        if Comp is TControl then
          TControl(Comp).SetNewScene(nil); //see below
      end;
    end;
  finally
    Source.Free;
  end;
  FGlyphsStyle := Value;
  { next lines only necessary because we aren't updating
    the style as such as well }
  for I := Screen.FormCount - 1 downto 0 do
    Screen.Forms[I].UpdateStyle;
end;

The code here should be pretty straightforward – when the glyph set is to be changed, the old glyphs are first destroyed, the new ones loaded, and the application’s forms asked to refresh their and their controls’ styling. The only slightly tricky thing is how we change an existing component’s owner – since the Owner property is read-only, we need to call InsertComponent on the new owner instead, the implementation of which first deassigns any existing owner. Further, since a FireMonkey control, like a VCL one, has both a parent and an owner, and both will destroy the control when the parent or owner is itself destroyed, we need to clear the parent too. Lastly, due to an oversight in the FireMonkey source, a further reference – to the ‘scene’ – needs to be manually cleared as well. If you check out FMX.Forms.pas, you’ll find TCustomForm calls SetNewScene(Self) in DoAddObject, but not SetNewScene(nil) in DoRemoveObject. The resulting dangling reference then causes access violations if not cleared.

To put the new unit in action, head back to the main form of the demo (i.e., the one with the button on it), remove the now empty TLayout, and add a couple of radio boxes called rdoStandard and rdoAlternative. Set the first’s IsChecked property to True in the Object Inspector, then handle its OnChange event as thus:

procedure TForm1.rdoStandardChange(Sender: TObject);
begin
  if rdoStandard.IsChecked then
    GlyphsManager.GlyphsStyle := gsStandard;
end;

Similarly, handle rdoAlternative’s OnChange event like this:

procedure TForm1.rdoStandardChange(Sender: TObject);
begin
  if rdoAlternative.IsChecked then
    GlyphsManager.GlyphsStyle := gsAlternative;
end;

Finally, add App.Glyphs to the form’s implementation section uses clause (Alt+F11) and run the application. If all goes well, clicking on the radio boxes should toggle the button glyph:

One thing to watch out for is that if you save everything, close and then reopen the project and have the form open in the IDE without either StdGlyphsForm or AltGlyphsForm too, the button’s styling will revert to a normal TPanel. This is nothing to worry about – close the form, open one of the glyph forms, then reopen the form, and the image will be back.

At the end of the day, I’m pretty happy with all this. While there was the odd irritating oversight in the FireMonkey source to work around, overall I find the style system here producing a more convenient approach that the VCL – in particular, it’s much nicer to be able to refer to a glyph by name rather than a meaningless numerical index. Moreover, the cosmetic issue of the custom style apparently being ‘lost’ when the main form is open without one of the glyph forms alongside is just that – cosmetic. In contrast, if the form were a VCL one with a TToolBar referencing a TImageList on a data module, the IDE would silently clear the actual reference!

Postscript – using TSubImage

As a final note, there is one variant of my approach that you might wish to consider. This is to replace the individual TImage instances with individual TSubImage ones, which then reference a single big TImage (TSubImage isn’t automatically registered, annoyingly enough, so you’ll need to do what Jeremy North did for TStyleTag here first). The reason is that when a control is used as a style, a copy of it is taken – and one aspect of the copy in a TImage case will be the contents of its Bitmap property.

If this were the VCL that wouldn’t be an issue due to the fact TBitmap there implements a reference counting system internally. In other words, when you do DestBitmap.Assign(SourceBitmap) in a VCL application, no ‘deep copy’ of the source bitmap is made, similar to how DelphiString2 := DelphiString1 doesn’t cause character data to be duplicated ‘there and then’ – rather, copying only happens when one of the two bitmaps or strings is modified later (the jargon for this is ‘copy on write semantics’). Unfortunately, the FMX TBitmap does not implement this behaviour though, and because of that, doing DestBitmap.Assign(SourceBitmap) causes an immediate ‘deep copy’ of the source, duplicating the bitmap bits in memory. For a small application with a small number of glyphs that won’t matter, and perhaps it won’t matter much either in a bigger program. As an application grows you might want to at least consider swapping out the individual TImage controls for TSubImage ones though. Thanks to the flexibility of the styling system, the task shouldn’t be too hard – all existing style associations can be kept intact.

These are many new improvements of Object Pascal programming language in Free Pascal compiler. I don’t know how much new are they, but at least they are new since Delphi 7 language. I haven’t used any of these features before (until now) because I wasn’t know about them.

1. For .. in loop:

This can be used to loop in string characters:

procedure ForInLoop(aStr: string);
var
  ch: Char;
begin
  for ch in aStr do
    WriteLn(ch);
end;

or through set items:

procedure ForInSetLoop;
var
  s: set of 1 .. 100;
  i: Integer;
begin
  s:= [1, 3, 7];
  for i in s do
    Writeln(i);
end;

2. += operator

This new operator can be used to concatenate strings and add values to numbers:

var
  aName: string;
begin
  aName:= 'Free';
  aName += ' Pascal';
  Writeln(aName); // Free Pascal
end;

For numbers:

x:= 10;
x+= 15;
Writeln(x); // 25

3. Properties without OOP

Now you can define a property in a structured code:

var
  x: Integer;

procedure SetX(aX: Integer);
begin
  x:= ax;
end;

function GetX: Integer;
begin
  Result:= x;
end;

property MyX: Integer read GetX write SetX;

// Main program
begin
  MyX:= 170;
  Writeln(MyX);

end.

4. Bit packed record

You can define a record of bits, and display it as byte:

type
  tbit = 0..1;

  tBitsByte = bitpacked record
    bit0   : tbit;
    bit1   : tbit;
    bit2   : tbit;
    bit3   : tbit;
    bit4   : tbit;
    bit5   : tbit;
    bit6   : tbit;
    bit7   : tbit;
  end;

var
  aByte: tBitsByte;
begin
  aByte.bit0:= 1;
  aByte.bit1:= 0;
  aByte.bit2:= 1;
  Writeln(Byte(aByte)); // 5

5. Sealed class

You can prevent inheriting from a class by adding the keyword sealed:

TMyClass = class sealed
  private
    fValue: Integer;
  public
    constructor Create(aValue: Integer);
    destructor destroy; override;
    function GetValue: Integer;
end;

I couldn’t find a good example right now to explain why we need to do this, but in the future I may get one.

6. Class methods and variables

You can declare methods and variables that can be used by class name before object instantiation the same like Java static methods as in this example:

TMyClass = class sealed
  private
    class var fValue: Integer;
  public
    constructor Create(aValue: Integer);
    class function GetValue: Integer;
    class procedure SetValue(aValue: Integer);
end;

constructor TMyClass.Create(aValue: Integer);
begin
  inherited Create;
  fValue:= aValue;
end;

class function TMyClass.GetValue: Integer;
begin
  Result:= fValue;
end;

class procedure TMyClass.SetValue(aValue: Integer);
begin
  fValue:= aValue;
end;

// Main code

begin
  TMyClass.SetValue(900);
  Writeln(TMyClass.GetValue);
end.

7. case of String

case aName of
'Free Pascal': Writeln('Lazarus IDE');
'C++': Writeln('CodeBlocks IDE');
end;

If you know any new useful additions please let me now to write it here.

References:

http://lazarus.freepascal.org/index.php/topic,19107.0.html

http://www.freepascal.org/docs-html/ref/refse24.html#x56-630004.6

http://edn.embarcadero.com/article/34324

Just in case you wonder about Property using Generics in Delphi, they are not possible.

Thanks David for mentioning it, Hallvard for mentioning it even earlier and Rudy for confirming it.

These are supported with Generics in Delphi:

• Generic interfaces
• Generic classes
• Generic methods
• Generic fields
• Generic type inferencing
• Generic constraints (a bit buggy in Delphi 2009)

All of the supported aspects are linked to articles from excellent authors. There is far more on the internet about Delphi and Generics, but those are a good start.

Thanks Malcolm, Phil, Barry, Hallvard, Jolyon and many others for posting all those articles!

Note that this is not possible in C# either, Julian Bucknall organized a chat and explains why, but there is a workaround which I might try to port to Delphi in the future.

–jeroen

via: Property using Generics in Delphi – Stack Overflow.

Thanks Warren Postma for this Google Plus mention: both the question and answer are incredibly insightful.

And indeed: the code from the answer is not possible in with Generics Delphi (:

–jeroen

via: syntax – Is C++ context-free or context-sensitive? – Stack Overflow.

It’s been several years since I used datasets for anything other than quickly displaying the results of a SQL Query or Proc.  Recently I have been reminded why I dislike the TDataSet based RAD development approach so much.

If you’ve ever done a DBX conversion you would know that DBX maps datetime database columns to TSQLTimeStampFields instead of TDateTimeFields.  If your datasets use persistent TFields, which is typically the case so developers can make use of TField events to provide formatting, and validation, then you’re in for a treat!  All the persistent TFields have to be removed so new ones can be generated at design-time using DBX to ensure the right field types are used.  Of course you don’t want to remove any additional TField descendants created at design-time that are not in the dataset, so it might be necessary to go through each one to determine if the TField originates from the underlying dataset (using FieldKind may not be enough).

Once you’ve finished re-mapping all the TFields, you have to re-connect all the event handlers.  Hopefully, the original developers actually centralized all the database related code into datamodules, or you will be going through every form in the entire project.  Even re-connecting all the dataset TField handlers in the datamodules may be a treat if handlers were not shared across TFields of the same type.  For instance, if you use the OnSetText, OnGetText events to provide standard date formatting for TDateTimeFields using edit masks for input with a different format for displaying the date, you have to reconnect numerous handlers to each persistent TField event and the only way to tell if you have it right is GUI testing.  If you don’t get it right you will see errors from TField.SetAsString() with no idea what field is causing the exception.  The easiest way to actually find out is to put a breakpoint on the method, enable Debug DCUs, and generate the error through the UI.

In an application using domain objects with the MGM pattern for presentation, all the TField handlers would be replaced with mediators that perform the translation between the UI presentation layer and the database layer.  If you need to enhance the application to work with a variety of date formats, for instance, instead of locking it down to the corporate standard format which I see most often when using TField events, the enhancement would only involve a change in one place (the mediator).  It’s a much DRYer approach.  While using TField events doesn’t necessitate multiple handlers for the same purpose (one per TField type instance), not many developers think about consolidating such code across the application, and the result is a maintenance nightmare, especially if you ever think about changing the database layer.

Avoid vendor lock-in, even if you’re not thinking about changing your database, consider using an ORM, or even database application layer interfaces such as hcOPF’s IhcQuery and IhcStoredProc so changing your database layer doesn’t result in sleepless nights.  One “proposed” EULA change could have you swapping a database layer in a hurry

I delayed publishing this post as I contemplated the wisdom of doing so, but 2012 has been a big year for Delphi, so I thought I would review the events of the year and make my predictions for 2013 even if it’s the last day of January rather than the first.

Corporate

One of the biggest news items was of course Marco Cantu joining EMBT as a Delphi Product Manager. Sadly, this was not the only staff change at EMBT. Barry Kelly among others, decided to leave EMBT, and there were anonymous reports of lay-offs, and a large degree of employee dissatisfaction including no raises for employees since EMBT acquired CodeGear, as well as hiring of junior engineers in economically advantageous areas of the globe.

The new EULA agreement for XE2 included changes prohibiting the use of DBX drivers (EMBT’s and third party) for accessing remote databases in the Pro version of Delphi. These “proposed” changes were leaked to the community, and the agreement was subsequently changed to exclude the new restrictions.

With the release of FireMonkey (FMX) on Sept. 1, 2011 it’s been over a year that FireMonkey has been out in the wild. The introduction of FireMonkey heralded the deprecation of the VCL despite numerous enhancements, it’s clear that EMBT is betting the future expansion of the Delphi/BCB market on FMX.

Desktop

Since FMX was released, there have been two major component vendors providing support for FMX; TMS and FastReports. Delphi XE3 has also been released with an updated version of FireMonkey (FM^2). With third party advanced grid and reporting capabilities, FMX now has a sufficient tool set to author cross platform desktop applications for LOB (Line Of Business) applications.

Many of the technical blog articles on FMX have been quite critical of its implementation and lack of completeness in the version 1.0 release even in the desktop space.  Some of these deficiencies have been addressed in version 2, but the framework is still maturing, and the latest feedback on FM^2 by those deep diving the technology is not extremely positive.

Mobile

In the mobile space, several applications were authored and accepted into the Apple App Store using XE2 with FMX before FMX support for iOS was removed in the subsequent release (XE3). Users who bought XE2 for iOS were left with a discontinued version of the framework and development tool, with no clear indication what the future held for them. These early adopters were then required to pay to upgrade to XE3 for the privilege of beta testing the up-coming Mobile Studio, in order to ascertain what their migration path would look like, and whether they should continue to support EMBT’s efforts in the mobile space.

The Future?

With the layoffs/departures from EMBT, as well as delayed compiler releases it appears the decision to bet the farm on FireMonkey is not paying off yet, and even EMBT employees may no longer believe in the strategy. This is further validated by the attempted EULA change which would have required Pro users to buy a higher priced SKU, and the 10% price hike in the new year.

I think EMBT has bitten off more than they can chew. Trying to implement a cross platform UI framework is a major endeavor with minimal payback (development tool licenses only), and lots of competition. There are free frameworks out there, and ones that have been around for a long time. Creating a framework specific to the Delphi/BCB tool set immediately limits its market, and dramatically increases the code base that EMBT has to maintain. From what I can see, they are already challenged in that respect (just look at the number and age of QC reports). It’s been over a year since FireMonkey was released, and the adoption rate appears to be minimal if you look at the available components and applications based on FMX.

IMHO, the writing is on the wall.  Expect to pay more for Delphi/BCB licenses while EMBT pours their revenue into FMX to develop the market.   Expect to wait longer for bug fixes and suffer from longer startup times due to increased anti-piracy efforts. I would also expect that the Android and Linux support will be even later than indicated as EMBT focuses on the Mac/iOS platforms trying to get traction in one of the most appealing market segments for Delphi developers.

As unfortunate as it may be, I believe that FMX will continue to flounder and that’s why you don’t see vendors like Developer Express, or Raize porting their VCL products, and even after over a year the monkey is hardly on fire.  FMX will likely become a niche framework, used by some developers for XPlatform support and 3D development, while the number of developers moving to different languages and tools for new development continues to escalate.  Certainly the release of mobile studio will be a pivotal event for the future of FMX, and therefore Delphi.

לפני חודש בערך, הזכרתיכי אני כותב תוסף ללזרוס.

התוסף מאפשר לעשות split view עבור העורך של לזרוס, ובכך לאפשר לבצע עריכה ו/או צפיה בקוד תחת 2 view ports על אותו טאב בעצם.

להגיע לנקודה הזו היה מאוד לא פשוט בגלל מספר סיבות:

• פעם ראשונה שאני עושה דבר כזה
• לדבג קוד למערכת הזו אינו פשוט – צריך לדבג את ה IDE בעצם מתוך ה IDE‏
• מצאתי באגבספריות של FPC אשר דורש התייחסות
• יש המון דברים שחשבתי עליהם בגישה איקס ומסתבר שהם ממומשים אחרת בפועל
• מה שאומר ששכתבתי קוד יותר מפעם או פעמים להגיע לגישה הנכונה

הגרסה הנוכחיתיודעת רק להעתיק את צביעת הטקסט, תכונות הגופן ולהציג עצמה כמובן על המסך.
היא לא אמורה לעשות שום דבר מעבר לכך, ואם היא עושה, אז לא במכוון
התוסף מתקין עצמו בתפריט הימני של הלשוניות אשר מחזיקות בעורכי הטקסט, וגם מאפשרת לרשום עבור הפעולות קיצורי מקשים, אך בברירת המחדל, אינה מקצה כאלו.

גרסה זו נועדה יותר לבדיקות וחוו"ד מאשר שימוש אמיתי בה, ואשמח לשמוע ממכם בנושא

הוראות התקנה

פתחו בלזרוס את התפריט package ושם בחרו באפשרות open package file (.lpk)‎.
בספריית התוסף, בחרו את תת הספרייה בשם package ושם את הקובץ lazsplitview.lpk .
לאחר שנפתח לכם חלון של החבילה, לחצו קודם על כפתור compile לבדוק כי אין בעיות בבניית התוסף, וכשזה מסתיים, בחרו ב install.
לאחר אתחול מחדש של לזרוס, התוסף כבר מותקן אצלכם.

• First time of writing such thing
• For debugging my own code, I need to debug the IDE, because I'm executed from within
• Found a bug with FPC class
• There are things that I thought that works in one way, but actually in much different way
• So I needed to rewrite code in that level as well …

The following release contains only few features, such as syntax color, and fonts that are copied from the original editor.
It also provide a splitter between the original editor and the new one, and should not support anything else. So if you find that it does something else, it was by mistake

The plugins install itself into the Editor tab menu, and also allow you to register a shortcut for it's actions that by default are empty.