On the road with Lazarus/Freepascal

Generic cross data report with lazreport

2011-07-10T14:16:00.000-07:00

In the lazreport repository there's a demo app showing how to create a cross data report. It uses two instances of TfrUserDataset: one for the master (row) data and one for the cross (column) data. At first glance the component does not provide another way to build such reports. A deeper look shows the contrary. Here are the steps to build a cross data report with arbitrary number of rows and columns.

WARNING: to follow this guide is necessary basic lazreport knowledge.

Prepare the report

Nothing special here

Create an empty report

Add a Master Data band

Add a Cross Data band

Add a Text Object inside the Cross Data

In the Text Object put a variable named value: [value]

Add handler to retrieve the value

Those familiar with lazreport will have no problems:


procedure TForm1.frReport1GetValue(const ParName: String; var ParValue: Variant);
begin
  if ParName = 'value' then
    ParValue := IntToStr(FRow) + ' - ' + IntToStr(FCol);
end;

Just the column and row indexes for demonstration purpose. Using together with matrix like data structures the retrieve of actual data is straightforward.

Set the number of rows and columns

The most attentive developers will notice that no dataset (even the virtual dataset) was linked to each band. In fact running the report at this stage will lead to a blank page.
If the number of columns and rows are previously know just set the Virtual Dataset option for each band. This is not an optimum solution since not always we have that info. Here's how to set the Virtual Dataset record count at runtime:


procedure TForm1.frReport1BeginDoc;
var
  BandView: TfrBandView;
begin
  BandView := frReport1.FindObject('MasterData1') as TfrBandView;
  BandView.DataSet := '9';
  BandView := frReport1.FindObject('CrossData1') as TfrBandView;
  BandView.DataSet := '2';
end;

This will create a report with nine rows and two columns. Yep, you read right: lazreport store the number of the records of band's Virtual Dataset in an string field, the same field that store the name of an associated TfrDataset.
WARNING: don't look at lazreport source. It may scare the faint hearted ;-)

Track the row and column positions

The tricky part. The first thing to do is add two integer fields (FRow and FCol) to the Form/Data Module containing the TfrReport instance.

To get the column add an event to OnPrintColumn, and store the ColNo parameter:


procedure TForm1.frReport1PrintColumn(ColNo: Integer; var ColWidth: Integer);
begin
  FCol := ColNo;
end;

Notice that the Lazarus IDE will create an event declaration with the second parameter named Width. This will not compile with {$mode ObjFpc}. Renaming it to ColWidth will make the compiler happy.

There's not an event that pass the current row position. The first try is to hook into the OnBeginBand


procedure TForm1.frReport1BeginBand(Band: TfrBand);
begin
  Inc(FRow);
end;

Running the report with this will show wrong row indexes because it will increment in all bands not only the Master/Row band. The fix is easy:


procedure TForm1.frReport1BeginBand(Band: TfrBand);
begin
  if Band.Typ = btMasterData then
    Inc(FRow);
end;

It's done, add Data Header and Cross Header bands, glue with actual data and the generic cross data report is done. The sample project.

Make a generic control behaves like a "DropDown window"

2011-07-01T16:04:00.000-07:00

Some controls, like the dropdown list of a combo box, disappears as soon as focus is lost. In web applications / pages this concept is expanded further by allowing form controls inside the drop down window.

To make a generic LCL control works like those web widgets, basically is necessary to hide it when the focus is lost. If the drop down control is a form this can be accomplished as simple as setting the BorderStyle to bsNone and using the Deactivate handler to hide itself:

procedure TMyForm.FormDeactivate(Sender: TObject);
begin
 Hide;
end;

For TFrame is possible to put an instance of it in an temp TForm configured as above. For other control classes, created at design time and with a parent already assigned, this may work but is not desired.

The alternative is to detect when the focus has changed and then check if the focused control is outside the "drop down" control. ~~Unfortunately, AFAIK, there's no way in VCL/LCL to detect globally when the focus changed.~~ Well, in fact there's an event that just do that: Screen.OnActiveControlChange. The drawback of using this event each time a "drop down" control is used is that will override a previously set event handler. Fortunately, LCL provides an alternative to set multiple handlers through Screen.AddHandlerActiveControlChanged.

So, for a TPanel descendant we would use something like to add remove the handler when the visible state is changed:


procedure TMyPanel.VisibleChanged;
begin
 if Visible then
   Screen.AddHandlerActiveControlChanged(@FocusChangeHandler)
 else
   Screen.RemoveHandlerActiveControlChanged(@FocusChangeHandler);
end;

In the handler code check if the focused control is itself or a child. If not hide:


procedure TMyPanel.FocusChangeHandler(Sender: TObject; LastControl: TControl);
var
 AControl: TControl;
begin
 AControl := Screen.ActiveControl;
 if (AControl <> Self) and not IsParentOf(AControl) then
   Visible := False;
end;

Yep! When the focus goes to outside of the "drop down" control it will automatically hide itself.

But...

Sometimes clicking outside of the control will not change the focus so it will not hide like desired. The solution is to detect user inputs (mouse click) globally. Setting OnMouse* events for all form controls is a no-no for obvious reasons. Using Application.OnUserInput event is an idea but has the same drawback of Screen.OnActiveControlChange. Similar problem, similar solution: is possible to set multiple handlers through Application.AddOnUserInputHandler.

The updated VisibleChanged code:


procedure TMyPanel.VisibleChanged;
begin
 if Visible then
 begin
   Screen.AddHandlerActiveControlChanged(@FocusChangeHandler);
   Application.AddOnUserInputHandler(@UserInputHandler);
 end
 else
 begin
   Screen.RemoveHandlerActiveControlChanged(@FocusChangeHandler);
   Application.RemoveOnUserInputHandler(@UserInputHandler);
 end;
end;

And the input handler that checks if the control where mouse is over is outside or not:


procedure TMyPanel.UserInputHandler(Sender: TObject; Msg: Cardinal);
var
 AControl: TControl;
begin
 case Msg of
   LM_LBUTTONDOWN, LM_LBUTTONDBLCLK, LM_RBUTTONDOWN, LM_RBUTTONDBLCLK,
   LM_MBUTTONDOWN, LM_MBUTTONDBLCLK, LM_XBUTTONDOWN, LM_XBUTTONDBLCLK:
   begin
     AControl := Application.MouseControl;
     if (AControl <> Self) and not IsParentOf(AControl) then
       Visible := False;
   end;
 end;
end;

Relatively simple but doing that for each control would be annoying so i wrote a component that takes care of it (among other few details). Enjoy.

JSON to the rescue

2010-08-05T11:16:00.000-07:00

Tired of creating boilerplate dialogs for every TDataSet i needed to edit, i developed a generic dialog with a data grid plus the basic edit buttons (add, delete). To edit a TDataset i just call a wrapper function that setup the grid with some configuration.

While most of the time i just needed to edit a single field, it was desirable to keep the ability to edit more than one field. Also it would be necessary also to set the column width for each field. So i was passing a record with the following structure to configure the dialog:


  TDataDialogInfo = record
    FieldNames: String;
    FieldWidths: array of Integer;
    Title: String;
  end;

Title stores the dialog title, FieldNames store the Field names in semicolon separated string and FieldWidths the width of corresponding field. Here is the first problem: without adding another record type with the field name and width there is noway to guarantee the correspondence between the values leading to error easily.

