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

[Mattias Gaertner]

On Sat, 21 Jun 2014 12:43:17 +0200
Giuliano Colla <giuliano.colla at fastwebnet.it> wrote:

> Hi Lazarus wizards and magicians,
> 
> I'm trying to figure how to face my nonlcl widgetset project.
> Before tampering with Lazarus code, I tried to gain a better understanding.
> My scenario:
> 
>   * a run-time package containing my non lcl widgets. Units are named
>     after Kylix naming scheme, i.e. QForms, QButtons, etc.
>   * a run-time package containing units lifted from Lazarus LCLBase and
>     LazUtils to provide the required run-time functionalities without
>     pulling in LCL (lresources, fileutils, etc.)

ok.

 
> With a minimal patch to lresources, in order to skip properties pulled 
> in by Lazarus and unsupported by my widgets, I can compile an 
> application using my widgets, run and debug it.
>
> If I try to access to a method already present in the lfm from the 
> Object Inspector, I can see the available methods, and jump to the unit 
> code.

Yes. In this case the IDE uses only the names to find the methods.


> But if I attempt to add something, such as an OnClick Event to a button 
> from the Object Inspector, I get the error "Unable to create new 
> method", and the reason given is:
> 
> Codetools, Errors:1
> unit1.pas Error: unit not found StdCtrls

The IDE searches the declaration of TButton.OnClick.
The TButton was registered from the LCL unit StdCtrls. That's why
TButton.UnitName is 'stdctrls'. The IDE searches the unit in the
project path and cannot find it.


> Of course my package doesn't have a StdCtrls unit, which would clash 
> with Lazarus, but has a QStdCtrls unit.
> Now my question is: where does Codetools find the need for a specific 
> unit? I gather that class, property, etc. names are loaded into the 
> global LazarusResources list, but this involves also unit names? In 
> order to support a nonlcl widgetset to what extent one should reinvent 
> Codetools in his Mediator?

Note: Codetools is a package for searching and editing Free
Pascal sources. You don't need to reinvent Codetools.
The problem is the IDE (i.e. form editor, designer) that drives
Codetools. The IDE needs to be extended to solve the name
clashes.

There are at least two possible solutions:

1. The quick and dirty solution:
You use the LCL forms and controls. The IDE is extended with some
hooks, so you can redirect from the LCL to your units.
Pro: Less work, you get some basic results quickly.
Con: The RTTI is wrong. The Object Inspector cannot show your
own properties. The property editors will show LCL values (e.g. TColor
will show the list of LCL color constants). Icon and bitmap data are
read/written in LCL format, which may be unreadable by your units. etc.

2. The clean solution:
You write your own mediator component classes. For example a
TButton, TForm, TPanel, TListBox, etc.
Con: the IDE needs to be extended to handle multiple component classes
with the same name (only one is active at a time, based on the project). You have to write painting code for the mediator TButton, TPanel,
TListBox, etc.
Pro: the RTTI is correct and so the Form/Source relation works, the
Object Inspector shows all your properties and only your properties and
you have full control. You can write good property and component
editors.


Mattias