Lazarus Development

LCL for Android

2011-11-25T14:55:00.004+01:00

As the maintainer of LCL-WinCE of course I was quite shocked when Microsoft dropped Windows Mobile into the limbo and announced that native applications would be restricted to a very small list of favorite partners. Because of this, since almost 1 year now I have been trying to port the LCL for Android.

My first success was in 19th January 2011 when I first built a good x86-linux -> arm-linux cross-compiler which I have been using ever since and I hosted here: http://sourceforge.net/projects/p-tools/files/Free%20Pascal%20for%20ARM/

After that I slowly started exploring Android and the SDK with many pauses. My free time floats a lot depending on the work load, my mood and my current interests. I have other hobbies which alternate as my biggest interest from time to time. The most important ones are: trains (reading news and discussing in skyscrapercity as well as travelling), politics (I'm right wing / conservative), keyboard playing and Pascal programming.

Ok, so next thing around in August I got some bounties which motivated me to make a good push. When I started we were in Android 2.2 still, and I bought a HTC Wildfire which came with 2.1 and can be upgraded only up to 2.2. At this time the perspectives for native applications were quite doomed, you had to interface with Java via the horrible JNI, I got pissed off by that and I developed an alternative system which worked by running a native executable and communicating with pipes with a Java machine. I posted about it in the android-ndk Google group and the Google guys hated my idea, they told me to buy and iPhone and try programming for that instead =D Well, I could do that, but seriously the Lazarus community is on a high mood for Android support, I don't remember yet anyone asking about iPhone support ... even requests of WebOS and Bada were heard. My hacky development strategy might sound like a bad idea, but I had many motivators for it:
1> If you can only have a library then the way LCL applications work changes dramatically =( I'm not sure yet how this will be worked around. You cannot keep the same main project file if Android requires a library and you also need changes in the project code flow.
2> FPC has a lot more bugs for library development then for executable development, specially in ARM-Linux
3> Using my method I could access the entire SDK without JNI! A true blessing. So I could quickly push some controls and get things working.
4> I also hoped that if people pushed then Google would flexibilize and support executables, but now I think I was too optimistic. At that time Android 2.3 was released and it brought a lot of improvements for native applications, but ever since there were very few changes in the NDK, so I lost my hope that Google would support native executables.

The alternative way would be creating a native library which draws all controls, and there are enourmous challanges in doing this. So, fast forwarding a bit into the future, after a bounty I got some expertise in NDK development with OpenGL so I got quite animated and I started a huge push to see how far I can push LCL-CustomDrawn until I run out of steam.

These days I feel like soldiers must have felt in the Market Garden operation, running against time to take all bridges in the way. I am not trying to consolidate the entire area, I just need to make as many breakthroughs as possible in as many key areas as possible to make sure that my development strategy works. Every time that we start doing something which was never done before, like LCL in Android you have a huge uncertainty about whether or not it will actually be possible to work, or if I will face a huge wall somewhere, like a compiler bug or a problem which needs a lot more steam then I got to solve ... so I want to clear the way and establish that my strategy indeed will work.

So far I have already taken the following bridges:

1> Lazarus Custom Drawn Controls - The first one to be tackled, it is far from complete, but I advanced it so well and so fast that it is clearly proven that we can have our own set of custom drawn controls inside Lazarus

Reference: http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls

2> Developing the major structure of LCL-CustomDrawn to allow painting with a non-native Canvas into a native surface. I already implemented this for Win32, X11 and Cocoa, so we are quite advanced here.

3> Develop a system to clip the painting of sub-controls and also clip events from sub-controls inside a form. In LCL-CustomDrawn TWinControl will be non-native, because some platforms like the Android surface do not support it. I have achieved success here too.

Now I am trying to push into a last bridge, which is resisting heavily:

4> Achieving a minimal LCL-CustomDrawn application which can run in Android and paint at least a rectangle or something.

I am facing big challanges in this task, the major ones being that when I simply include the LCL the application starts to crash, even if I don't call anything from it =( I have narrowed down to cwstrings, which is a major source of crashes, so I disabled it, but now the application crashes when clicking on it. I tryed to comment out all initialization sections in the LCL, but it didn't help. My greatest fear is a compiler bug somewhere which would reproduce only in big programs like LCL apps and stop me =( But so far it appears that I am going well, let's hope we will succeed here and clear 1 more obstacle in this difficult road.

Edit: I managed to get it working now, the second problem was introduced while debugging the cwstring issue. Now it works fine =) So we are each day closer to have LCL-CustomDrawn running in Android. From what I can see my snapshot compiler has no bug which could defeat us, so the path is ready =)

Edit2: Now it loads the application and it can draw some green stuff =D Really exciting days for LCL-CustomDrawn-Android. It still doesn't do anything useful, but the entire fact that it loads without crashing and can render something is excellent.

Remember, Remember ... The History of Debugging

2011-05-16T03:41:00.005+02:00

Debugging your application can be an intriguing task. And analyzing what happens in your application, and what went wrong (or maybe right), often requires the developer to keep an eye on quite a lot of data.
Sometimes that means not only to look at the data as it is on the current step of execution, but also to compare it to what it was on the previous step(s).

Lazarus does now provide a history overview for watched values, locals, and call-stack. Each time your application stops, a record of this data is made and stored.
By default Watches and Locals are recorded for the current stack-frame/thread. But if you browse other frames or threads by selecting them in the stack or threads overview windows, then Lazarus will notice this and keep track of those too.

A new debug window "History" provides access to all recorded values. Currently this is up to 25 history entries. And you can even browse the history after you program terminated.
If you have a history entry selected, you can use the stack-window to change the current stack. If any data was collected for the selected frame, it will be shown. Currently data for extra stack frames is only collected if the frame was selected, while your app was running, and if the watches or locals window where open and active.

There is however a little twist to it. Collecting all the data takes some time. To avoid any slowdown of the debugger, this new feature works on idle time only. It collects data, only if the debugger has no other work. This even means that you can continue the execution of your application, without having to wait the full time it would have taken to get all the data. In this case the snapshot will be incomplete.
If you want to ensure complete snapshots, you can open the watches, locals and stack window, and observe when the information has been fully fetched, as it gets displayed to you.

This feature is available in Lazarus 0.9.31

Profiles for Build Lazarus

2010-11-15T22:54:00.008+01:00

The dialog opens from Tools --> Configure "Build Lazarus".
It is meant for building Lazarus or parts of it, using the given parameters.
The original dialog looked about like this.

The dialog was made by the same developers that actually use it all the time. Thus the GUI is little confusing, it's main design goal was not "ease of use".

Then some people made an effort to simplify the GUI. They didn't touch the original GUI but instead added another "Quick" tab sheet to the dialog.

The original GUI was named "Advanced" tab sheet (as seen in the first picture).
A problem was that this Quick page was not very intuitive either.
There were radiobuttons for options which is OK but then also 2 settings for LCL Interface, Target and IDE. They were never both enabled at the same time. So weird. If some Lazarus user really was so "non-advanced" that he needed this simplified page, how could he understand the difference between Target and IDE LCL Interfaces?

The worst problem however was that the Quick settings modified directly the Advanced settings, but there was no visual feedback about it. It took some time to realize it. A generally accepted GUI convention is that tabs have individual separate sheets. I remember I started using the Advanced page very soon although I was not an advanced user yet. I dare to say very few people used the Quick page.

Already a year ago I created a big patch implementing Build Profiles. It kind of extended the idea of quick selections and made it configurable. It also made the GUI more intuitive. In fact the sane GUI was my main motivation, the profiles were more like an extra bonus.
It was my first substantial patch for Lazarus and I had to study lots of code for it. At the same autumn I had started evening school (although I am not young). Now I can reveal that I made the Lazarus patch partly when I should have read to my math exam. Under pressure my mind goes into a hyper-active state or something. A psychologist could maybe explain it better. Anyway, I scored well in the math exam, too, no problem.

My feature got attention and mails were written but it was not accepted. Actually I created many versions of the GUI based on feedback.
The first version had everything at the same page in 2 panes, Profiles pane and Details pane. That was intuitive but big and crowded.
The second version had a clear list of profile names and a button that opened a details form for the selected profile. That is still my favourite. It is the most intuitive GUI for such things.
It was rejected because the (hard-)core developers want to use the settings as before. The dialog has to be "settings oriented", not "profile oriented". The third version (= the current dialog) follows that idea.

For a while the patch was forgotten but I salvaged it using a local git branch. Recently, finally, it was accepted to Lazarus trunk! After that it was changed some more based on feedback. Widgetset is now selected using a combobox instead of radiobuttons. Options have more room in a multi-line memo and there is a user-configurable list of defines to select from. Etc...
The latest (for now) version looks like this:

There is another dialog for managing the profiles:

I got positive feedback especially from people who cross-compile. The GUI is still complex but it is intuitive and very usable.

A more philosophical point can be made, too. GUIs should be designed and implemented by different people. As a mind-set, GUI design is more close to graphics design than to computer programming.
If no such designers are available, at least comments from outsiders (not Lazarus user) should be listened. I noticed myself that one gets used to confusing GUIs very quickly. A month or two passed and I didn't pay attention to it myself.
Open source projects with financial backing usually concentrate more on visual appearance. And commercial SW, too, of course, but sometimes they consider visual appearance more important than code quality which is not good either.

Juha

Delphi Converter improves

2010-09-27T11:05:00.016+02:00

Converter has taken a big step forward during the past few months. The main features I had in mind are now implemented. Most details are configurable in Settings dialog. All settings are saved in file delphiconverter.xml in local Lazarus configuration directory and thus are persistent.

This is the settings dialog:

There is a wiki page with detailed explanation of conversions: Delphi_Converter_in_Lazarus

Here is a brief list of them.

Conversions for Unit file

* All unit source files get a {$mode delphi} directive. It makes the compiler support language syntax exactly like Delphi has it.

* {$R *.DFM} is replaced with {$R *.lfm} if the form file is renamed and converted. Conditional compilation is used if the target is "Lazarus and Delphi".

* Unit names in Uses section and include file names are fixed to match the real case sensitive name found in the file system. This is needed for case sensitive file systems.

* Some unit names in Uses section are either replaced or removed.

* Some Delphi types are replaced with "fall-back" LCL types (same as in form files).

* Some function names called in the code are replaced.

Conversions for Form file

* Older Delphi versions used a binary format for .dfm form files. The converter always converts them to ascii text format.

* .dfm form file is renamed or copied to .lfm and converted as needed. There is also an option to use the same Delphi form file directly. See section Target below.

* Unknown properties are removed.

* Some Delphi types are replaced with "fall-back" LCL types (same as in unit files).

* Top and Left coordinate offset adjustment for controls inside visual containers.

Implementation details

Codetools are used a lot when changing the source code and .lfm form file.

One challenge was to replace function calls inside the source code, using parameters from the original call as defined in configuration. Codetools create a parse tree of the code but it includes only definitions, not function calls or other code constructs.
It means that the source code must be parsed char by char when looking for function calls to replace. Fortunately there was TFindDeclarationTool.FindReferences which I could use as the base for my TConvDelphiCodeTool.ReplaceFuncCalls. I copied the code, studied and debugged it for some time, then stripped useless parts out and added more code for replacing the function calls.

Another challenge was adjusting Top and Left coordinates of controls inside visual containers.
I based my TConvDelphiCodeTool.CheckTopOffsets on TStandardCodeTool.CheckLFM.
Again, I copied, studied, stripped, modified and added code.

The huge code-base of codetools looks first almost incomprehensible. The code browsing features of Lazarus are a big help here. They let you jump around code with no delays. After jumping and debugging for some time the code starts to make sense, piece by piece.

It is funny. When you first look at complicated code in a big project, you think: "oh, who is able create such code?". Then you make some code yourself and then have a month or 2 pause, and then look at the code and think: "oh, who has made this? Must be a clever person! ... oops, it is my own code...".
I guess other coders have similar feelings. Nobody can handle big amounts of code at one time. Sometimes you concentrate on the big picture and forget the details, sometimes you fiddle with the details and forget everything else.
In the end, for an outsider, the code may look like some intelligent person had made it. :-)