Another problem is that there's no way in fpc to create the record on the fly so i need to declare a constant somewhere. To use a dialog with Title "Edit Test Dataset" and editing field "Name" i need to do:


const
  Info: TDataDialogInfo = (
    FieldNames: 'Name';
    FieldWidths: nil;
    Title: 'Edit Test Dataset'
    );

Notice that even if i don't need/want to set the width i have to declare the record field Widths.

I used this way for some time, and is really a lot less work than creating a TForm and setting the components for each TDataset, until i needed to add an option to show more rows than the usual in the grid. How to add such option? Adding a field to the TDataDialogInfo record would make all previous defined constants unusable and i would need to fix than all. What if later i needed to add another option?

It was at this moment that i think: "How it would be good if pascal had the ability to define objects with arbitrary fields on the fly, like in JavaScript!". Well, in fact, although indirectly, is possible to do it in pascal thanks to the native fpc implementation of JSON.

So instead of using a record to pass the configuration now i use a string with a (valid) JSON definition. In the previous example (Title "Edit Test Dataset" and editing field "Name") now i do:


Info = '{"title": "Edit Test Dataset", "fields": {"name": "Name", "title": "Person"}}';

If i just need to define the field name:


Info = '"Name"';

If i want to edit two fields:


Info = '["Id", "Name"]';

And i can set different properties for each field


Info = '{"title": "Edit Test Dataset",'+
    '"fields": ["Id", {"name": "Name", "title": "Person"},' +
    ' { "name": "Phone", "width": 100}]}';

Notice that the format of the property (in this case "fields") vary from a single string to a JSON array or object. Better: you can mix in the same property different formats! Flexibility it's your name. All of this backward compatible: i can add another property and previous definitions will still work!

The cost of accessing object fields (part 2)

2010-08-01T14:05:00.000-07:00

In the last post, we could see the benefits of using a temporary variable to access frequently used object fields. What if the object field is accessed only two times. The benefit would be maintained?
Let's see this example:
Before:


begin
  if FDataLink.Field <> nil then
    Caption := FDataLink.Field.DisplayText
  else
    Caption := '';
end;

After:


var
  DataLinkField: TField;
begin
  DataLinkField := FDataLink.Field;
  if DataLinkField <> nil then
    Caption := DataLinkField.DisplayText
  else
    Caption := '';
end;

It seems that yes, although very little (saves only two instructions). This is the kind of optimization to be done on only very sensitive areas.

Since the benefit was mainly due to the compiler saving the local variable in a register, a doubt that i had in mind was what would happen in a method with many parameters? The addition of the variable would still be beneficial?

So i tested the addition of a variable in a method with the following header


procedure DoIt(Sender, Sender2, Sender3: TObject);

As we can see, the version with the local variable is still smaller.

All in all, some like to say that less is more, but sometimes, as in this case, more is less!

The cost of accessing object fields (part 1)

2010-07-25T07:20:00.000-07:00

The common sense make us believe that adding more code and/or more variables leads to bigger programs. Looking at the generated code of one example in the previous post, the addition of one variable made the executable smaller. This occurs because fpc is smart enough to reuse registers (in this case eax).

This week, while fixing one Lazarus bug i noticed the following pattern in the generated code of method TDBEdit.DataChange:


 movl 12(%ebx),%eax
 movl 24(%eax),%eax

Basically this is the code to access FDataLink.Field property (the first instruction get the FDataLink address and the second get the Field address). So what would happen if this field was "buffered" in a TField local variable?

Before:


procedure TDBEdit.DataChange(Sender: TObject);
begin
  if FDataLink.Field <> nil then begin
    Alignment := FDataLink.Field.Alignment; 
  [..]

After:


procedure TDBEdit.DataChange(Sender: TObject);
var
  DataLinkField: TField;
begin
  DataLinkField := FDataLink.Field;
  if DataLinkField <> nil then begin
    Alignment := DataLinkField.Alignment; 
  [..]

This simple change lead to these differences.

As expected the code became smaller but two things surprised me:

There's no increase in the temporary memory allocated

The variable assignment did cost nothing (not even one instruction)

The above test was done with a "clone" of TDBEdit.DataChange in a test project. To make sure there are no confounding factors i also tested with the original code to confirm the differences. Notice that in this case, although the code is also smaller, the addition of the variable increase the temporary memory allocated as well the variable assignment requires one extra instruction. Bad.

But there was one last hope: compile LCL with -O2 option (i assumed that LCL was already compiled with that optimization turned on). Seems that my assumption was wrong. The -O2 option did the trick: the same result as before.

In the next post i will play with a few more scenarios.

And remember: don't forget to put -O2 in LCL build options when doing a release, it makes difference.

Condition check versus a type map

2010-07-21T16:28:00.000-07:00

Often, the programmer is faced with the need to translate from one type to another, e.g., given a boolean variable return a corresponding integer value. As a real world example see a piece of Lazarus code:


  if NewWordWrap then
    gtk_text_view_set_wrap_mode(AGtkTextView, GTK_WRAP_WORD)
  else
    gtk_text_view_set_wrap_mode(AGtkTextView, GTK_WRAP_NONE);

NewWordWrap is a boolean variable, but the gtk function expects an integer. To translate from type to another a condition check is done.

Another way to handle this would be creating a map array with the type to be translated. Lazarus also has an example of this technique:


const
  WidgetDirection : array[boolean] of longint = (GTK_TEXT_DIR_LTR, GTK_TEXT_DIR_RTL);
[..]
  gtk_widget_set_direction(AGtkWidget, WidgetDirection[UseRightToLeftAlign]);

Here is the same pattern: UseRightToLeftAlign is a boolean variable and the gtk function expects a integer, but instead of checking for the variable value a boolean to integer map (WidgetDirection) is used.

While the map approach seems faster because avoids a check, it adds an additional constant. I decided to look at the generated code to see the actual benefits.

Check the condition code:


  if B then
    DoIt(CONST_1)
  else
    DoIt(CONST_2);

Map code:


const
  BoolMap: array[Boolean] of Integer = (CONST_2, CONST_1);

  DoIt(BoolMap[B])

Here is the generated code. This shows a clear advantage to the map approach. Notice that in this small example the size of executables were the same.

I also tested a more complex type than boolean: an enumerated.

Check the condition code:


  case E of
    EnumA: DoIt(CONST_1);
    EnumB: DoIt(CONST_2);
    EnumC: DoIt(CONST_3);
  end;

Map code:


const
  EnumMap: array[TMyEnum] of Integer = (CONST_1, CONST_2, CONST_3);

  DoIt(EnumMap[E])

The result.

Now with a slight optimized code for the condition check...


var
  I: Integer;

  case E of
    EnumA: I := CONST_1;
    EnumB: I := CONST_2;
    EnumC: I := CONST_3;
  end;
  DoIt(I);

... i got this.

The discover of RTTI

2010-05-21T11:58:00.000-07:00

I never got much interest, or knowledge, by Delphi/fpc RTTI. But the recent fuzz about the new RTTI features introduced in Delphi 2010 raised my curiosity even if the fpc provides only the old style RTTI.

The opportunity to learn, and use, RTTI came when i figured the possibility to enhance/clear some of my code.

