[Lazarus] LCL improvement idea

michael.vancanneyt at wisa.be michael.vancanneyt at wisa.be
Tue Jan 18 15:53:16 CET 2011



On Tue, 18 Jan 2011, Max Vlasov wrote:

> 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.

Well, one system doesn't exclude the other. I will implement the event as
well. If the event is not set, then the speed will remain as it is now.

Question is, where to call the event ?
- In the streaming system ?
- In the TComponent.AfterCreate ?

The latter means that it is always called, even if you create components in
code, but then you have no context - (namely: which form is being loaded)

Michael.




More information about the Lazarus mailing list