Juha Manninen

User defined color-schemes

2010-06-02T20:55:00.004+02:00

As the lazarus community grows people yearn for more customizations to please their personal habits.

To help creating a wider choice of readily available settings, user defined color schemes have been introduced.

So now, your community needs you.

Get the latest Lazarus snapshot, load your favourite color settings (or create the perfect scheme from scratch) and then make it available to all of us. All you need is press "Export", enter a Name and save it.
Upload it to your home page, or a place of your choice and link it on our wiki so everyone will find it.

Wiki page to link to your scheme(s): wiki.lazarus.freepascal.org/UserSuppliedSchemeSettings
Documentation: wiki.lazarus.freepascal.org/IDE_Window:_Editor_Options_HighlightColors

"Page-Locking" or "multiply Editor-Windows (part 2)"

2010-04-22T14:56:00.007+02:00

Following up the article about "Using multiply Editor-Windows", let's look at some more advanced scenarios.

You may want to use two editors, so that one shows you the interface of your class, while in the second you can work on the implementation of it.

The only thing is, once you have carefully positioned the first editor, you must always make sure, that you don't move it by accident. If it gets focus and you trigger a jump-to-implementation (or a jump to history/bookmark in this file), it will move away from your chosen location and you have to re-position it again.

This is where page-locking comes in. You can tell Lazarus, that it shouldn't move this editor away from your chosen location. The context menu has an entry "Lock Page" which will toggle the lock for the page. If the page is locked the entry in the context menu has a checked mark, and the editor tab will show an "#" in front of the file-name. (The command can also be assigned to the keyboard.)

Once your page is locked, Lazarus will no longer move it to other locations. You can still go to the editor and use the cursor keys or page up/down to reposition it. But if you try to jump between interface and implementation, go to declaration, bookmarks, etc, the IDE will automatically change to the other editor showing this file and move the other editor to the location you want to see.

So now in the example with the class declaration in one window, you can choose any method declaration of the class in the fixed window, and then trigger a jump to it's implementation. And it will always end you up in the 2nd window, in which you want to edit the code.

But what if you are in the 2nd window and jump back to the interface of your class? You don't need to have both windows showing the same code. By default Lazarus will recognize that your first (locked) window, already displays the interface. And the IDE will take you back to this first window.
Lazarus offers you some settings, to change this behaviour, if you like a different behaviour. (See Options / Editor / Multi Window)

And what happens if you accidentally lock an editor that has no 2nd view of the file? or you lock all editors of a given file? If that happens, Lazarus will open a new editor in a new tab (in an existing or even in a new window) for you. And if you don't like that, you can change the options so lazarus will ignore the locks, if this case arises.

Using multiply Editor-Windows

2010-04-20T15:36:00.016+02:00

During development a programmer encounters many different tasks. Some of them require you to work locally on the implementation of a single method. Code completion and hints can provide you with anything you need to know about other methods or objects that you access.

Other work requires you to frequently work on many different places in your code. Refactoring is a good example:

Comparing different methods side by side to find duplication.
Extracting functionality and moving it to a new location. Viewing both locations at the same time.
Changing the interface of your class, viewing interface and implementation next to each other

Multiply Windows

Lazarus can now open as many Source-Editor-Windows as you want, and you can freely move files between them.

Each Window offers you the same functionality as the current Source-Editor-Window. Each window can hold one or more files, accessible through editor-tabs.

You can move a file by using the context menu and selecting "Move to new Window".
Once you have more than one Window open, you can also choose "Move to other Window".

Or you can drag and drop the editor tabs between the windows. If you prefer using the keyboard, you can assign your own key-shortcuts.

If you often have a window with just one tab open, you may find it helpful to hide the tab header and get more space for the editor. An option to do so can be found on the misc editor options.

Editing the same file in multiply Windows.

Sometimes it is not enough to view two different units side by side. Sometimes you need to see different parts of the same unit.

Lazarus can do that too. You can open as many editors for the same file as you want.

Choose "Copy to new Window" from the context menu. Or once you have several windows open drag and drop while pressing the CTRL key.

How it works:

Lazarus will keep one single instance of the file open. This instance is shared by all the editors that you opened for this file.
If you type in one editor, the changes are always made in all open editors at the same time.

Actions like saving or reverting your code always act on the file. It does not matter in which of the opened editors you trigger them, they will affect all the editors that display the file.

Other actions are done per editor. For example you can select a different block of text in each editor, and the selection(s) will be kept while you can edit the text in an other editor.

Limitations

Lazarus only allows you one copy of a file per window. You can not have two tabs with the same file in the same Window. But you can open as many windows as you like, each having one copy of the file.

Undo information is combined for all editors of a file.
For example: Modify a file in one editor, then do further modifications in another editor. Now go back to the first editor. If you press undo in the first editor, it will first undo the changes of the other editor, before undoing the changes you applied in this editor.

This is necessary to avoid conflicts. If you had inserted text in the first editor and then deleted this text in the 2nd editor, it would be impossible for the first editor to undo the insert, because the inserted text is no longer there.

A word about adding more windows to Lazarus.

Many people feel that the Lazarus IDE already has to many Windows, and efforts should be made to reduce the amount. So why adding even more Windows?

Very simple. Using multiply Windows did offer the highest amount of flexibility for now. Having to implement all this with splitters inside a single window would have added serious amounts of extra work or more likely cut-backs on the flexibility of this feature.