To show a generic TForm i created a ~~very imaginative~~ simple function:


function ShowForm(FormClass: TFormClass; Owner: TWinControl): TModalResult;
var
  Form: TForm;
begin
  Form := FormClass.Create(Owner);
  try
    Result := Form.ShowModal;
  finally
    Form.Destroy;
  end;
end;

This little function works nice and save some boilerplate code but it's limited to forms that don't need to initialize a property before is called since i don't know class type before hand.

As stated before, messages can be used to notify with arbitrary information any TControl, so i created a variant of the ShowForm that takes two ordinal (LPARAM and WPARAM) parameters and send a CM_INIT message to the created TForm instance. The TForm descendant would need to add a CM_INIT message handler and interpret the TLMessage parameter.


function ShowForm(FormClass: TFormClass; Owner: TWinControl; WData: WPARAM = 0; LData: LPARAM = 0): TModalResult;
var
  Form: TForm;
begin
  Form := FormClass.Create(Owner);
  try
    Form.Perform(CM_INIT, WData, LData);
    Result := Form.ShowModal;
  finally
    Form.Destroy;
  end;
end;

So to set to true the MyBool field of a TForm descendant i would call:


ShowForm(TMyForm, nil, 1);

And in the CM_INIT handler:


procedure TMyForm.CMInit(var Msg: TLMessage);
begin
  MyBool := (Msg.lParam = 1);
end;

It worked nice for simple variables like a integer or boolean, but things started to look clumsy when i needed to pass a variable of string or TObject type. Furthermore there's the limitation of restricted number of variables and the danger of the need to assume the meaning of the Msg(TLMessage) fields

There's where the RTTI ability to set arbitrary properties came in hand. All i needed to do is publish a property in the TForm descendant and set it through RTTI functions. This way i got type safety, unlimited number of parameters/variables and clearer code.

The new ShowForm interface:


function ShowForm(FormClass: TFormClass; Owner: TWinControl; FormProperties: array of const): TModalResult;

FormProperties is a array of const where the even items are the property names and the odd items, the property values.

What about RTTI? Pretty simple and direct:


//stripped code (no type check, no array of const parsing)
uses typinfo;
[..]
  ClassInfo := Form.ClassInfo;
  PropInfo := GetPropInfo(ClassInfo, PropertyName);
  case PropInfo^.PropType^.Kind of
    tkAString, tkSString:
      SetStrProp(Form, PropInfo, StrPropertyValue);
    tkInteger:
      SetOrdProp(Form, PropInfo, IntPropertyValue);
    tkBool:
      SetOrdProp(Form, PropInfo, Integer(BoolPropertyValue));
  end; 
[..]

Now to set MyBool property of TMyForm i do:


ShowForm(TMyForm, nil, ['MyBool', True]);

A lot clearer no? ;-)

Draw Rotated Text

2010-02-25T16:39:00.001-08:00

Current version of Lazarus provides the ability to draws text in an arbitrary rotation angle. Although is needed just to set the TFont.Orientation property to configure the feature, the position of the draw text will change according to the angle. So, to make things easier, i wrote a routine that draws a rotated text centered in a given Rect.

If someone needs something similar:


type
  TRotateType = (rtNone, rtCounterClockWise, rtClockWise, rtFlip);

procedure DrawRotateText(Canvas: TCanvas; const R: TRect; 
  const Text: String; RotateType: TRotateType);
var
  TextExtent: TSize;
  SavedOrientation: Integer;
begin
  SavedOrientation := Canvas.Font.Orientation;
  TextExtent := Canvas.TextExtent(Text);
  case RotateType of
    rtNone:
    begin
      Canvas.Font.Orientation := 0;
      Canvas.TextOut((R.Right - R.Left - TextExtent.cx) div 2,
        (R.Bottom - R.Left - TextExtent.cy) div 2, Text);
    end;
    rtCounterClockWise:
    begin
      Canvas.Font.Orientation := 900;
      Canvas.TextOut((R.Right - R.Left - TextExtent.cy) div 2,
        (R.Bottom - R.Left + TextExtent.cx) div 2, Text);
    end;
    rtFlip:
    begin
      Canvas.Font.Orientation := 1800;
      Canvas.TextOut((R.Right - R.Left + TextExtent.cx) div 2,
        (R.Bottom - R.Left + TextExtent.cy) div 2, Text);
    end;
    rtClockWise:
    begin
      Canvas.Font.Orientation := -900;
      Canvas.TextOut((R.Right - R.Left + TextExtent.cy) div 2,
        (R.Bottom - R.Left - TextExtent.cx) div 2, Text);
    end;
  end;
  Canvas.Font.Orientation := SavedOrientation;
end;

Finally...

2010-02-11T04:17:00.000-08:00

... the VirtualTreeView port is released.

The release notes.

Convert database files from Ansi to UTF-8

2010-02-03T14:05:00.000-08:00

While porting old Delphi projects that uses paradox files i faced the problem that the data was stored in an ANSI code page (the current Lazarus version expects UTF-8 encoded strings).

So i wrote an simple application that can convert the encoding of database files (sqlite3, dbf, paradox).

That program can be useful for more than legacy code: after converting a spreadsheet data to a sqlite3 file using Sqlite Data Wizard. The resulted file was in ANSI and there was no option (AFAIK) to convert directly to UTF-8.

I put it here in hope that can be used by someone else.

Using messages to notify events

2009-11-30T02:05:00.001-08:00

Lately, i've been using frames extensively in my projects and recently i faced a little problem while working with them: how to notify the parent control (often a TForm) changes in the state of the frame controls/data?

I tried some approaches:

1) Add an event handler to the TDatasource.OnDataChange event.
This has the disadvantage of not being a generic solution since not always the frame has a TDataSource. Also this event is fired in changes to all fields of the respective TDataset, and often only a few fields need to be monitored, leading to some overhead. Yet is not possible to set the event at design time due to bug 14947.

2)Create handlers for events of child controls.
Works by setting in the parent form handlers for events, e.g. OnChange, of child controls of the frame. It has the drawback of needing more than one event handler in the case where is necessary to monitor more than one control/field.
Another problem is that such event handlers can be cleared by the IDE due to bug 14835. Not to say that sometimes the changes in the frame are not propagated to frame instances. In this case the workaround i found to sync the frames was to remove and add the frame again, loosing all properties set in the frame parent control.

So, i decided to implement a specific event for the frame. The first approach i thought was adding a TNotifyEvent property to the frame but this has almost the same drawbacks of approach 2. At this point the idea of using messages came in my mind.

AFAIK messages are used mostly in LCL and seldom in user projects so i had doubts if would work. Here is what i did:

1) Declare a custom message id constant
I declared the following constant in a shared unit:

LM_CHILDDATACHANGED = LM_USER + 1;

2) Create a method in the frame to send the message
I created a method SendDataChangeMsg with the following code:

var
Form: TCustomForm;
begin
Form := GetFirstParentForm(Self);
if Form <> nil then
Form.Perform(LM_CHILDDATACHANGED, 0, 0);
end;

The code is pretty straight. It get the parent form and then send the message through Perform method

3) Hook the events of the controls that should be monitored
Mostly OnChange events. Just called SendDataChangeMsg inside them

