OPCB – Object Pascal Component Builder Library

[fabianoallex]

I’m developing OPCB – Object Pascal Component Builder, an open-source project for Lazarus And Delphi.
It simplifies the creation of visual and non-visual components at runtime, without needing .lfm or .dfm files.

I’m currently working on documentation and examples — feedback and suggestions are very welcome.

🔗 https://github.com/fabianoallex/opcb-object-pascal-component-builder

[Handoko]

Hello fabianoallex,
Welcome to the forum.

Nice idea!
Thank you for sharing it.

I downloaded and tested the examples, unfortunately it requires Windows unit but I'm a Linux user. With the discontinue support of Windows 10, more users will start to use Linux. It would be good if OPCB can remove Windows unit requirement so it can be run on Linux too.

[fabianoallex]

Thanks for the feedback, Handoko. I haven’t tested it on Linux yet. I’ll look into the feasibility, it would indeed be very interesting to have it running on Linux.

[wp]

It would be good if OPCB can remove Windows unit requirement so it can be run on Linux too.

I did not study the code but in my experience the "windows" unit can be replaced by "LCLIntf, LCLType" in most cases. Also, if there is a "messages" unit, replace it by "LMessages". These little changes are often sufficient for having a cross-platform component. (Of course, if you still want to use the component in Delphi you must place these changes into an {$IFDEF FPC}...{$ELSE}...{$ENDIF} directive.

[fabianoallex]

All the examples in Lazarus have been adjusted and now it compiles on Linux as well. Thank you.

[n7800]

Code: Pascal  [Select][+][-]

1.     Creator
2.       .WithOwnerAndParent(Self, Self)
3.       .SetTopLeft(20, 20)
4.       .SetSpace(5, 5)
5.       .SetDirection(cpdVertical)
6.       .GridInit(4, 6)
7.         .GridSetCellWidthAndHeight(70, 70)
8.         .GridSetColWidth(0, 200)
9.         .GridSetRowHeight(1, 150

I'm curious how the FPC compiler implements method chains. Can they lead to stack overflows?

[Leledumbo]

Why do I feel too familiar with the concept? Hahaha, good ol' method chaining. jQuery users will love it, as well as SwiftUI users.

[Thaddy]

It is a KOL like concept, so I like it!

[fabianoallex]

Code: Pascal  [Select][+][-]

1.     Creator
2.       .WithOwnerAndParent(Self, Self)
3.       .SetTopLeft(20, 20)
4.       .SetSpace(5, 5)
5.       .SetDirection(cpdVertical)
6.       .GridInit(4, 6)
7.         .GridSetCellWidthAndHeight(70, 70)
8.         .GridSetColWidth(0, 200)
9.         .GridSetRowHeight(1, 150

I'm curious how the FPC compiler implements method chains. Can they lead to stack overflows?

I've only used it in tests so far, and in my tests I haven't had any stack overflow issues. I believe that in the vast majority of scenarios there won't be any problems. But if you think the chaining is too long, just break it down into smaller parts.

[fabianoallex]

Someone sent me a direct message asking which tool I use for documentation, but I can’t reply because of my recent registration on the forum.

"You are not allowed to send personal messages."

To answer: I just use Markdown (https://markdownlivepreview.com/
) and review it with ChatGPT.
You just need to ask ChatGPT to generate the content inside a Markdown code block, otherwise you’ll get formatted HTML text.

[Khrys]

Code: Pascal  [Select][+][-]

1.     Creator
2.       .WithOwnerAndParent(Self, Self)
3.       .SetTopLeft(20, 20)
4.       .SetSpace(5, 5)
5.       .SetDirection(cpdVertical)
6.       .GridInit(4, 6)
7.         .GridSetCellWidthAndHeight(70, 70)
8.         .GridSetColWidth(0, 200)
9.         .GridSetRowHeight(1, 150

I'm curious how the FPC compiler implements method chains. Can they lead to stack overflows?

Method chains like this aren't anything special. They only require that each function return  Self:

Code: Pascal  [Select][+][-]

1. function TFoo.Chainable(): TFoo;
2. begin
3.   DoSomething();
4.   Result := Self;
5. end;

The result of the previous call then becomes the hidden  Self  parameter for the next call, meaning that no nesting is needed:

Code: Pascal  [Select][+][-]

1. // Desugared method calls with explicit `Self` parameter
2. Self := SetTopLeft(Self, 20, 20);
3. Self := SetSpace(Self, 5, 5);
4. Self := SetDirection(Self, cpdVertical);

[cpicanco]

Hi fabianoallex, do you have plans for including documentation about opcb development? (For example, do you have consistent ontology? Is there any difference between With... vs Set.. functions?)

Also, may you elaborate why avoiding .lfm files is a feature for your usecases?

[fabianoallex]

Hi fabianoallex, do you have plans for including documentation about opcb development? (For example, do you have consistent ontology? Is there any difference between With... vs Set.. functions?)

Also, may you elaborate why avoiding .lfm files is a feature for your usecases?

Yes, my goal is to improve the documentation and examples.

In general, the “With” prefix is used in Builder classes, indicating that the object will be created with certain settings. The “Set” prefix, on the other hand, is used when changing properties of an already existing object.

For example, in the Creator, there is a method called WithOwnerAndParent, which indicates that objects added via .Add will be instantiated with the Owner and Parent passed as parameters. Meanwhile, SetDirection modifies the internal Direction property of the Creator, which is used to determine the direction of the next components to be created.

It’s possible that some methods were named with less appropriate prefixes, and this might be refined in a future review.

As for avoiding the use of .lfm files, this is mainly a project design decision. However, there are practical advantages to not relying on those files, such as:
 - Better compatibility across different IDEs (Lazarus/Delphi or between different Delphi versions).
 - Support for dynamic UI generation (runtime customizable interfaces).
 - Fewer conflicts in version control systems.
 - Improved portability.
 - Easier UI testing.

These benefits may vary depending on the context, but the main purpose of the library is to provide an additional option, not to impose a restriction.

The use of the library does not mean that the entire project must abandon the use of .lfm (or .dfm) files.
It is perfectly possible to combine the traditional approach with specific functionalities where you might want more flexibility to create components or controls at runtime.

[etrusco]

I'm curious how the FPC compiler implements method chains. Can they lead to stack overflows?

Quick answer: in practice, no. Theorically, yes, it could, if you had millions of chained method invocations and compiler optimization is off ;-)
In a normal user application (contratry to low-level, kernel, driver, etc) stack size is usually huge and grow automatically, so stack overflows are in practice always caused by infinite recursion.

[cpicanco]

fabianoallex, have you tested your library with pas2js?

https://wiki.freepascal.org/pas2js