> The "original" intention was to allow the developer to change
> the font colour.

> Perhaps 3 basic properties instead of a TFont would be
> sufficient:
> FontColour
> FontName
> FontSize

> and "maybe" style?

Its one of those issues - the one thing you dont include will
be the one thing that someone else wants. ;-)

What it really needs is some test or definite information about
exactly what impact the full TFont instance will incur.

So in that light I just did a very basic test demo. I placed
500 TIB_Edit controls with visible labels on a form. most were
not showing very much (I just let them sit where a copy/paste
sat them). But I figured this was an easy way to see how things
went.

The difference in executable memory consumption (using TaskMgr
on WinXP) was about 20k. That is; the new AutoLabels use about
20k more than the old - whether labels were visible or not.

For 500 controls I do not see this as significant (40 bytes per
control instance). So the existence of the TFont property does
not seem important (IMO).


HOWEVER, there was a performance hit when labels were visible!

When I open the dataset (using the TIB_DatasetBar) at runtime:
with the old AutoLabels, open took < 1 second to complete
with the new AutoLabels, open took > 10 seconds to complete

This was just measured with the second hand on the clock next
to my PC, so its not that accurate. But the scale of the
difference is definite.

I do see this as significant (500 controls on one form is not
likely, so its probably not hugely significant, but still
something worth investigating).

Since the performance hit was only when labels were visible
the implication is that this is not to do with the TFont object
but probably something to with how the label is updated.


Can I let you take it from here Mark? I dont do much VCL/IBO
stuff these days, so I cant really spend more time looking at
the issues.

--
Geoff Worboys
Telesis Computing