4) Add a property ValidData
This property checks if the data in the monitored controls are valid

5) Intercept the message at the frame parent (TForm)
In the TForm i put the frame, i created a method to intercept the message declared as follow:

procedure ChildDataChanged(var Msg: TLMessage); message
LM_CHILDDATACHANGED;

I'm using that to allow saving or not the data so i put a code to enable/disable the save button:

SaveButton.Enabled := Frame.ValidData;

That's all. It's working fine for me. In the end i got a pretty clear notify system. Now i can remove/add the frame as necessary without the need to reconnect the event handlers every time.

Qt and Lazarus: a nice surprise (again)

2009-11-15T14:06:00.000-08:00

Long, long time ago i wrote how the Lazarus Qt interface impressed me by its functionality. Yesterday, after updating my Lazarus working copy to do some debugging in Linux, i rebuilt the IDE as usual. But the IDE looked a little different, most notably the source editor font. I've got sometime to figure that the IDE was compiled using the Qt interface. I use the gtk2 interface but somehow i left the LCL build configured to Qt, so the unexpected result.

Again, the Qt interface surprised me. The IDE ran fine with good looking and very responsive except by bugs 15101 and 15103. Unfortunately, i use a lot the features that these bugs affect and i will stay with gtk2 for now. But as soon as these bugs are fixed i will give a try to Qt again.

Using TDBEdit to handle date fields

2009-11-01T01:17:00.000-07:00

If you try to link a date field with a TDBEdit, when an user inserts an invalid date, the control reacts with a non user friendly exception message. So, for long time, i used a TMaskEdit to edit date values and then update manually the dataset.
After some debate about TMaskEdit in the mail list i tried to workaround this problem.

The first think i did was to set the EditMask property to !99/99/9999;1;_ and hardcode the ShortDateFormat with a compatible format, e.g. 'dd/mm/yyyy'.

To validate the value inserted i created a handler to be linked to TDBEdit OnExit event(the color setting is optional):

var
D: TDateTime;
DateEdit: TDBEdit;
begin
DateEdit := Sender as TDBEdit;
if not TryStrToDate(DateEdit.Text, D) then
begin
ShowMessage(DateEdit.Text + ' is not a valid date');
DateEdit.Clear;
DateEdit.Color := clRed;
//or set a default value
//DateEdit.Text := '10/10/1900';
end
else
DateEdit.Color := clWindow;
end;

So you clear the TDBEdit and get a empty string that is valid value right? Not so fast. The message dialog will trigger an KillFocus message updating the Dataset with the old (and invalid) value. Calling ShowMessage after Clear does not help because the the control will try to update the dataset with " / / ", that is also not a valid value.

The solution i found was to handle the OnSetText event of the date field to skip all invalid values:

var
D: TDateTime;
begin
if not TryStrToDate(aText, D) then
  Sender.Value := Null
else
  Sender.AsDateTime := D;
end;

With this approach is possible to allow date edition with masks safely.

However, setting events for each TDBEdit and date field is annoying, so i created an TDBEdit descendant to handle this issue. It can be found in the LuiControls package (svn version).

In time:

Rx package has a TDBDateEdit component, but it does not allow editing with masks and don't manage invalid dates.
It's required a recent (post 0.9.28) svn version because of a bug in TMaskEdit in the earlier versions

Effect of using a constant parameter for string types

2008-11-15T18:14:00.000-08:00

Is not rare to find implementations of procedures/functions/methods that uses a value parameter for read only string arguments. While i always use constant parameters for such cases, the real benefit of this code practice was not clear. Until today.

I made a small application that implements two versions of a procedure identical except by the type of parameter (Value vs Constant)...


program asmConstParameter;

{$Mode ObjFpc}
{$H+}

uses
  SysUtils, Types;

procedure DoIt(V: String);
begin
  Writeln(V);
end;

procedure ByValue(V: String);
var
  S: String;
begin
  S := V;
  DoIt(S);
end;

procedure ByReference(const V: String);
var
  S: String;
begin
  S := V;
  DoIt(S);
end;

var
  X: String;

begin
  X := 'Test';
  ByValue(X);
  ByReference(X);
end.

...and examined the assembler output. See the difference yourself. Using optimizations through -O compiler options does not change the produced code.

So using a constant parameter has a practical effect, is not only a good code practice.

BTW: just for curiosity i put {$IMPLICITEXCEPTIONS OFF} in the program header. Not bad. Be aware that this info is here just for curiosity ;-) .

UPDATE: Using constant arguments also benefits ShortString types. See.

Status of Virtual Treeview port

2008-10-26T11:52:00.000-07:00

It has been more than one year after the last blog update about the Virtual Treeview (VTV) port and some people may be asking what happened with it.

The port is far from dead. In fact, it is fully working under Win32, Gtk1/2 and Qt since, at least, the previous six months. I was just waiting to the Lazarus 0.9.26 release to do an official release. Lazarus 0.9.26 is out, so where is the new VTV?

One of the main features of Lazarus 0.9.26 is the Unicode support for Win32 interface that, in your turn, uses UTF8 encoding. Currently VTV supports Unicode by using UTF-16/WideString and was working fine. After the LCL Unicode switch some encoding conversion problems appeared when iterating with strings returned by databases or LCL controls, so i decided to anticipate the migration to UTF-8 before doing a release.

This task is not trivial and i'll start to work on it only after December, so don't expect an release soon.

This has some advantages:

There will be no need to further string types changes (WideString -> String) in applications created with the released component
It will be faster since WideString is known to be slower specially under Win32

Anyway if someone is interested in testing the component check the instructions on how to use the svn version here. Be aware that a change from WideString to String type will be necessary in the long run.

LCL, Gtk2, Pango and Cairo

2008-06-01T13:54:00.000-07:00

Introduction

Lately, in the Lazarus mail list, has been a lot of discussion about the performance of LCL/TextOut under Gtk2 and many (erroneous) arguments used derives from the lack of proper knowledge, including from myself. So in this article, i'll try to clear the things a bit.

When Gtk2 was released back in 2002, Pango was one of the Gtk2 main new features. Pango provides support to render Unicode text (encoded in utf8) with advanced layouts. But i was also one of the reasons of the degraded performance of Gtk2 when compared with its predecessor.

Pango has a flexible design allowing to use different backends (Cairo, Xft, Win32, X) to render text. Until version 2.6 Gtk2 used the Xft backend that was replaced, starting from version 2.8, by cairo (a 2D vector drawing library) as the default renderer. At that time the performance dropped even more, but after some work in pango and in cairo, the things got better.

So, the first point to take in consideration when evaluating pango performance is the version of pango and cairo. More on this later.

Testing LCL

In order to get an accurate diagnostic, i wrote an test application that fills an entire window with text using TextOut and compared the results (output quality and time to draw) of the Linux widgetsets (Gtk1, Gtk2, Qt).

Here is the output:

The time to draw an entire screen (average times of 15 iterations):

gtk1: 24ms
gtk2: 150ms
qt: 92ms

The gtk1 widgetset is really fast but it has two drawbacks: the font quality is low and the screen flickers while updating.
The gtk2 widgetset is the slowest loosing to qt by 60%, but in other hand has the sharpest font draw. An important point is that when double buffer is disabled (LCL disables it by default), the screen flickers just like gtk1, but if double buffer is enabled there's no flicker and the screen is updated instantaneous.
The qt widgetset is in the midterm both in quality and in speed. Not sure why qt text looks blurred: if is a configuration or the default font is not so good. There's also no screen flicker since qt is all double buffered.

