[Lazarus] nonlcl basic issue: is codetools LCL dependent?

Mattias Gaertner nc-gaertnma at netcologne.de
Sun Jun 22 15:06:45 CEST 2014


On Sun, 22 Jun 2014 12:13:02 +0200
Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:

>[...]
> > 2. The clean solution:
>[...]
> That's the way I'd like to go. A more general support of non-LCL 
> widgetsets would be a not only a good long term solution for my project, 
> which in my ambitions would be not just to support Kylix legacy but to 
> rewrite step by step all widgets thus getting free of license issues. 
> More important, it could be useful to the Lazarus project as a whole. It 
> could be used to revive the pretty much dead CustomDrawn project, it 
> could provide a better way to support FPGui, etc. It's quite likely that 
> in any widgetset one can conceive, a form will have a TForm class, a 
> button a TButton class, etc.

True.

 
> My problem, right now is: where do I start from? Which units should I 
> start looking at?
> 
> Currently, if I understand properly, everything is set up in main.pp. 
> Then, when loading a project, palette visual components without an 
> editor hook are only hidden, but nothing is removed from 
> LazarusResources.

LazarusResources is only about LCL resources, which is here the lfm
format and some utility functions for the dfm format. You don't need to
change that.
Other resources must be implemented in your designtime
package and registered via the IDEIntf unit UnitResources.
That was started by the iphonelaz package, which uses another format.

The IDE uses the TReader/TWriter of the FCL for streaming components.
For the IDE there are two types of component classes:

1. Root components are descendants from TForm, TDataModule, TFrame and
can hold user methods and variables. They are created completely from
scratch. That means a new class is created at runtime and an
instance. When the resource is read by TReader the IDE creates methods
and child components on the fly. Here the IDE needs to be extended to
handle multiple base classes with the same name.
The IDE needs a simple way to decide which TForm to use. A good
solution would be the resource file extension.

2. When TReader wants to create a child component 'Button1: TButton' it
needs a component class 'TButton'.
All component classes are registered via
RegisterComponents, which is in Classes and that
does not support duplicates. Maybe a RegisterComponents can be added
to the TUnitResourcefileFormat.

I have to write an example and check things to tell what exactly needs
to be changed.


Mattias




More information about the Lazarus mailing list