[Lazarus] LCL improvement idea

Max Vlasov max.vlasov at gmail.com
Tue Jan 18 14:35:44 CET 2011


On Tue, Jan 18, 2011 at 4:02 PM, <michael.vancanneyt at wisa.be> wrote:

>
>
> On Tue, 18 Jan 2011, Max Vlasov wrote:
>
>  On Tue, Jan 18, 2011 at 2:11 PM, <michael.vancanneyt at wisa.be> wrote:
>>
>>
>>>
>>>  Hmm, Michael, I understand you here, but I think that the main drawback
>>>
>>>> about application-wide (so possibly run-time only) is about losing
>>>> design-time magic. For example when you have 10 panels, go change some
>>>> ...
>>>>
>>>
>>> The whole point is to avoid having to do the same task all over again.
>>> Remember, a typical app of mine has more than 1000 forms.
>>>
>>> ...
>>>
>>>
>> Ok, now I see, your initial idea is really simple and working, the one I
>> suggested maybe needs a little more thinking about worth it or not
>> implementing. I know it can work, but for the time being looks a little
>> bit
>> too complex
>>
>> For yours I have something in mind. Is it possible to create something
>> similar to TApplicationEvents (in terms of accessing special places in the
>> LCL) and this component that will introduce an event
>>
>> TOnCreateComponent: procedure (Sender: TObject; Component: TComponent) of
>> object;
>>
>> I could then create a global object that sets this handler.
> This should be implemented in TReader or in TComponent.AfterCreate, so I
> can do it myself in the classes unit if necessary.
>
> There is only one drawback in this system: it will be called for all
> created
> components. This means that there will be a huge If/then/else, and that
> there is only 1 handler possible.
>
> My system will be significantly faster, and is easily controllable on a
> per-component basis.
>
>
>
As for the speed, I think you're more familiar with internals than me so
you'd better decide yourself :)

just two things about events that I like a little more:

Just to clarify, did I understand the logic behind your objects correctly,
should they self-register somewhere from their create's?

- If objects are self-created, the context of the changes is hidden. It's
sometimes very hard to remember why this particular object looks differently
to what one saw in the desiginer. Calling some self-registered objects from
deep within LCL is just hidding this changes far from the developer.

- Sometimes when one have options to implement or not to implement a
brand-new object (TLabelDefaults in your example), it depends on the value
of this. So when I have some exotic component I probably will use twice or
third times, making additional "else if" is sometimes easier than
implementing a new object, even if I understand that the latter is more
effective.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110118/01fa9fa5/attachment-0003.html>


More information about the Lazarus mailing list