Gtk2 dissected (almost)

Pango allows more than one engine to be used and there's also the options to draw directly using cairo or the old gdk functions (that use the X11 bitmap fonts). So i wrote an application using direct calls to the gtk2 api. It draws text with default Gtk2 (Pango/Gdk), Pango/Xft, Xft, Cairo, Gdk/X11.

The output (Cairo is equal to Gtk2 and Gdk/X11 is equal to LCL/Gtk1):

The time results:

Gtk2 (Pango/Gdk): 130ms
Cairo: 90ms
Xft: 70ms
Gdk/X11: 12ms
Pango/Xft: 110ms

Gtk2: very close to LCL/Gtk2
Cairo: the same quality of Pango/Gdk (I would be very surprised if was different ;-)) but significantly faster
Xft: Almost two time faster then Pango/Gdk but with lower quality output (An configuration issue?)
Gdk/X11: basically the same output of gtk1. Again really faster but without the screen flicker of gtk1.
Pango/Xft: faster than Pango/Gdk, slower than Xft. Out of option since is not working at all: it draws always at 0,0 coordinates.

Alternatives to pango?

From this tests, using directly Cairo to draw text seems to be a good option to replace Pango: the same quality and faster. But is not that easy. With direct calls to Cairo is needed to do all sort of text position (bidi, alignment) and text styles (underline) manually. Also it would be necessary to do the font selection and loading logic manually in a system specific way,i.e., is necessary different code to Linux/Win32/MacOSX.

Another option is using Xft directly. Aside from the different/worse output, it would be necessary to change the widgetset to retrieve the XftDraw handle for each drawable which is a complex task principally for double buffered controls. All in a system specific way.

Gdk/X11: the quality of output and lack of Unicode support makes a no-no option. At least for me.

Conclusion

Is there a direct/easy/faster replacement for Pango under LCL/Gtk2? No.

Here is necessary to make another question: there's a real need to replace it? Like shown earlier, default Pango is really slow compared to other alternatives, but, principally when double buffer is enabled, there's no visible glitches or general system slowdown. Is also necessary to take in account the increase of code size and complexity in LCL/Gtk2 side to make such change.

Notes

The test applications can be found here and here. Is necessary the package chronolog;
The test were conducted in a Celeron 1.4, 512MB, with an intel integrated video running Ubuntu 8.04;
Upgrading from Ubuntu 7.10 to 8.04 leaded to an significant speed in all widgetsets (Gtk2 250 > 150 / Gtk1 50 > 24ms);
I also tested drawing with low level Pango api. I'll post the results later;
~~Win32 took impressive 5ms in the same test~~ Not to be considered since the win32 test was done in another (more powerful) machine;
A point that is not directly related to text draw but affects performance of LCL/Gtk2 is the fact that the LCL/Gtk2 test application calls 4 times FcFontSort, while a Gtk2 pure application calls only once. This is an expensive call that takes almost 20% of the application time.

Reduce memory usage of LCL

2008-03-15T16:17:00.000-07:00

To test the conclusions of the last post i modified the field order of some LCL classes to group together Boolean fields.

Here's the return value of the InstanceSize property:

TButton
before: 874 bytes
after: 829 bytes (saved 24, 16 and 5 bytes in TControl, TWinControl and TCustomButton respectively)

TMenuItem
before: 152 bytes
after: 136 bytes

In an application with 100 controls and 20 menu items you save 2400 (considering only TControl memory) and 320 bytes respectively.

Maybe be this is negligible in computers with 1GB or more of RAM, but for mobile platforms it makes a difference.

The patch is here. Have fun!

Memory layout (and size) of a object

2008-02-19T07:05:00.000-08:00

After reading a article about memory layout of objects in Delphi i was curious about how fpc behaves. So i did some small tests:

Memory layout of objects (instances of a class)

At offset 0 resides the virtual method table. Starting from ofsset 4 comes the fields. Just like in Delphi.

Number of associated methods

The number of associated methods and if they are virtual does not influence the object size. Just like in Delphi.

Type of the fields

According to the cited article, Delphi reserves 4 bytes for each field even if the type has a size of 1 byte. Here comes the fun.

Take the following classes:

TOneFlagClass = class
Flag1: Boolean;
end;

TTwoFlagClass = class
Flag1: Boolean;
Flag2: Boolean;
end;

The size of TOneFlagClass and TTwoFlagClass are 5 and 6 bytes respectively (4 for the vmt and 1 for each field). The memory offsets of Flag1 and Flag2 are 4 and 5.

Delphi is a bit different here. The size of both classes are 8. The memory offsets of the fields are the same as fpc.

At this time i think: "In this case is better to place less than 4 bytes fields at the end of the class declaration to avoid subsequent fields to be accessed outside the dword boundary"

I was wrong. In fact half wrong:

Take the following classes:

TFlagFirstClass = class
Flag1: Boolean;
Int1: Integer;
end;

TFlagLastClass = class
Int1: Integer;
Flag1: Boolean;
end;

The size of TFlagFirstClass and TFlagLastClass are 12 and 9 respectively. The compiler allocates 4 bytes for the boolean field to maintain subsequent fields (that has a size of 4 bytes) aligned with the dword boundary.

If another boolean field (Flag2) is added just after Flag1, the instance size is not affected. In fact, grouping 4 boolean (or another 1 byte type) fields together will lead to the same instance size as only one boolean field if those are succeeded by Integer or Pointer like types.

In the end, my suggestion is still valid: put the "less than 4 bytes field types" at the end of the field declaration of the class (or group together in groups with 4 bytes in total). You will save some memory.

If you are not convinced compare size of a class with the following fields sequence:
Boolean, Integer, Boolean, Integer, Boolean, Integer, Boolean, Integer
Boolean, Boolean, Boolean, Boolean, Integer, Integer, Integer, Integer
Integer, Integer, Integer, Integer, Boolean, Boolean, Boolean, Boolean

Some notes:

Object here is not referenced as the object type (that has the same memory layout of a record), but as the instance of a class
There's no difference between mode delphi and objfpc
It's valid only for i386 architeture. No idea how this works in ppc, amd64, arm

Effect of buffer size in deflate and md5

2008-01-23T14:20:00.000-08:00

I tested the effect of buffer size in compressing a file using deflate procedure (paszlib unit) and calculating the md5 (using the functions of md5 unit).

I loaded a 30MB file in memory and did the compression/md5 calculation. The buffer size varied from 1024 to 512.000.

To my surprise no significantly difference was found, so no graph this time since is almost a plain line.

What Time Is It?

2007-10-26T18:55:00.000-07:00

How many cairo clocks the world needs?

I don't think we have sufficient!

Effect of buffer size for reading files [Linux]

2007-10-15T10:35:00.000-07:00

Reading a file entirely in memory is not a good idea as stated before, but how large should be the memory buffer?

I did a test under Linux (Ubuntu 7.04) reading the fpc2.2.0 installation file (29MB) using different buffer sizes.

Here's the result:

The time to read the file decreases as the buffer size increases until the buffer is 128kb then, as the buffer gets bigger, the trend inverts.