Once Lazarus will have docking, the Source-Editor-Windows will benefit from this as well.
On top of that there is of course room to think about specific optimizations, such as splitting a single tab, for two views of the same file. When and if this will be done, remains to be seen.

Delphi Converter

2010-04-15T15:29:00.017+02:00

The converter has improved during past few months. The main focus has been in Delphi project conversion. Delphi package conversion should get most of the same improvements automatically but it is not tested much.

I think Delphi converter is a very important piece of Lazarus because new people coming from Delphi often want to try it. They get their first impression of Lazarus from it.
When I started to learn Lazarus last year, it was one of the first things to test. Then it failed to convert most projects. Its quality was not equal to the rest of Lazarus.

On February 2010 I got write access to SVN trunk converter directory. I made the converter code more object oriented. Using object member variables instead of function parameters made it easier to extend the code later. I refactored the code heavily, actually more than really necessary, partly to organize it better and partly to learn what it does.

The initial dialog shows there are three possible targets for the conversion:
* "Lazarus/LCL" -- One way conversion.
* "Lazarus/LCL for Windows only" -- Does not remove or convert windows specific unit names.
* "Both Lazarus/LCL and Delphi" -- Tries to maintain the code compatible with both Delphi and Lazarus using conditional compilation.

Source file conversion

Initially the main goal was to reduce messageboxes and other notifications. Converting a big Delphi project was not realistic because there were so many messages. Now useless questions are removed and notifications go to IDE messagewindow.

Earlier it was possible to comment out not-found unit names in USES section. Now that is extended. The user can either comment them out or search for a unit path during conversion. If the units are found, their path is added to project settings. If user chooses to comment them out, the same units are then commented automatically in following source files.

Used unit names can also be replaced by other unit names. Regular expression syntax for replacement is supported.

Form file conversion

The other big part of conversion is the DFM form file conversion. Some properties of Delphi components do not exist in the equivalent LCL components. They can be deleted, either automatically or interactively.
A bigger problem are Delphi components which don't exist in LCL at all. It is important to replace them with a "fall-back" LCL component, especially if they are containers and have more components inside them.
Now the components can be replaced and regular expression syntax is supported, just like for unit name replacement.

Issues

The converter is not ready yet. These are some issues and problems I must solve.

Replacement names for both units and components are hard-coded. Soon they will be stored in a XML configuration file and the user can edit them.

A complex codetools function CheckLFM is used for scanning the form file. It stops working when there are errors in source. There are often errors in a unit under conversion so this is a problem.
I must study and fix the codetools functions or even replace them with something.

Replacing a component with a "fall-back" LCL component leads to more unknown properties. It must be solved somehow.

Juha

Work on 0.9.30: changes in resource handling

2010-02-12T09:28:00.008+01:00

One of the big changes we have in the svn trunk (you'll get it with the 0.9.30 release) is the modified resource subsystem. Since the first time I tried Lazarus I felt a big displeasure regards the resource handling. I believe you had similar feeling too if you are an old Delphi developer. The main problem was that each lfm stream (Lazarus form) must be duplicated in a .lrs file which is included in unit initialization section. What is bad in this?

First of all lrs needs to be stored with your project and therefore eats the free space.
The second bad thing is initialization section - a special routine which is called on your program start. Thus your application will run 200 routines at the start if you have 200 forms. Not very nice if you care about the speed.
And the last is the amount of memory required for resources and how this memory is allocated. Lrs resources are stored both in the code of your executable (which loads on start) and a TList. Thus each resource is stored twice. Moreover when you add a new resource TList code needs to reallocate the memory used for all resources it has (look at TList.Grow).

All these problems are perfectly solved by the native resource support which is finally implemented by FPC 2.4.0 Starting from 2.4.0 release of FPC it is possible to include a form resource using the {$R *.lfm} (or {$R *.dfm} if you want to include a Delphi form resource) directive. Of course we don't need to store lrs file anymore, we don't initialization section and each resource is stored once in some section of your executable.

Since this way of resource handling is more effective we decided to use it by default in Lazarus. Of course we don't deprecate or remove in anyway lrs support. You are able to choose how to store the form resources in the project options dialog.

Warning: FPC 2.4.0 has 2 small bugs which are already fixed in the svn trunk (revisions 14805 and 14824). It opens all the resource files during linking and if you have small ulimit value you may see a linker error. To workaround the problem set ulimit to a bigger value. The second problem is that your project can't contain special symbols (like spaces) in the path.

Another rework we've made regards resources are the xp manifest, version info and project icon handling. Previously we created up to 5 files to add those resources to an executable: lrs file with an icon resource, rc file which included in turn manifest, version info and project icon files. So you had a whole zoo in the project directory. Now you have only a res and an icon files. We are building the res files ourself using the new FP package fcl-res. This mean also that we don't need finally to use windres. Res file is now used for all platforms while previosly rc was used for windows only and lrs for other platforms.

Warning: you need to remove {$ifdef windows}{$R you_project.rc}{$endif} from your lpr file manually (if you have it there). Maybe we'll implement a way to detect and remove that automatically before the release.

I want to summarize what advantages we have with the new resource support:

Less garbage in the project directory and smaller size.
Smaller and faster executables (because of no initialization sections).
Less memory usage.
Unified resource handling on all platforms.

As as special bonus for component developers I can note a possibility to use one form resource for both Delphi and Lazarus which can be included by {$R *.dfm} :)

This is a resource handling revolution, isn't it?

Vote for Lazarus

2009-06-23T08:28:00.011+02:00

Thank you, people from the Lazarus community! For the first time of our project history Lazarus has been nominated for SourceForge's Community Choice Award in the category "Best Tool or Utility for Developers".

Grab your chance to let others know how much you like Lazarus by voting for Lazarus. Spread the news and don't forget to vote, this time to make us winners.

Changes with Button Glyphs

2009-05-13T05:20:00.010+02:00

If you ever worked with the Lazarus IDE under windows (or just compiled an LCL application for windows) you were probably sickened by the glyphs on the dialog buttons since it is not native for windows. But on linux all is vice versa - most of the buttons have glyphs (and for example gtk and qt suggest an appropriate API to query "stock" images for buttons with various actions like save, open, apply, cancel, ...).

Therefore I needed a solution which can satisfy both windows and linux users. I started from the TBitBtn class which represents a button control with an image inside it. What I have added is a new property "GlyphShowMode" with 4 states:

gsmAlways
gsmNever
gsmApplication
gsmSystem

It is clear what the gsmAlways and gsmNever states are for: gsmAlways - to show the glyph always and this is how it worked before, gsmNever - to show the glyph never. Well, you may ask: What do I need the gsmNever state for, if I can use a TButton instead?. And I would answer: TBitBtn is not just a button with an image. It also has a Kind property which is very useful to set the ModalResult and Caption of a button :) But let's return to the other modes. gsmSystem can be used to show glyph depending on current OS - on MS Windows glyph will not be shown and on other system it will. And the last mode which is also default for this property - gsmApplication. In this mode TBitBtn (well, not exactly TBitBtn but TButtonGlyph) will look at the Application object for its value.

So, you can control the visibility of all button glyphs using the Application object. How? There are 2 ways: at run time by changing the Application.ShowButtonGlyphs property or at design time by changing the same property for the TApplicationProperties component. TShowButtonGlyphs is an enumeration too with following elements similar to TGlyphShowMode:

sbgAlways
sbgNever
sbgSystem

The default value for the ShowButtonGlyphs property is sbgAlways and not sbgSystem as one may expect. The reason is compatibility with old applications. Developers don't like surprises after a development tool upgrade and the loss of images is not a nice surprise. Anyway, it is not difficult to change the behavior of your application.

One more thing - glyphs are always visible when you are designing your forms. The glyph visibility mode is applied to the controls only at run time (when you start your application).

And now with regards to the Lazarus IDE. After this change the IDE on windows does not show glyphs on buttons by default, but if you really liked them, you can ask IDE to return them. You need to open the IDE options dialog and select Desktop settings:

No updates on the 0.9.26 fixes branch

2009-04-21T19:50:00.005+02:00

I have decided to stop merging revisions from Lazarus trunk to the fixes_0_9_26 branch. There are two reasons:

The differences between trunk and the fixes branch have become too many, over a thounds revisions. It is difficult to oversee their relations and dependencies, so I cannot guarantee the quality of the fixes branch just by looking at the patches and revision logs.

I want to focus on the 0.9.28 release rather than maintaining 0.9.26.3 and working on a 0.9.26.4 release.

That said, it doesn't mean 0.9.28 is almost ready, a lot of work still needs to be done. The list of issues with that we want to fix before the 0.9.28 release contains about 50 items.

