On Tue, Jan 18, 2011 at 4:02 PM, <[email protected]> wrote: > > > On Tue, 18 Jan 2011, Max Vlasov wrote: > > On Tue, Jan 18, 2011 at 2:11 PM, <[email protected]> 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
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