Some notes:

The test was executed three times for each buffer size. The results are expressed as the Median;
The Y axis is the time to read all the file in microseconds. The X axis is the buffer size in bytes;
The first time the file is read is significantly slower than subsequent reads. Probably this is an effect of the OS file system buffering (I did not find a way to skip it). This limits further analysis. However, excluding the first run, all other results are consistent across the same buffer size. All results can be browsed here.

Strange days...

2007-10-01T08:55:00.000-07:00

Since day 1 of Lazarus, the gtk1 widgetset is the default, and reference, interface under Linux.

Today, after one of my applications crashed using gtk1, i tried it with the Qt4 interface: it worked flawlessly!!.

The Qt interface, given the recent work, is in the way to become the standard widgetset under Linux. Wait and see.

Update: Using Valgrind/massif with fpc

2007-09-25T05:41:00.000-07:00

In a previous post i claimed that the option to hide memory allocation wrappers in massif was broken or not working with fpc.

The problem is that i was using only the pascal name of the function (CMEM_CGETMEM) instead of the mangled internal name (CMEM_CGETMEM$LONGINT$$POINTER).

Thanks to Michalis Kamburelis that gave the hint and also provided this script:

#!/bin/sh
set -eu

valgrind --tool=massif \
--alloc-fn='CMEM_CGETMEM$LONGINT$$POINTER' \
--alloc-fn='CMEM_CREALLOCMEM$POINTER$LONGINT$$POINTER' \
--alloc-fn='SYSTEM_GETMEM$LONGINT$$POINTER' \
--alloc-fn='SYSTEM_GETMEM$POINTER$LONGINT' \
--alloc-fn='SYSTEM_REALLOCMEM$POINTER$LONGINT$$POINTER' \
--format=html \
"$@"

I updated the previous charts so they show where in pascal code the memory is allocated.

PS: it's annoying that the function names are truncated in the charts.

Zlibar memory behavior compressing many small files

2007-09-23T12:11:00.000-07:00

The previous analysis of zlibar memory behavior was done taking as example the compression of one big file. Let's with many small files (all *.pas files under lazarus/lcl dir).

Original (load the entire file in memory):
The heaptrc dump:
18573 memory blocks allocated : 496119560/496173048
18573 memory blocks freed : 496119560/496173048
0 unfreed memory blocks : 0
True heap size : 4423680
True free heap : 4423680

After memory optimization (load file in small buffer):
The heaptrc dump:
17446 memory blocks allocated : 439659064/439708048
17446 memory blocks freed : 439659064/439708048
0 unfreed memory blocks : 0
True heap size : 2326528
True free heap : 2326528

We can take some conclusions:

The memory usage is almost equal over time (the graph scale does not help much here)
UPDATE: the heaptrc dump shows that the original code really takes more memory.
In the optimized build the memory is allocated in a continuous fashion, always growing. The original build the memory is allocated and freed all over time while still growing in the end. This can lead to more memory fragmentation.
In the optimized build there's not the final peak. This is not really expected since the section of code responsible by the peak was not changed. Some options: 1) the peak exists but valgrind does not detect 2) a bug in the optimized code 3) an unexpected (and good) side effect

Reduce zlibar memory usage - step1

2007-09-23T08:28:00.000-07:00

Previously we learned that zlibar uses 1.5MB of memory to compress a 1.1MB file. It compress each file in three passes: 1) loads all the file into memory 2) feed the deflate function with this data using a small buffer as a bridge 3) calculate the md5 signature transversing the file data again.

The option is to compress using only one pass: load the file data incrementally into a memory buffer and than feed deflate and md5 functions with it. It has two advantages: the memory usage (in this step) is constrained by the size of the buffer and you save the memory copy from the stream (that holds the file data) to the deflate buffer and to md5 buffer.

The modified InternalCompressStream function would be something like:

MD5Init(Context);
z.next_in := @input_buffer;
z.avail_in := FileRead(InStream, input_buffer, MAX_IN_BUF_SIZE);
MD5Update(Context, input_buffer, z.avail_in);
while z.avail_in > 0 do
begin
repeat
z.next_out := @output_buffer;
z.avail_out := MAX_OUT_BUF_SIZE;
err := deflate(z, Z_NO_FLUSH);
OutStream.Write(output_buffer, MAX_OUT_BUF_SIZE - z.avail_out);
until Z.avail_out > 0;
z.next_in := @input_buffer;
z.avail_in := FileRead(InStream, input_buffer, MAX_IN_BUF_SIZE);
MD5Update(Context, input_buffer, z.avail_in);
end;
MD5Final(Context, Result.Md5Sum);

Lets run valgrind/massif to see what we got:

Comparing with the previous graph we notice a great memory usage reduction: from 1.5MB to 0.5MB.

The heaptrc dump:
55 memory blocks allocated : 2811961/2812056
55 memory blocks freed : 2811961/2812056
0 unfreed memory blocks : 0
True heap size : 950272
True free heap : 950272

Let's do a deeper analysis:

The memory used by deflate functions is close to the expected 256kb.
The pink area is the memory used by the stream that holds the compressed data. It is allocated incrementally so the ascending angle.
There's a peak after the deflate memory is freed and just before the program finishes. This represents the copy from the compressed stream to the output stream that doubles the data in memory. More on this later.

Someone may say that load a file using a small buffer is slower than reading all data directly in memory. This is true but it would be reasonable only with small files. In a general usage packer it would be a big limitation.

Using Valgrind to profile fpc applications

2007-09-18T11:23:00.000-07:00

Before starting to optimize is necessary to know beforehand what and where to optimize. It's here that the profiler tools plays a role. Valgrind, and its brother KCachegrind, are know unix profiler tools that makes success in the C crowd. Let's see if is useful to fpc programmers.

Zlibar is a fpc component that encapsulates the paszlib functions in a programmer friendly way. I use it in the Becape application and for sometime i have a plan to optimize it.

The heart of the component is the TZlibWriteArchive.CreateArchive method that compress the files (InputFiles) into a stream (OutputStream):

TmpStream := TMemoryStream.Create;
TmpFile := TMemoryStream.Create;
[..]
for X := 0 to fInputFiles.Count-1 do begin
[..]
TmpFile.LoadFromFile(fInputFiles.FileName[X]);
[..]
FileInfo.CompressedSize := InternalCompressStream(X, TmpFile, TmpStream); //(1)
FileInfo.Md5Sum := StreamMD5(TmpFile);
[..]
end;
WriteHeader(AHeader);
OutStream.CopyFrom(TmpStream, TmpStream.Size);//(2)
[..]

It creates two temporary memory streams (TmpFile and TmpStream). TmpFile will hold the uncompressed data of the file being added. TmpStream will be filled with the compressed data in step (1). The process continues until all files are compressed in the TmpStream.
After that the header is written in the OutputStream and then the compressed data is written in the OutputStream.

The problems:

The file is stored entirely in memory before is processed. For small files is fine but for larger files it would be problems.
Even for small files the memory of TmpFile will be reallocated in most of the LoadFromFile calls
After step (2), you will have three streams in the heap: an uncompressed file, the compressed data of all files and a header + the compressed data of all files