So, from now on nobody from the current Lazarus team maintains the 0.9.26.3 branch. If somebody from the community is using the Lazarus fixes branch on a daily basis and want to extend its life, then that is possible. The new maintainer would supply me a list of revisions to be merged and tests the fixes branch. I would do the actual merging and keep the snapshots of the fixes branch alive. If you are interested, you can contact me and we can work out the details.

fpsvnsync, thanks for your services

2009-03-26T09:48:00.005+01:00

Since March 2007, the Lazarus SVN repository has been mirrored on SourceForge. Mirroring it on SourceForge is nice, sometimes people have trouble reaching svn.freepascal.org. And the svn commits count for the SourceForge ranking. Because SourceForge did not allow changing the revprops like author and date, I could not use the official tool called svnsync to create such a mirror. I submitted a tracker item at SourceForge to allow changing revprops, but two years nothing happened. So I wrote a watered down version of svnsync which would do almost the same as svnsync and named it fpsvnsync.

Last week I browsed the SourceForge site status and found an announcement about enabling revprops. This is good news, fpsvnsync does it job, but it needs both trees checked out and it is not as efficient as svnsync itself, because it starts a svn process several times for each changed file.

Last Monday I made a svndump of the Lazarus repository to get all those names and dates (which fpsvnsync cannot / could not set correctly) right. For your information, is a 700 MB file after bzip2-ing. I imported it on SourceForge using the svn migration page. Then I had a surprise when started svnsync init:

svnsync init https://lazarus.svn.sourceforge.net/svnroot/lazarus \
http://svn.freepascal.org/svn/lazarus
svnsync: Cannot initialize a repository with content in it

It only works on empty repositories. Three hours of import wasted.

So I imported an empty repository and called svn init on that repository. Using svnsync sync would be an option to make the mirror up to date, but importing more than 19000 revision this way didn't seem to be a wise choice. So I imported the 700 MB dump again, but without clearing the existing one. But still the svnsync utility didn't want to work. I had to set the svn:sync-last-merged-rev property manually, svnsync keeps this revprop for its administrative puproses at revision 0:

svn propset svn:sync-last-merged-rev --revprop -r0 19091 \
https://lazarus.svn.sourceforge.net/svnroot/lazarus

I updated my crontab to call svnsync every three minutes and the Lazarus svn mirror at SourceForge has been updated nicely after.

Next Lazarus release: 0.9.26.2

2009-01-23T10:25:00.005+01:00

More than three months (and 1500 revisions) have passed since the latest Lazarus release, so it is time for a new release. Lazarus trunk has now gtk2 as default widget set on Linux and is not yet in a releasable state. Further, gtk2 on newer Linux distros, requires fpc 2.2.4, which has not been released yet. The first release candidate is expected in the coming week(s). So I don't expect the final fpc 2.2.4 release before March. Waiting for fpc 2.2.4 would mean waiting for the next Lazarus release till April or May.

Fortunately, selected revisions from trunk have been merged to the fixes 0.9.26 branch, which actually has become more than just fixes, also 'stable', finished features from 0.9.27 have been merged, such as the use frames and the project icon.

This release can been regarded as an experiment with time based releases. Trunk releases usually have been scheduled to follow a fpc release or some finished feature and bug fixes. The exact timing of such releases was hard to predict. I tried to keep the fixes 0.9.26 branch always in a releasable state, so for example the switch to gtk2 has not been merged, because that depends on a fpc release.

I think the challenge with this release is the testing. The fixes branch is (almost?) not used by the Lazarus developers and I doubt that Lazarus snapshot users use 0.9.26.1 snapshots as much 0.9.27 snapshots. I want to ask you to try these 0.9.26.1 snapshots and report any regressions compared to the 0.9.26 release.

If everything goes well, we have a 0.9.26.2 release next month. Keep an eye on the release plan.

New TPen properties

2008-11-19T02:42:00.001+01:00

1. What is a Pen?

You know we are using pens when we draw a line or a shape border on a graphic canvas. A Pen defines how our lines will look. It can be thick or thin, dotted or solid, color or black. So lets review what properties a pen can have?

First of all pens can be cosmetic and geometric. Cosmetic pens are always 1 pixel wide, while geometric pens can have any width. But width of geometric pens are defined in world units and thus depends on transforms (scaling, rotation, shear, reflection) applied to canvas. Operations with cosmetic pens are faster.

The next pen property is pattern. Different libraries suggest different sets of default patterns (dot, dash, dash dot, dash dot dot, etc). Some of them don't contain any predefined pattern but allow to set a custom pattern. All libraries allow to set a solid pen pattern (usually default pattern) and some of then an empty pattern (invisible :) ).

The next usual pen property is color. Every library allows to set any custom pen color.

Geometric pens usually allow to set the style of end caps and the style of the joins between lines. The end cap can be: Round, Square and Flat. Look at the picture - they are placed in this order. When end caps are round - last points are drawn round, when end caps are square - last points are drawn square. When end caps are flat - last points are not drawn at all.

The join style can be: Round, Bevel and Miter. Look at the picture - they area placed in the same order.

Lazarus is using different libraries and each of them has a different pen implementation. For example Carbon does not supports cosmetic pens. And gtk does not support flat end caps for geometric pens (a similar style exists - GDK_CAP_NOT_LAST but it behaves as GDK_BUTT for geometric pens).

2. What was added and how it behaves

Before 0.9.27 pens were the same in Delphi and Lazarus. Pens were (and are) implemented through TPen class and had the following properties: Color, Style, Width (which cannot be less than 1). In order to create a widgetset object, TPen used a call to the CreatePenIndirect winapi compatibility function.

Thus I looked at how winapi works with all those end caps, join styles, cosmetic/geomtric and found another function which can create all what I need - ExtCreatePen. So the first thing I've done was inclusion of ExtCreatePen into LCL. I tried different pens by assigning that function result to Canvas.Pen.Handle. ExtCreatePen allows to choose whether your pen be cosmetic or geomtric, set a predefined line style or use custom dashes, set a solid color or even any brush to draw a line, set end cap style and join style. Don't expect full winapi compatibility from LCL, if you try to use this function directly. Only solid colors are supported - thus you need to pass BS_SOLID for the brush style and hatch = 0.

Another winapi compatibility function I touched was GetObject. It returns a description for the given GDI object. I've extended it to return correct TLogPen if a pen was created by CreatePenIndirect and TExtLogPen if a pen was created by ExtCreatePen.

Next I touched the TPen class itself. I've added TPenEndCap, TPenJoinStlye enumerations and TPen.EndCap, TPen.JoinStyle properties. Also I've added TPen.Cosmetic property since TPen.Width cannot be less than 1 (in other case I would use Pen.Width = 0 as cosmetic). So if you set TPen.Width = 1 and TPen.Cosmetic = True - you'll get your cosmetic pen (this is set by default for newly created pens). In all other cases pens are geometric. Pen is always geometric if Pen.Width > 1 even if Pen.Cosmetic = True. I've also added TPen.SetPattern method to set user defined patterns. If Pen.Style = psPattern lines will be drawn with dashes defined in the pattern array (first number means dash length, second space length and so forth).

3. Limitations

As I wrote before, Carbon does not support cosmetic pens and Gtk has its own point of view about Flat end caps :) But is this all you need to keep in mind?

When I wrote my test application and launched it on Mac OS X I've found that anti aliasing is not always a good friend :) My dashes were invisible and the pen looked almost solid for all styles when its width was equal to one. To eliminate this defects I've added TCanvas.Antialiasing property and now we can control it (only on Carbon and Qt though).

4. Conclusion

Almost all pen capabilities you can find in different libraries are now present in the LCL TPen class. If you missed ExtCreatePen or GetObject winapi functions - you can use them now too. If you don't understand something or just need more info then read msdn (ExtCreatePen), Qt help (QPen class reference) and Gtk reference manual (Graphics Contexts). If you want to look at TPen extensions yourself then launch our "Pen and Brush" example (I was inspired by a Qt Basic Drawing example when wrote it).

Compressed HTML help (CHM) in Freepascal

2008-11-18T16:29:00.003+01:00

What are CHM files?

CHM files are html archives that are compressed using the LZX compression algorithm.

The Idea

In early 2000 something, there was a discussion about Lazarus and making the help system better. Many different ideas were thrown around but the one that caught my eye was CHM, to me it made sense.

So I began to search for a way to make Lazarus help available as CHM files. The Freepascal documentation: the Run Time Library(RTL), Free Component Library(FCL) and the Lazarus Documentation Lazarus Component Library(LCL) were and are, all available in html format either to download as a zip file or from a website for browsing. This was good because CHM's are just html files in a special archive so in theory it's easy to make CHM's from the existing HTML files.

A bunch of History

I used the MS HTML Help Workshop to make some CHM's from the existing html files. This worked just fine but already I was seeing a problem: CHM readers only exist for Windows.

