> -----Original Message-----
> From: Geoff Worboys [mailto:geoff@...]
> Sent: Domingo 11 de Marzo de 2001 8:19
>
> > Hi, I have to change programmatically display width of
> > a query column, but I can't understand the syntax!
> > It should be something like:
> > dmMain2.qryCustomers.FieldsDisplayWidth[ 'CUST_NAME' ] := 420;
>
> If the query is already prepared then you can do something like...
> Query.FieldByName('CUST_NAME').DisplayWidth := 420;

It works. At first glance I thought it won't work. Now, the ReadOnly case
is an exception to the rule, as Nick J. observed, because you can't affect
the TIB_StringList by changing TIB_Column.ReadOnly.

> Whether the query is prepared or not you can...
> Query.FieldsDisplayWidth.LinkValues['CUST_NAME'] := 420;

Probably you wanted to say:
Query.FieldsDisplayWidth.LinkValues['CUST_NAME'] :=
IntToStr(420);

or maybe even more paranoid, to check:

if Query.FieldsDisplayWidth.LinkIndex['CUST_NAME']
then
Query.FieldsDisplayWidth.LinkValues['CUST_NAME'] :=
IntToStr(420);

> You can find out more by looking at the online help for
> TIB_StringList.

When I studied with Champollion, he told me to tackle the help for
TIB_StringList as the ultimate challenge after understanding all Egyptian
signs.
:-)
I've made good progress since then. Maybe I will create my own derivative
class to handle my own ideas.

> > Second, since fields attributes are set at Dataset (i.e.
> > IB_Query) level, is the above the only way to have two
> > grids using the same dataset but with different widths
> > and displayed fields? Or there is a IB_Grid property
> > that overrides the ones set into IB_Query?

Yes, there's one, but nobody has seen it before today, I think.
:-)

> The only method I can think of would be to derive your own version of
> TIB_Grid and override the UpdateColumnAttributes procedure to do your
> own thing.

Consider the enhancement done. The method UpdateColumnAttributes is not the
only place to change, so IMHO overriding this vitual function is not enough.
I introduced the change in TIB_CustomGrid tonight. Otherwise, I had to
override UpdateColumnAttributes without calling the current implementation
and just inject two lines of code, do the same with DefineFieldMap and
again, the same with ColWidthsChanged. Too much hassle. Also, I thought more
than one person may benefit from the enhancement and it won't affect current
applications. Besides, Jason already did the politically correct act in
TIB_CustomGrid.ColumnMoved so GridLinks are adjusted when columns are
exchanged.

I've sent Jason the modifications. Geoff, if you don't like my idea, you
can... continue using your applications as before. <g> Here's the
explanation:
Until now, TIB_Dataset governs most of the settings that affect the
attached data controls. Some setting can be put higher, at the
TIB_Connection class, so all the application can benefit. Having global
settings (and even more, a repository for application/database settings,
probably in Jason's to-do list) is a godsend but in my view, thing should be
"overridable" at the most granular level, namely the controls themselves.
This personal view is also related to my complain about how the IBO
TIB_LookupCombo works, because I grew thinking one should separate the
logical from the GUI aspects as much as possible, regardless RAD
environments going in the other direction.
Do you remember GridLinks? Have you used it? Well, the traditional way of
hiding fields is to fill entries in the FieldsVisible property of the
dataset or connection objects. But sometimes we want independence in the
grid, so the grid got GridLinks. In IBO, TIB_CustomGrid is the ancestor of
TIB_Grid and TIB_LookupList but TIB_LookupCombo is a different beast. Don't
mark the field as invisible in the dataset or connection at the same time
you put it in the GridLinks property of the grid or you will get an empty
column. The global setting will win.
Until now, GridLinks was only a list of fields, one per row. But other
TIB_StringList-based properties use more capabilities of that TStringList
derivative. So, I expanded the syntax of GridLinks to become
fieldname=width
or
table.field=width
BUT THIS IS OPTIONAL. If you don't use it, your application will work
anyway. You can still write simply
fieldname
or
table.field
as before. The only difference is this: if the field is listed in GridLinks,
it will appear in the grid regardless FieldsVisible's settings in the
dataset or connection objects. I think this is more consistent, since more
detailed settings should override generic settings. You wish has been
granted, Marco, but you will see the capability when the Inquisition <g>
approves my code.

> > Where on hell are the examples in the help file? :))
>
> (Finding time for documentation would simply not be in keeping with
> the spirit of programming ;-)

Geoff, what else do you want, going back to DOS or CP/M? Writing one
million assembler code lines without any documentation?
:-)

I coded this change as a way to rest from the latest two (*censured words*)
weeks. If I have one more like those, I won't be visible in this list for 10
days more. Of course, other people have other ways to rest, but this is just
me. I wonder whether the computer is an extension mine or I became an
extension of the computer. Besides that (and this is for Freudian people
<g>) I enjoyed working in the grid since it's a control that I almost don't
know internally and there's an IngridLayout method whose 6 first characters
made me to remember some woman from the university. :-)

C.