To see this in action i created a small application that just compress only file (the VirtualTrees.pas with 1.1MB), and compiled with -gv (Generate code for Valgrind) and -gl. Run with valgrind(callgrind):

valgrind --tool=callgrind ./zlibar_opt

It was created a file with the pattern callgrind.out.[pid] that i loaded in KCacheGrind. In this tool is possible to see most of the function calls the application did, the times that each function were called, who called who, and the time each function spent.
To my surprise the memory allocation routines does not spent much time (in fact was zero). The most expensive was, of course, the compression related functions.

Now let's use the massif tool:

valgrind --tool=massif ./zlibar_opt

It creates two files: massif.[pid].ps and massif.[pid].txt. The txt file contains info about the callstack and how much memory each function allocated. The ps file contains a graphic showing the functions that were responsible for most memory allocation and the evolution in time. See below:

Now you say "what hell is this"?
To work with valgrind the -gv option forces the use of the cmem memory manager which is a wrapper around malloc, so massif understand the cmem* functions as the programmers allocation routines. I tried to use the fn-alloc option to force the display of the pascal functions without success.
Update: i was passing only the pascal name function (CMEM_GETMEM) to fn-alloc while is necessary also the parameter list names. I updated the charts to show where in pascal the memory is allocated.

Anyway in the graphic we can see that 1.5MB of heap memory is allocated (used?*) at its peak and that is the point where we can optimize.

Here's the heaptrc dump:
58 memory blocks allocated : 3926105/3926208
58 memory blocks freed : 3926105/3926208
0 unfreed memory blocks : 0
True heap size : 950272
True free heap : 950272

In the next articles, i will take a look in the possible optimizations.

Notes:

* The fpc heap manager pre allocates space in the heap that sometimes is not all used but i dont know if this is still valid when using the cmem functions
The -gv option is necessary to run the massif tool but is dispensable when using the callgrind
The valgrind checkmem tool is of little utility to fpc since it provides the heaptrc unit with a lot of advantages
One drawback of valgrind is that is exclusive to unix. No windows.
For more info see the valgrind manual

Back to blogging and to lower levels

2007-09-18T11:13:00.000-07:00

This blog has been quiet lately, but is not dead.

In the last months a played a lot with LCL, sometimes in the VirtualTreeView port, sometimes writing original components. I will take a rest in high level/GUI programming and return to lower levels.

Starting from today i will post a sequence of articles about memory usage and general optimizations to fpc/Lazarus applications.

Later, i plan to talk about file system integration and IPC techniques.

... and not alone!

2007-03-15T13:09:00.000-07:00

After getting VTV to work reasonably well under Windows, i started to port it to Linux/gtk.

It's already compiling but crashes at start with the following message:

"BadMatch (invalid parameter attributes)"

Searching such message in Google i get 32.800 results.

At least, i'm not alone ;-)

Not so far ...

2007-03-15T13:08:00.001-07:00

Before than i think i got VTV to work under Windows (In fact is working since, at least, two weeks).

Is almost everything there: Header, OLE drag and drop (and VCL too), Unicode, Bidi. Alpha Blend is still missing. There are also some graphic glitches with the more advanced examples.

Here's a sample:

Traps of Delphi to Lazarus conversion

2007-02-15T10:54:00.000-08:00

There's only a thing worse than a bug difficult to resolve: a bug difficult to find. As an example, i was getting a weird bug in the drawing of VTV. The colors were being painted wrongly and only after a few hours i figured what was going on. See the code below:

with Canvas do
begin
[..]
Brush.Color:=Color;
[..]
end;

Apparently nothing wrong. But the Devil resides in the details. Under Delphi there's no TCanvas.Color while there's in LCL. The result of this code, in Delphi, is that Brush.Color is assigned to TControl.Color. In LCL, Brush.Color is assigned to TCanvas.Color (which in your turn points back to Brush.Color!!).

You can't even say that there's a bug in LCL or in the program. Is just one of traps found while converting Delphi code.

The same occurs with TCanvas.Width/Height (does not exist in Delphi) and TBitmap.Width/Height when used inside compound "with" statements.

Children of the port

2007-02-12T03:34:00.000-08:00

A working new VirtualTreeview is far from reality but there are already some results.

Since this is really a complex software, a lot of debugging will be necessary so i needed to extend the Multilog component/package. I just released a new version. But one of the functions i added was the ability to log memory areas and i needed a component to display it. This way i ended porting ATBinHex (in fact is a grandchild of the port ;-)).

As a bonus i implemented TOleStream that was missing from Delphi.

You can find them at https://luipack.bountysource.com/

Ports of Delphi components

2007-02-03T12:22:00.000-08:00

Last week i started to port two Delphi components: the already know VirtualTreeView and ATBinHex a Hex viewer. At the moment VirtualTreeView is compilable but does not work and ATBinHex works under Windows only. Both code can be get in LuiPack, a project i started to centralize and help keep track the components i develop.

Before someone would ask: "Why do a new port of VirtualTreeView if already exists one?", here are the answers:

The original port of VirtualTreeView (VTV) was based in version 4.0.17 from December 2003. Currently we are in version 4.5.1. A lot of changes happened after that. One option was to see what changed and than backport to the lazarus version. But two problems arise: At the time of 4.0.17 the VTV code was not in a version control system making hard to know what changed. Furthemore, the chances that applying these changes would conflict with the modifications done in lazarus port are high.
So this time, the VTV code is in a svn server being easy to see what changed and than backport small modifications to lazarus if appropriate.
Some features were removed in the port process (CheckBox images, AlphaBlending, Bidi support) and other bugs introduced. To completelly fix them and add the missing features would require deep knowledge of how VTV works and the success was not guaranteed. So i believe the work to do a new port would be only a more hard than to fix it.
In that time LCL/fpc was far from what is now. This allow to do a easier port without the need to remove features. So, instead of removing features the idea is to fix the LCL, where appropriate or redo with LCL/fpc functions.

PS: Don't expect a working VTV soon, because of the decision to not remove features will lead to a long road.

It's Open Source stupid!

2006-12-29T03:50:00.000-08:00

In the previous post i badly evaluated the gtk api, but in one thing it is far ahead from win32: it's open source.
To fix this bug i just looked in the gtk source the routine that insert items in a listbox (See gtk_list_insert_items in gtklist.c). Easy.

Eliminating duplicate events of TComboBox and TListBox

2006-12-27T11:22:00.000-08:00

One year ago i posted a bug in Lazarus about the problems of TComboBox events. The win32 part was resolved but not the gtk one. So i think it was time to learn something about gtk programming.
To help me find where the problem was i used the MultiLog, a logging component useful to debug gui apps.

The diagnostic: i wrote a small app that has a combobox with the OnChange and OnSelect events set. After selecting an item in the dropdown list two events are fired: first OnSelect and than OnChange. I put a call to Logger.SendCallstack in both events handler and i got from where the events were being called:

- [internal gtk calls] > GtkListSelectChild > DeliverMessage > LMSelChange
- [internal gtk calls] > GtkChangedCB > DeliverMessage > LMChanged

Than i figured that GtkListSelectChild is attached to the 'unselect_child' signal of the TGtkCombo.list handle (the dropdown list) and that GtkChangedCB is attached to the 'changed' signal of the TGtkCombo.entry handle (the edit box).