I found a library, libchm, which was capable of reading and decompressing CHM files. I started working with that and in not too long I was able to extract any file from within a CHM file and display it. This was wonderful but still it was not a perfect solution since Lazarus, if it provided a CHM help system, would rely on an uncommon library.

So I searched using google for an explanation of the CHM file format and found a very detailed specification. http://www.speakeasy.org/~russotto/chm/
The real work began. I converted the LZX decompression code in chmlib from C to Pascal. At first it did not work, but with the help of Micha Nelissen I corrected the mistakes from the conversion and that was finished.

Next came the part which required actual understanding of the innermost workings of a CHM archive. This is when I realized that reading CHM files was not just one file to understand but many. I'll explain: We already know that a CHM file is an archive that contains compressed HTML documents, but how do we know which HTLM documents are included and where they are, or how big they are? CHM's have a document index which uses a tree structure to store information about the directory and files within. After some time I was able to read this structure and see a list of all files and directories in CHM's. Subsequently I realized that a CHM has files stored within it that are added when it is made, which contain information about the Table of Contents, Index, which file is the “Home page” of the CHM and many other disinteresting but important things. Understanding a CHM involves understanding these internal files of a chm.

The specification I referred to above had all the information I needed about reading a CHM's contents but not how to understand these other internal files. Google to the rescue. I found another website http://www.nongnu.org/chmspec/latest/ that had information about the internal files! Not much later I was able to open, extract, and show correctly chm files. All without any external library dependencies.

I was very pleased but the CHMs made by the MS HTML Workshop did not have a very helpful Table of Contents or Index. Additionally there was some discomfort on the part of Lazarus developers that the documentation could only be compiled on Windows PC's since many of the Lazarus developers only used Linux.

This is why several months later, I began work on a CHM compiler! During a two week period I converted more C code to Pascal so a LZX compressor existed for pascal, and wrote from scratch several units to write CHM files.

Now it is possible to write and read CHM's files. The code is included with Freepascal in the packages/chm folder. Also fpdoc the Freepascal documentation tool incorporates the ability to write CHM files.

A program was made (LHelp) and a package made for Lazarus to integrate CHM help. It did not gain popularity however. Why? I'm not sure but it could be because people didn't know it was there. It required setting up in the Lazarus which may have been too compilicated for some. But regardless two years go by.

Recent Progress

I had recently been distracted away from Lazarus development by life and not paying much attention to it's progress. Then an email on the mailinglist caught my eye. A Freepascal dev, Marco van de Voort, was working on integration CHM help into the FP ide. I immediately started reading the logs to find out what interest had been shown in CHM's.

So in the last few weeks I implemented something I had wanted to but as yet, not been motivated to do: I implemented creating and reading the search index CHM's can contain.

What does this mean? This means that now it is possible to author searchable CHM files in any os/platform that FreePascal supports and also read them, all with Pascal code and with no external library requirements.

In the not too distant future, Lazarus may by default use these CHM files to display help when you need it.

Lazarus cross platform and cross widget set example

2008-09-30T15:34:00.000+02:00

Today I read a news item on the Lazarus site about a SI_Browser, a simple DICOM viewer. I didn't know what DICOM was, but google led me to the wikipedia article about it.

At the bottom of the site, I found a familiar link about the MRIcron DICOM viewer. I knew MRIcron is built using Lazarus; Chris Rorden, the developer, has made and paid several successful bounties to support MRIcron and Lazarus.

The actual reason I write this post, is the installation page of MRIcron. MRIcron is a Lazarus application that really shows the strength of Lazarus cross platfrom and widget set support. Chris offers MRIcron in 8 differenent flavours:

Windows (WinAPI widgetset)
Linux

32-bit (QT widgetset)
32-bit (GTK1 widgetset)
32-bit (GTK2 widgetset)
64-bit (GTK1 widgetset)
64-bit (GTK2 widgetset)

Macintosh OSX

OSX 10.4 or later (Universal binary, Carbon widgetset)
OSX 10.3 or earlier (PowerPC, GTK1 widgetset)

Chris, thanks for showing the power of Lazarus.

Lazarus 0.9.26 tagged

2008-09-25T15:39:00.002+02:00

Today I tagged the 0.9.26 version of Lazarus. In the coming week we will do the release building, some testing and preparing the announcement.

Lazarus svn trunk now contains version 0.9.27 and there is a new fixes_0_9_26 branch with 0.9.26.1.

SVN and the bug tracker: a powerful team

2008-08-21T10:58:00.008+02:00

This morning an issue was reported that using the win32 widget set,"RadioButton changes its state (becomes checked) when selected with Tab key". I could reproduce the issue easily and I remember that I had seen some code in the win32callback.inc file that sets the radiobuttons explictly using the BM_SETCHECK message. In Lazarus, I used Find in files searching in the lcl\interfaces\win32 directory, I found the piece of code rapidly, the WM_SETFOCUS handler around line 2084. The next step was to use svn annotate on the file, which returns the file with a note in which revision the lastest change has been made and by who. Then the patch and the log message are just a mouse click away:

moved checking of radiobutton to wm_setfocus, so keyboard action is handled too (issue 1171)

Now, resolving this report is easy. Either closing it as won't fix: it is as designed or revert the change of revision 8017. The hard part is to decide what is the best behavior.

Without using SVN or bugtracker, all this would depend on people's memory. I would not have remembered it after almost 3 years. The most important lesson for me, is that it showed how vital it is to put the issue number in the svn log message, otherwise you loose the track from change in source to bug report.

Lazarus 0.9.26 release preparation

2008-08-20T09:08:00.005+02:00

The list of open issues for Lazarus 0.9.26 is getting smaller by the day. Most are fixed. Some are re-targeted to 0.9.28, if we estimate it takes too long fix them now. Some are re-targeted to 1.0.0, if closer inspection turns out the bug is not a regression.

Some issue are in the status feedback. This means that the Lazarus developers are waiting for information from the issue reporters to be able to fix the issue or for confirmation that the bug already has been fixed in the meantime. I'd like to ask people who have submitted bug to check their reports and give the necessary feedback.

Translators are requested to check the translations for new or modified strings, so we can release Lazarus with up to date translations.

FPC 2.2.2 released

2008-08-18T00:55:00.000+02:00

FPC 2.2.2 has been released. In the coming time we will focus on fixing the regressions in Lazarus 0.9.25 and release 0.9.26. There are still about 15 issues to be fixed.

If you don't want to have nasty surprises, when Lazarus 0.9.26 is released, grab one of the snapshots and test it.

Amazing features in 0.9.26

2008-06-25T16:57:00.003+02:00

I don't remeber any release which excited me so much like the not yet finished 0.9.26. The reason is that many great features which were once a distant dream are now ready from becoming reality. I will describe some of them bellow.

* Windows Unicode support, even in Windows 9x. This is a very strong feature, which will take Lazarus much closer to having full Unicode support in all our supported platforms, something indispensable for any modern GUI Library. This allows us to show in the same application Russian, Portuguese and Chinese, for example, regardless of the Windows locale. Having Windows 9x support with the help of some testers puts us ahead of many other GUI Toolkits that dropped Windows 9x. Extended information for users can be found here.

* Native Mac OS X version with the Carbon widgetset. Yes, no more X11, no more Gtk under Mac OS X. A native IDE instead, which can be launched form the Dock and integrates nicely into the system. Copy+Paste, Debugging, everything works in the new Mac IDE. I expect this to boost Lazarus popularity under Mac OS X. In the long term a Cocoa interface is being developed, but the Carbon IDE should be more the enough in the next 1-2 years.

* TIcon.Handle finally working. This is also a long awaited feature, and should help removing some necessary ifdefs when using TTrayIcon, which needs TIcon.Handle to work.

* A much better Windows CE interface. Lazarus 0.9.24 was the first release supporting Windows CE, but many bugs were present at the time, making it somewhat problematic to develop real applications. In Lazarus 0.9.25 we have made a great work polishing the Windows CE interface, and this new release will push it to a new level, making it ready for the development of high quality applications. For some screenshots and extended information of the work being done, take a look here

* Tons of bugfixes

The final feature, which would make Lazarus finally ready for 1.0 (just my opinion! I know others disagree) is unfortunately not in this list. It would be the retirement of the Gtk 1 widgetset, and the move to a fully unicode and modern Linux Toolkit. I have worked a lot in the Gtk 2 widgetset, trying to get it to a development level where it could substitute Gtk 1, but I got really frustrated, partly because of the low quality of the mixed gtk1/gtk2 interface code, but also because Gtk just doesn't help. Having worked with the Windows API, Qt, fpGUI, Cocoa and Gtk, I am absolutely sure that Gtk is the worse GUI toolkit I have ever seen. Yes, even worse then direct Windows API, because at least the Windows API works!

