On Thu, 14 Dec 2006 12:57:27 +0200
"George Birbilis" <[EMAIL PROTECTED]> wrote:
> > > >> 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).
Property editors are created for instances, not classes. For example
everytime you add a component to the multi selection, some property
editors vanish from the list and the others can change their attributes.
> That way the font property editor wouldn't have to
> be recreated since the OI would grab the same instance from the pool.
At the moment all property editors are fast created/destroyed, so no
need for a pool. BTW, it would be more efficient if the property editor
code creates a global pool itself for its data.
> 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)
In fact, the OI uses TPropertyGrids. They create the property editors.
And property editors are used by all RTTI controls and at other places
in the IDE.
>
> Btw, do I guess wrong that only one OI can be visible?
The IDE only uses one OI.
But of course the OI form can be created as many times, as you want.
Just create one TPropertyHook instance per OI.
> 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]
At least I have no plans to do that.
> 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?
No. It does not need yet such a pool, because the speed is ok and the
overhead of typinfo functions is still bigger than the
creation/destruction of property editors. So, before you start such a
generic pool, add a pool for typinfo functions.
>
> 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?
Yes, several. Depends on what you want to do.
Mattias
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