The next step was to see what is going on there. After reading the gtk 1.2 reference, i put log messages in GtkChangedCB and GtkListSelectChild to get the gtk_signal_n_emissions for both. The idea was that i could break the OnChange firing using gtk_signal_emit_stop function. But unfortunately, only apparentelly as you will se later, i was wrong. According to the results (see figure 1) it seemed that the 'changed' signal was started after the 'unselect_child' signal, so there would be no way to stopping it inside GtkListSelectChild.

Figure 1

The things was not going as planned and i had the idea of connecting to the 'select_child' signal (i used a function called GtkListSelectChildNew). At first look, it was a hope since this signal is triggered twice, before and after 'changed' (See figure 2) and i could use the LockOnChange procedure to avoid its execution.

Figure 2

So i incremented the LockOnChange in the first GtkListSelectChildNew and.... Nothing!!. This strategy did not prevent the message deliver in GtkChangedCB.

At this time i knew that there were something very very wrong and after examining the handles of the PGtkWidgets (PGtkCombo, PGtkList, PGtkEntry) i found that i was getting the PGtkCombo handle in the wrong way: i was relying in the TGtkWidget.parent field of the list and entry handles. This parent field is anything but the combo handle (I dont know who is more stupid: me or gtk). The right way is using the data parameter of the callback functions that holds the LCL Object address from which i can get the Handle field.

From this point everything got easier. The 'changed' signal is emitted before 'unselect_child' (see Figure 3) so the gtk_signal_emit_stop (using the correct handle) called inside GtkListSelectChild prevents the GtkChangedCB to be fired. My initial idea was correct, only not properly implemented!.

Figure 3

But is not over yet. After stopping in GtkSelectChild the 'changed' signal, if i click in the dropdown list only OnSelect is called, as desired, but the first change in edit box calls OnSelect ('unselect_child' signal) instead of OnChange ('changed' signal), the subsequent changes in the edit box call OnChange correctly.

No panic!. I noticed that the 'select_child' is not fired in this case, so i could use
it instead of 'unselect_child'. But this brings another problem: 'select_child' is fired twice. But nothing that some refactoring can not resolve.

The final schema i got:
- GtkListUnselectChild is connected to 'unselect_child' signal. Inside it the signal to 'changed' is stopped as well one of the 'select_child' signals. No message is delivered.
- GtkListSelectChild is connected to 'select_child' signal. The previous routine guaranties that is called once. The message is delivered to the LCL
- No changes to GtkChangedCB

I fixed the problem of TListBox.OnSelectionChange with similar approach.

Now it's time to do some more testing, clear and comment the code so i can send a patch.

The programs i used to do the tests can be found here and here

I have some experience with the win32 api and this was the first time i looked deep in the gtk programming. What i can say is that a convuloted gui api is not exclusive of the Windows programmers ;-) .

Only one instance

2006-12-16T16:13:00.000-08:00

Usually each time you launch an application a new instance is created, but sometimes is not desired to have more than one instance running. There was no way to force only one instance using Lazarus/fpc and was some discussion in the maillist the best way of implementing it (using mutex, file locking etc). I had a different idea: how about to use simpleipc, a IPC mechanism which comes in fpc?

So i started to implement such component based in simpleipc. First i searched how the Delphi programmers resolved this problem. I found two open source components TRunOnce and TInstanceControl. Both uses a file mapping technic which is win32 centric, so without use for me and i already had another idea. But i learned with them that the best place to do the implemantation is inside the Loaded procedure which is called just after the components are streamed and before the form is show.

The algorithm is pretty simple: a client (TSimpleIPCClient) checks is there's a corresponding server (TSimpleIPCServer) running, if so (a instance is already running) notify the server (the running instance) and terminate the app, otherwise it means that is the first instance so init a server and let the program go.

The next step was a little more difficult: how to pass the command line arguments to the second instance. I had 3 options:

Pass the cmdline as is and let the receiver (server) parse it. Not good since the parsing of the command line is not so simple and probably platform dependent
Pass each argument (ParamStr(x)) separately. It was considered but, in the server side, i needed a way to tell that the argument passing was starting (to set the length of the array), than pass the parameters itself and finally notify that the arguments finished (to fire the event). I could do that passing special chars as markers or with numerical values in the beginning of the stream. Definitely an overkill.
Create an easily parsable string with the parameters in the client side and then send once. The chosen one.

To the tests. Aside from a bug of the style for x:=1 to y do; everything worked fine. Only one annoyance: the form was being show in a few instants before it was killed. So, looking at TApplication.Run i found a ShowMainForm property and voila: no flashing form.

The results can be found here

Delphi is far away from Lazarus/fpc, no doubt, but this is an example that some problems can be resolved cleaner and easier with the open source solution.

PS: more difficult than write the component is creating a icon for it. And the result... LOL

Hiding a TNotebook tab

2006-12-15T02:49:00.000-08:00

While developing with TNotebook, i found some problems using TPage.TabVisible property. If we Toggle TabVisible forth and back of more then one page, the tab title does not correspond to the page content. So i took a look into this issue.

To examine the bug i created a test project with a notebook containing 3 pages (Page1, Page2 and Page3 - creative names no?). If we set TabVisible of Page1 to False, everything is fine: the remaining pages are correct. Setting it back to True also works like expected. However, after setting TabVisible of Page1 and the Page2 to false the problem appears: the remaining page (which should be Page3) has the Title of the Page2 and no content (should have a TLabel) inside it.

To the work. A look in TCustomPage.SetTabVisible lead us to TCustomNotebook.AddRemovePageHandle. In this routine, if the TabVisible is set to true a page is added otherwise removed through a widgetset function. Here's the problem: to add the page its passed the VisibleIndex as the insert position but to remove the PageIndex is used as the position instead. In our example, when all Pages are visible, PageIndex = VisibleIndex so no problems, when Page1 is not visible Page2 gets VisibleIndex = 0 and PageIndex = 1. In this situation, setting Page2.TabVisible to false informs the widgetset to remove the page with index 1 (PageIndex) when should be 0 (VisibleIndex).

After the fix, the problem vanishes, but it still not working as should. If Page1 is the active tab and Page1.TabVisible is set to false no page is selected and the content area stay blank. Worse: Notebook.ActivePage still points to Page1. More work.

Examining the ActivePage property we discover that it depends of the TNotebook.PageIndex, so is necessary to update the pageindex properly after toggling the TabVisible. I found that in TNotebook.RemovePage method the new pageindex already computed but does not consider the TabVisible state. I reworked the routine creating to auxiliary functions ,with the suggestive names of SetNewPageIndexAfterPageRemove and GetNearestVisiblePage, which takes in account the TabVisible state.

The test program and the patch can be found in the bugreport.

The patch also does some cleanup in the code:

TCustomPage.SetParent set TabVisible to false before calling RemovePage. I removed the TabVisible assignment since RemovePage already does the job.
In GetActivePageComponent and GetActivePage i changed from PageIndex to fPageIndex (Notice that in other functions fPageIndex is already used)

PS: I tested in win32 but notice that the modifications are done only in LCL level so should not be problems with other interfaces.

Start (or better: begin)

2006-12-15T02:42:00.000-08:00

In this blog i will write about the problems and solutions i found while developing with Lazarus and Freepascal. It will be mostly technical articles. Maybe it can be useful for someone else.