> > >> 1) get list of available font names (this seems to > already be done > > >> by the TFont property editor used at the Object Inspector) > > > > > >Yes. This can be quite slow. > > > > I'll try to do it once at creation, instead of at each > update (I hope > > the Object Inspector doesn't recreate the property editors at each > > refresh, does it?), > > Not at every update, but frequently.
Shouldn't the OI keep a live pool of property editors then? (since they're created given a property classname [or was it class], not a certain instance). That way the font property editor wouldn't have to be recreated since the OI would grab the same instance from the pool. The pool would be only for the OI to use (are other tools in the IDE that might want to use property editors? Then that pool should be more generally accessible by the IDE code) Btw, do I guess wrong that only one OI can be visible? is there a requirement for many simultaneous views of the OI in the future? [say like how split window works in Word by dragging that small knob over the top arrow of the scrollbar - imagine being able to split the OI in two or more separately scrollable views] The pool could contain more than one prop editor of the same type if there's such need and used ones would be removed from the pool by the using code, then returned back to the pool when done (that's better than locking used itmes cause the pool size remains small for easier search - search only the free ones to use - plus if using code forgets to unlock would keep the pool big - instead if it forgets to return to pool not much harm done to the pool). Initially the pool would start up empty. When asked for items it would work like a class factory, allocate the prop editors asked for and return them. When using code is done using them, will (most probably) return'em back to the pool. The pool (a hashtable) would have a max buckets (how many types of prop editors it can keep) setting maybe and maybe also a max bucket size (how many live instances of the same prop editor it can keep) Or does it do already like above? The pool logic could be made generic (via some interface and/or ancestor class) to reuse at other places (say for reusing component editors [although that's a bit more risky since not-well written comp editors might need to destroy and recreate after setting another component instance to them to edit] etc.). Is some hashtable class available at Laz now? Cheers, George ---------------- George Birbilis ([EMAIL PROTECTED]) Computer & Informatics Engineer Microsoft MVP J# for 2004-2006 Borland "Spirit of Delphi" ++ QuickTime, Delphi, ActiveX, .NET components ++ http://www.kagi.com/birbilis ++ Robotics ++ http://www.mech.upatras.gr/~Robotics http://www.mech.upatras.gr/~robgroup _____ avast! Antivirus <http://www.avast.com> : Outbound message clean. Virus Database (VPS): 0657-0, 12/12/2006 Tested on: 14/12/2006 12:57:27 ?? avast! - copyright (c) 1988-2006 ALWIL Software. _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