The final shot in Gtk 2 for me was the fact that the Qt 4 interface, which I started 2 years ago just to learn how the LCL worked inside, managed to become much more reliable then the Gtk 2 interface which was already being developed a long time before, and without the support of most core developers! (Paul is the only core developer doing heavy development in Qt). Unfortunately Qt is not LGPL, and we expect to support the development of proprietary applications without the need to buy licenses, so Qt cannot substitute Gtk =/ At the moment I believe that fpGUI is the widgetset with the highest changes to substitute Gtk 1. The highest obstacles are the lack of developers and fpGUI being still under development, which makes it's API not so stable, but I really believe this path may have a great future.

A small comparison of the development difficulty in each widgetset:
Implementing TTrayIcon under Windows API: 4 hours
Implementing TTrayIcon under Qt: 3 hours
Implementing TTrayIcon under Gtk 2: 2 *weeks*

Concluding, I had originally planned for 2 posts, 1 about the great new stuff in 0.9.26 and 1 ranting about Gtk, but I managed to cover both topics here =D In conclusion I think we are reaching a new milestone, a new development level, but our official Linux interface (gtk 1) is unfortunately limited and we have no good enough substitute yet.

FPC 2.2.2 RC1 released

2008-06-19T19:03:00.006+02:00

The first release candidate of FPC 2.2.2 has been released. The Lazarus team is waiting for the release of FPC 2.2.2, because it needs it for the Unicode support for the win32 widget set. We intend to release Lazarus 0.9.26 soon after FPC 2.2.2 has been released.

People who want to test this release candidate with Lazarus, can download a Lazarus snapshot. The last week have replaced all fpc 2.2.0 based snapshots with fpc 2.2.2rc1 based snapshots.

Don't wait too long with testing, because 30 June will start the code freeze in preparation of the RC2. Hopefully this is the final release candidate for FPC 2.2.2, so we can have a FPC release before the end of July. Another release candidate will delay the release about a month. So test well, and report any regressions before the end of June.

New 0.9.26 features. Part 2. ImageList effects

2008-05-14T13:15:00.000+02:00

I think that almost nobody knows that internally the LCL TCustomImageList contains an array of 32 bit (rgb + alpha) data. In this array the imagelist stores images in the best quality. When it is needed the imagelist use this array to create a widget set imagelist (at this moment this is only the case for the win32 widget set) with the best possible quality. Any time we can access the 32 bit image data and we can do any manipulation with it. If you ever worked with image data you should know that 32 bit data is one the easiest formats for manipulations.

But what manipulations do applications (controls) usually need? The most often used manipulation is the transform from multi-color to gray image. It is used for example in menus and bitbtns (a button with an image). The next two often used manipulations are image highlighting and shadowing, which are also used in menus and buttons.

So I added TCustomImageList.Draw(... ADrawEffect: TGraphicsDrawEffect) and TCustomImageList.GetBitmap(... AEffect: TGraphicsDrawEffect).

At this picture you can see all effects currently supported by the imagelist. And this is the description:

Normal - no effect. You get an original image without any transform.
Disabled - gray image. Red = Green = Blue. We get every component value by the following formula: (Red + Green + Blue) / 3.
Highlighted - a bit shining image. To achieve shining we alphablend the original image with white.
Shadowed - opposite of highlighted. To achieve shadowing we alphablend the original image with black.
1Bit - this effect is used for drawing bitbtn glyphs in windows applications with no theme support. Windows just cannot draw gray images - they can use only 3 colors on a button: clBtnFace (transparent), clBtnShadow and clBtnHighlight. To support disabled bitmap drawing on such buttons we have added this special effect. We are using a special formula to achieve sharp edges in order to save all image details.

Currently every bitbtn and menu use these methods to draw their glyphs. When you disable them , the gdeDisabled effect is used, when you move a mouse pointer over a control, gdeHighlight is used and when you press a control gdeShadowed is used.
Of course, these imagelist methods can be useful not only for menus and buttons - you can use them for your own controls and other needs too. And we hope you will do that. :-)

GTK2 planned not before Lazarus 1.2?

2008-02-10T15:25:00.000+01:00

Sometimes people ask: Why don't the Lazarus developers want to fix the gtk2 bug before Lazarus 1.0?

The Lazarus developers have limited resources, so in order to have Lazarus 1.0 sooner rather than later, some decisions were made to reduce the work load (scope) for Lazarus 1.0. Some of this is mentioned on the wiki.

Basically, this means we think that no new features are needed for Lazarus 1.0. That doesn't mean that there will be no new features until then, but that we won't delay the release of Lazarus 1.0 because of it.

The gtk2 interface could be regarded as a feature too, because in most cases the gtk1 interface works just fine or better (except it looks dated). I must admit it is getting more troublesome recently, because some distroes now ship with gtk2 only. Currently the gtk widgetset is more stable and has less bugs with Lazarus than gtk2. Until that situation has changed gtk1 will remain the default. As soon as gtk2 is better (i.e. less bugs and more stable) than gtk1, it will come the default. But this is no priority for the Lazarus team, it rather focuses on other bugs.

Fortunately Lazarus is open source and with your contributions you can steer the path of Lazarus. For example Andrew Haines and Ales Katona understood that and have contributed a lot of gtk2 patches, trying to improve the gtk2 widgetset, so that it become the default for Lazarus 1.0. If a couple of other people start helping, I have no doubt that Lazarus 1.0 will eventually be with gtk2.

New 0.9.26 features. Part 1. SendMessage and PostMessage

2008-02-10T15:00:00.000+01:00

If you ever wrote some big application or component, I am sure you met the problem of postponed execution of some code. Delphi programmers usually used 2 solutions: timers and Windows message system abilities. This article is about message system approach. Note that Lazarus has a third solution: Application.QueueAsyncCall.

I suppose you already know something about the Windows message system. And you are familiar with SendMessage and PostMessage commands. They are used to deliver messages to controls. SendMessage sends message dirrectly to control window procedure. PostMessage adds message to the message queue, so control will get it only after processing all other pending messages.

Group of message numbers from 0 to WM_USER are used by Windows itself. So if you want to use message system in personal purpose you should use message numbers >= WM_USER.

Lets return to Lazarus where you want to indirectly perform some actions. Very usual task is when you need to destroy some control (your form for example) in event handler. Ofcource your application crash if you call Free in event handler - so you need to call Free somehow after event handler. But how? Call PostMessage in event handler and process posted message in message handler.

Delphi example:


const
  MY_MESSAGE = WM_USER + 1; // <-- your message number  
type 
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);  // <-- some event handler
  private
    procedure MyMsgHandler(var Message: TMessage); message MY_MESSAGE; // <-- message  handler
  end;  

...   

procedure TForm1.Button1Click(Sender: TObject);
begin
  ...  //code before
  PostMessage(Handle, MY_MESSAGE, 1, 0);  // <-- here you post message to message queue
  ...  // code after 
end;   

procedure TForm1.MyMsgHandler(var Message: TMessage);
begin
  Free;
end;

If you used similar constructions in Delphi, you should know that they did not work in Lazarus. In the win32 widgetset code all WM_USER messages were blocked for some reasons:
- other widgetsets had no support for PostMessage and SendMessage
- few WM_USER messages were used by Windows and cause errors in LCL

After releasing 0.9.24 we reevaluated our decision since gtk and qt supported PostMessage and SendMessage. Then an implementation for Carbon appeared. Of course it would be a joke to block messages under Windows when all other widgetsets (where messages are aliens) support them. Now you can use PostMessage and SendMessage with few limitations:
- use Message numbers >= LM_USER
- sending messages outside application does not work (you cannot send message to another application)

And the last - if you need example - look at lazarus\examples\messages.

Lazarus fixes branch

2007-12-28T11:03:00.000+01:00

While working on Lazarus 0.9.23, which took more than 6 months, Giuliano Colla proposed to create a stable branch. Lazarus development goes very rapid with about 100 commits each week and with each daily update, there is a reasonable chance that something got broken. This is not desirable for people that need to do production work with Lazarus.

The idea was welcomed, although I had some doubts about the feasibility, especially the man power needed. Lazarus development goes rapid and there is still a lot to do, so the current Lazarus developers can better spend their time on new development than on maintaining a stable branch. So, we offered Giuliano to maintain it him self and we would support him.

After the Lazarus 0.9.24 release in November, I created the fixes_0_9_24 branch and set the version number to 0.9.24.1. Windows snapshots using fpc 2.2.0 and the fixes branch are created on a daily basis from ftp. Giuliano would send me a list of revision numbers to be merged and I would apply thoses merges to the fixes branch. After a couple of merges, the branch became 'super'-stable, because there were no changes. A lot of changes are related and Giuliano wanted to test them before applying. This takes a lot of time. Also, it is sometimes not trivial to see the dependencies between the different revisions, espescially if a revisions contains new functionality, that you don't want to merge and a simple fix that is needed when you want to merge a later bug fix revision.

