[Lazarus] Library internals and interface based data aware controls

[Juha Manninen]

Hi,

I have learned more about Lazarus / FPC by porting some Delphi code. It seems 
to be very usable now, I am impressed. I must admit I considered it as a 
hopeless project some years ago when I first noticed it. Not any more...

But first a minor complaint. I often get errors like:
  Error: Illegal type conversion: "ShortString" to "^Char"
or
  Error: Call by var for arg no. 2 has to match exactly: Got "AnsiString" 
expected "ShortString"

if I don't add
  {$MODE DELPHI}
into a source file. However, I don't explicitly define any short strings. The 
default objfpc mode illogically thinks a "string" as function parameter is 
short string but other "string"s are dynamic ansistrings (or something like 
that).
The language has evolved and short string is mostly a historical remain. 
I would suggest that MODE DELPHI is made default in Lazarus or then FPC's MODE 
OBJFPC is fixed.

---

Then some thoughts about library internals:

It seems that LCL is designed internally better than Delphi's VCL even though 
they have similar components.
For example in Delphi I had a small helper function:
  procedure EnableAndBold(aButton: TButton; aEnabled: Boolean);
which enables/disables a button and sets its Font.Style accordingly.
I tried to use the same func for BitBtn but no, their properties are not 
inherited from the same ancestor and I had to make another almost identical 
function:
  procedure EnableAndBold(aButton: TBitBtn; aEnabled: Boolean);

However in LCL the properties are coming from the same ancestor so I could use 
a single function:
  procedure EnableAndBold(aButton: TCustomButton; aEnabled: Boolean);

The same thing seems to be true for some edit controls' properties.

Good!

---

Now a question about data aware controls:
Has there ever been an idea of making dataset components and data aware 
controls based on interface?

The program code for data aware controls in Delphi is quite ugly. Lots of 
copy-pasted code and ugly hacks. DataSource maybe tries to be kind of 
abstraction layer there but it doesn't help much.

I think Borland (or what is it nowadays?) would use interfaces for the task 
now. When they first implemented it there was no interface feature available. 
Database connectivity was revolutionary then but now it would need an update.

The current DB components (Dataset, DataSource and edit controls) are needed 
to support existing code base but there should be another well designed 
interface based component set.
What you say?


Regards,
Juha Manninen