So we are still struggling to find a good strategy for maintaining the fixes branch. In the last week, I took a different approach. I looked at the list of revisions and merged the new component bar images, splash screen and most the bug fixes I made in Lazarus 0.9.25. Almost 200 revisions were merged from trunk to the fixes branch, so things might have been broken, but I have good hopes that 0.9.24.1 is at least as good as 0.9.24.

There are still about 500 revisions in trunk not (yet) merged:

Documentation hints
Handle rewrite
New project options and environment options dialog
A number of bug fixes for other widget sets than win32 (my only expertise).
Improvements to images in the toolbar of the IDE
Several improvements to the Lazarus IDE dialogs

Because it is hard to guess what people want in the fixes branch (except stability), we want to ask users of the fixes branch to indicate what they want to be merged from trunk. If we think the feature is stable already, we will try to merge it.

I encourage everybody to test the fixes branch and give feedback on the Lazarus mailing lists. If the fixes branch proves succesfull (stable updates without occassional breakage), I am considering to put snapshots of it in the Lazarus-Testing Ubuntu repository.

Lazarus 0.9.24 tagged

2007-11-05T20:00:00.000+01:00

This afternoon I tagged Lazarus 0.9.24. The coming days we will build all the windows installers, rpms, debs and dmgs for the suported OS-es and CPU's.

As part of the release testing, I created an ubuntu lazarus-testing repository at http://www.hu.freepascal.org/lazarus/dists/lazarus-testing/. Currently it still contains Lazarus 0.9.22 and FPC 2.0.4, but as soon as the Lazarus 0.9.24 and debs are ready they will be put there, until the Lazarus 0.9.24 release can be announced. After the announcement, they will be available in the lazarus-stable repository too. For more information about how to get debs from the Lazarus testing repostitory, see the wiki.

Please, let us know if you have problems using the testing repository and during the upgrade from 0.9.22 to 0.9.24.

New poll on the lazarus site about Windows versions

2007-10-29T22:01:00.000+01:00

Lately I have been trying to fix recompiling the Lazarus (needed to install components) from the IDE. On windows 2000 and higher, using .rc files is working OK if windres is not on the path, but on windows 98 there are still some problems.

Marc has done a large graphic rewrite in Lazarus 0.9.23 and he also noticed that there are noticeable difference between Windows 98 and Windows XP.

I wondered if there still many people using Windows 98 and Windows ME for Lazarus development or as target for LCL application. Therefore I created a new poll on the Lazarus website, asking people about the oldest Windows version is, that they use for Lazarus development.

Currently when we program on the win32 interface we try to use only functions available in windows 95, or provide a fall back if we want to use a function not available on windows 95. Some features like graphics, Unicode support, the shell provided by cmd32.exe and the availability of console (used for the debugger) are better and easier in Windows 2000 and later. So it would be nice if we could restrict ourselves to these newer Windows versions.

Personally, I don't think we can drop support for windows 98 yet, but I doubt anybody is using Windows 95 to program with Lazarus. Let us know where you stand and cast your votes in the poll. This poll is about the OS you use for Lazarus, a future poll may be held about the Windows versions you want your developed applications to run on.

Note: people who don't use Lazarus on Windows, don't need to vote.

How TPageControl tab switching in designer has been solved

2007-10-28T16:37:00.000+01:00

I think most users who used TPageControl in windows ide suffered from the inability to stitch its Tabs by clicking them in the designer. Indeed, the gtk ide had no such bug while the windows one had. I got annoyed by the fact too and as result I started my research of the problem.

My first assumption was that somewhere a csDesigning (you know that usual "if csDesigning in BlaBla.ComponentState" ;) ) condition was written and I spent much time (searching code) to prove myself that I am wrong.

Ok, if I am wrong (I thought) then it is by design or by the designer :) So I started my research of how the win32 designer works. Usually my research consists of Alt+F7 in Far manager for some search key (in this case for 'designer') and if Alt+F7 doesn't help, then in debugging the code. I suppose on that occasion I had been satisfied by search in files. First of all I found 'TWin32WidgetSet.GetDesignerDC' method and later I've checked that this method is indeed what I searched for. Look at TDesigner.DrawDesignerItems and you'll find that yourself.

So, I've known the enemy by sight :) If you notice GetDesignerDC creates a visually transparent window over WindowHandle and returns the Device Context for that overlay window. The Device Context is not a interesting thing for us, but the overlay window is. That overlay window is placed on top of a form (and all child controls). And the most interesting thing in that overlay window is the window procedure OverlayWindowProc.

Inside OverlayWindowProc we can find that overlay window easts all messages except WM_KEYFIRST..WM_KEYLAST, WM_MOUSEFIRST..WM_MOUSELAST and that bunch of messages it redirects to the parent (look at Windows.GetParent(Window)). If you look at TDesigner.DrawDesignerItems then you'll know that the Parent of OverlayWindow is the Form. So nothing wondering now that the PageControl Tabs cannot be switched in designer - PageControl gets no clicks (they are caught by our overlay window).

Hmm ... I thought about a solution. The first thing that flashed through my mind was sending those mouse clicks to the underlying control. But it is so easy to forget about some messages or make other errors if you want to emulate windows behaviour. So I rejected that way as defective. Another way is to make some parts of our overlay window transparent for mouse. Windows has a special message WM_NCHITTEST to check what a given coordinate means. And a window can return HTTRANSPARENT as result of a message to indicate that message must be sent to the underlying window (so this point is transparent for the window).

As result the whole solution consisted of handling WM_NCHITTEST in OverlayWindowProc and return HTTRANSPARENT if underlying control wanted mouse messages for that point at design time. I've added a new method GetDesignInteractive to TWSWinControl.

class function GetDesignInteractive(const AWinControl: TWinControl; AClientPos: TPoint): Boolean;

Now I had a method to check, but of course I needed the implementation of that method for TPageControl (which checked that mouse is over control Tabs). So I've added TWin32WSCustomNotebook.GetDesignInteractive, rebuilt the win32 ide and hurray - I switched PageControl tabs in designer w/o problems.

You can look at implementation in revisions: 12245, 12620 (method has been renamed).

Fight for Synedit speed under qt widgetset

2007-09-29T20:05:00.000+02:00

One or two weeks ago our qt-ide was almost fine (if form designer was not taken into account) except one important detail - the speed of the unit editor. Yes, you were able to edit source, but the speed .... it was deadly slow. You could type a key and wait second or two before that key was printed in editor. So we started the fight for speed.

The core of the unit editor is the Synedit component. Lazarus uses an early version of Synedit but it is heavily changed for our needs (adopted, extended). Synedit is a TCustomControl, so it does all its painting and event handling itself. When I looked at the source for the first time, I found nothing criminal. A well done component which repaints only changed areas.

I tried to find out what piece of code makes the component so slow under qt. And I found that it is the qt QPainter.DrawText method. My first assumption was that in the OnPaint event we were repainting the whole Synedit, not only the changed area.

I checked how invalidateRect was done and there was no error - QWidget.Update(Rect) was called. My next assumption was that we were ignoring that Rect in the OnPaint event, but no - we did clip the paint area by that rect. What was it - a mystery?

I checked how clipping worked and found, that in DrawText the clipping was gone. The reason was in Synedit - it used double buffered painting and as result DrawText performed on a non clipped bitmap instead of a clipped window. Revision 12175 changed things. There was no more bitmap, but painting was still as slow as before.

My next assumption was that qt doesn't check the clipping region before DrawText. And bingo - manual check of clipping rect before DrawText gave us no bad speed (revision 12183). But cpu usage was very big in spite of the achieved speed. So something was still wrong, but what?

Zeljan noticed that caret eats too much cpu time. It was because of a not optimal use of timer and widget repainting. After fixing those things in revisions 12198-12200 there was not so high cpu rate as before.

I was already happy but Zeljan was at his best and found one more speed killer. That was our ExtTextOut implementation. ExtTextOut have 2 arguments related to text: Str - the text and Count - count of chars. We made the assumption that Pascal components pass Str arguments that are already trimmed to count chars, but this was not true (at least for Synedit). There were cases where count was equal to 1, but Length of Str equal to 300 (or 400 chars). After an appropriate patch (revisions 12201,12205)the speed of Synedit has become really fast.

Now qt-ide as fast as it should be.

The Lazarus 0.9.24 release date

2007-09-21T13:03:00.000+02:00

One of the best held secrets in the Lazarus community is the release date of Lazarus 0.9.24. Sometimes people ask when the next Lazarus release will be. The only correct answer is: "When it is finished". And even the Lazarus developers don't know when that is.

Fortunately, we have a criterium for finished. We want our next release as good as the previous one, so things that work in 0.9.22, must work in 0.9.24 too. If soemthing stops working and it is found out by people using the snapshots, we ask create a bug report for it in the Lazarus bug tracker. Such regressions are marked with "LazTarget 0.9.24". On the view issues page, you can filter on those issues. The list of 0.9.24 issues is currently 23 long, most them are already assigned to some developer. The list also contains patches contributed by Lazarus users, we want to include in the next release. Currently the list is too long to give a reliable estimate of the next Lazarus release date.

In the final stages before a release and during the release preparation we use the Detailed todo page on the wiki as a kind of check list.

You might wonder if nothing is happening on the Lazarus front. The truth is, that very much has been done since 0.9.22. Almost 200 bugs have been fixed (see Changelog in the bug tracker) in Lazarus 0.9.23 and more than 1300 svn commits have been made. You can track the svn commits to the Lazarus svn repository though rss or at the Lazarus page at CIA.vc.

Lazarus snapshot are using fpc 2.2.0

2007-09-20T12:03:00.000+02:00

In the last couple of days I have made changes to the build servers and the mirrors. All snapshots that were using fpc 2.0.4 are now using fpc 2.2.0.

The next Lazarus release (version 0.9.24) will be based on fpc 2.2.0 too, so these snapshots give a good preview of the next release. At his moment there are still about 20 bugs open that need to be fixed before the release, so there is still plenty time for testing Lazarus 0.9.23. Download it from one of the snapshot mirrors:

Reviewing a patch for the chart component

2007-09-18T11:30:00.000+02:00

The chart component in Lazarus was written two years ago by Philippe Martinole for his TeleAuto project. He submitted the component to the Lazarus Code and Component Repository. Later Luis Rodrigues extended it and made it more Delphi compatible. The component was considered stable and useful enough to add it to the default installation of Lazarus. Luis Rodrigues now is the main maintainer of the component.

A couple of weeks ago Luis submitted a patch for the chart component. Because I don't know the inner workings of the chart components and don't have a test program, I usually do two things:

Do a visual inspection of the patch to see if it contains sensible things.
Check if the patched version compiles on under windows, my main development OS.

People submitting these patch are major users of the component, so I assume they are better testers than I possibly can be.

This particular patch contained the following code to fix clipping:

      //set cliping region so we don't draw outsite
-     Rgn := CreateRectRgn(XImageMin, YImageMax, XImageMax, YImageMin);
+     p[0].x := XImageMin;
+     p[0].y := YImageMax;
+     p[1].x := XImageMax;
+     p[1].y := YImageMin;
+
+     {$IFDEF windows}
+     LPtoDP(Canvas.Handle, p, 2);
+     {$ENDIF}
+     Rgn := CreateRectRgn(p[0].x, p[0].y, p[1].x, p[1].y);
    SelectClipRgn (Canvas.Handle, Rgn);

I don't know how clipping works and what LPtoDP exactly does, but having a {$IFDEF} here in the middle of a procedure, doesn't look like good portable code. There seemed to be some inconstencies between the CreateRectRgn functions for win32 widgetset and the gtk widgetset: one expects logical points and the other device points.

Even if we wanted to use a {$IFDEF} the current one is probably not correct. The difference is not the OS, but the used widget set, so using {$IFDEF LCLwin32} would have been better. Remember, that the qt and the gtk2 widget can be compiled on windows too.

I asked Luis to find a better solution and maybe some people on the mailing list could help (unfortunately I had no clue how to fix this properly). Luis found another way without IFDEFS:

      //set cliping region so we don't draw outsite
-     Rgn := CreateRectRgn(XImageMin, YImageMax, XImageMax, YImageMin);
-     SelectClipRgn (Canvas.Handle, Rgn);
+     IntersectClipRect(Canvas.Handle, XImageMin, YImageMax, XImageMax, YImageMin);

This patch I happily applied after I tested the compilation.

Vanishing snapshots

2007-09-17T12:28:00.000+02:00

From time to time, the Lazarus snapshots at Scenergy disapear. It is probably happens when two build servers upload a new version at the same time. The update process has roughly the following steps:

Delete the files currently in the temp location
Copy current files from the ftp-directory to a temp location.
Remove old snapshot
Add new snapshot
Rsync the temp location to the ftp-directory

The temp location is the same directory for each upload. Now if one build server is at step 4 and a second build server starts at step 1, the rsync job will finish quickly with no files to copy ...

For normal snapshots this is not a big problem, they will be regenerated within 24 hours. But occasionally I upload a wince cross-installer too and that doesn't get updated automatically yet. So until this issue has been fixed (probably by adding some locking and using different temp locations), I have put the latest wince snapshot at sourceforge, in the Lazarus Testing package.

Some stats

2007-09-01T00:04:00.000+02:00

Two weeks ago I setup an ubuntu deb repository for Lazarus releases. I wondered how much they were used and asked the server admin to install webalizer on the server (it's name is Scenergy). In these two weeks, the repository generated 15 GB trafic and the i386 archicture is still favorite.

Scenergy is also one of the Lazarus snapshot servers. So I added the ftp stats too. In August this server served 50 GB of snapshots. The same ftp server has fpc releases too and the fpc 2.0.4 windows installer causes 43% of trafic: 128 GB. Interesting figures ...

Qt IDE

2007-08-31T15:46:00.000+02:00

Not long (about 2-3 months) ago my attention was drawn to the lazarus Qt widgetset (child of Den - author of the bindings and Felipe - author of the lazarus widgetset). It is easy for me to develop the Qt widgetset, since I can run the Qt enviroment on my main platform - windows xp. Another developer - Zeljan (with qt on linux) worked hard on qt widgetset at that moment. My goal was to achieve a working Qt ide. Zeljan had another goal (as I know). He had a real application and tested the qt widgetset on that.

Step by step and day by day we fixed bugs and implemented missing features (of course, what else can we do?) :) There were problems with mouse, keyboard, painting, widget sizes and positions and so on (you can look at the changelog for more details). As far as I can see my goal is achieved now. Yes, ide is mostly functional: you can edit units, you can use form designer, you can play with lazarus dialogs (really I don't know what you can't do).

But please dont expect too much - the ide still has bugs. Some of them are known and fixing them is in progress (form designer has no rubber band, some controls have wrong size until parent resize, tool windows have no close button), but some are not known. So we need testers.

We'll have lazarus-qt snapshots soon. Stay tuned.

Fixing Lazarus compilation with fpc 2.2.0

2007-08-30T16:54:00.000+02:00

Last night FPC 2.2.0 was tagged. This means that the source code for the release is frozen, no more changes can be made. Now the release builders can start their job and create Windows installers, Linux rpms and debs and Mac OS X dmgs with installer packages. When they have finished their jobs, the FPC team will announce their release, probably in two weeks or so.

I am glad we have reached this point; the last critical bugs for Lazarus were fixed almost a month ago, all the Lazarus snapshots using fpc 2.1.5 were compiling fine and there had not been any reports about failures with fpc 2.1.5. So I was very surprised to get an email this morning from the debian builder, that Lazarus trunk could not be compiled with fpc 2.2.0.

Compiling memcheck.pasmemcheck.pas(211,17)
Error: Identifier not found "pptruint"memcheck.pas(211,17)
Error: Error in type definitionmemcheck.pas(222,33)
Error: Illegal qualifier memcheck.pas(1110,22)

The memcheck unit is a copy of the heaptrc unit from the RTL with some extras. Because there were no problems with fpc 2.1.5, I suspected it contained something like {$IFDEF VER2_1} which should be extended to version 2.2 too. But the source was clean of such version dependent ifdefs. I started to doubt if the snapshot were built with fpc 2.1.5 after all, the only difference between fpc 2.1.5 from yesterday and fpc 2.2.0 is the version number.

Then I got a idea, and looked in the build unit for the codetools allcodetoolunits.pp. It contained the following lines:

uses
 {$IF defined(VER2_2) or defined(VER2_3)}
 MemCheck,
 {$ENDIF}

We changed this to:

uses
 {$IFDEF VER2_3}
 MemCheck,
 {$ENDIF}

and now Lazarus is fpc 2.2.0 ready.

The memcheak unit depends on the heap manager and besides the use of unsigned integers the fpc 2.3 heap manager has some improvements for multithreaded programs, which make it incompatible with the fpc 2.2 heap manager.

Let's start the blogging

2007-08-29T12:46:00.000+02:00

Theo suggested to start a blog to give people some insight in the development process of Lazarus. A bit of tips and tricks on improving Lazarus.

So I opened an account at blogger and created this blog. Let's see if I have something to tell.

I am still a bit sceptical about its use, but having a blogspot makes the threshold to write something down easier. The future will tell, if this was a good idea or not.