> >
> > > b) If you move an item to the top or the bottom of the list using
> > > the "go to top" and "go to bottom" button, the item looses focus
> >
> > yes, this is intended, but can be changed easily. The reason is
> simply, that
> > by moving an item to the top or bottom, you're normally done
> with your work
> > and select new columns anyway. Can be changed though
>
> Ok, but it can also be used like a "fast forward" and then refine
> the position.
>

O.K. Will be changed......Its not too hard anyway and so I'll go teh way of
least resistance

> >
> > > c) if you have item 1...9 and hide 2,3,4,5, if you then take the
> > > first item and click the down arrow to move it down, you have to
> > > click 6 times to have it move to the second position. It's like
> > > the code is stepping through the list without jumping the hidden
> > > (so not more present) elements of the visible columns.
> >
> > Yes, this is intended. I am moving the items through all fields
> order, not
> > all visible fields order. Doing the latter would have introduced some
> > complexity I did not have enough time to cope with. You can see
> the behavoir
> > at full work, if you move one column up while having several invisible
> > columns over it and set these columns visible again. I prefer
> this that way
> > but I think there is a possiblility to change the behavior in the future
>
> It's confusing... you don't know if you clicked the button or
> not, or what is happening. As a programmer, I can understand such
> behaviour, but a simple user will not.
>

I'll see If I can find some nice way to do it. Both ways are confusing. The
now present one will not move the fields, if there are invisible, and the
other one will move a field not only 1 position up, but could move it 4 or
10 positions up in one click.
Perhaps there is a way to combine both into it...

>
> The
> > default delphi splitter behavior (I am using a plain TSplitter
> here) has no
> > support for proportional splitting, so I would need to code it
> by hand, and
> > I don't see too much use for this right now...
>
> It's just making thing more useful
>

ANd requiring lots of coding. If anybody wants to, he's welcome.....perhaps
I can tinker around with anchors a bit....

> >
> > > e) I HATE flat buttons, they break one of the basic interface
> > > design principles, so I always set the bar Flat to false.
> > > Unfortunately, your window ignores this setup... ;)
> > >
> >
> > Ouch, you mean the flat buttons for moving the columns? Well,
> flat or not
> > flat is personal preference and not design principle and is not
> a subject of
> > discussion for me.
> > I like them, you not. Period.
>
> Ok, but IT IS A DESIGN PRINCIPLE. If you put somebody in fron of
> something that has the look of being pushable, he will try to
> push it. If flat, who can imagin that can be pressed? IE is one
> of the worse interface I've seen. You can't understand what
> button is active if you don't move the mouse on it, and you have
> to imagin that those stragne pictures are buttons and not
> decorative effects. Of course, you can learn it, but you can also
> leark WordStar key combinations...
> (have a look to www.cooper.com).
> But, of course, what Microsoft does, everybody likes...
>

Cooper is an authority, but not always right. Only god is always right, and
Cooper is not him.
Most people I know prefer flat, and none of my targeted users is confused by
flat, as any targeted user knows IE better than Netscape :-)
Lets take it really to preference, not design principle. A glyph itself
imposes enough hint to push it.

> >
> > > What about having some more property to customize? Like colors...
> >
> > What do you mean with this? You mean an interface for TIB_SessionProps?
> No, please, not. Just grid properties (fonts, selected color,
> etc.... but maybe it's a wrong idea, some user could make a mess
> of the grid :(
>

Don't forget: The restructure dialog work dataset-centric, and not
grid-centric. The dialog does not know anything of the grid. It only knows
the Datasource and its corresponding Dataset. I can only change
Dataset-Properties, not grid ones. THe grid is only adapting the changes as
they happen :-)

> > I think this should be fairly simple provided I can find a nice
> colorpicker
> > which is Public Domain (and NOT Freeware) to inlcude the units
> directly into
> > IBO, and not to require third-party stuff to be installed along
> with IBO.
> >
> > > add a PageControl... but ask Jason first. What I would like to
> > > have, and is a general consideration, is a component that can
> > > save forms (I mean, components, grids, etc.) state to a blob
> > > field of a table with form_name+user_id fields, so every time a
> > > user reopens the form, the values he used the last time are
> > > presented back (very useful for forms asking parameters...).
> >
> > I use TFormStorage from RXLib to save that stuff into the
> registry....I do
> > not want to bloat the Database with such stuff. I have Formstorages in
> > Datamodules with a custom onRestorePlacement and
> onSavePlacement handler,
> > where all Queries on a Datamodule are looped through and the properties
> > FieldsIndex, FieldsVisible, OrderingItemNo and
> FieldsDisplayWidth are saved
> > and restored. Works like a charm, and RXLib is free....
> > When I create a form in any kind of app, the first thing I do
> is to drop the
> > TFormPlacement onto it, and set the registry-key. Saving
> formposition, size
> > and all kinds of properties gathered trhough RTTI is such a
> nice thing, I
> > would NEVER try to code this stuff myself. Use what's already there, and
> > RXLIb is definitely a must-be to consider for every
> delphi-installation :-)
>
> Ok, but I don't like put things in registry. If you reinstall
> Windows, you loose your setup. But thanks for the suggestion. I
> will have a look at Rx components, and adapt them to IBO
> properties and definitions :: I think it will a good starting
> point (btw, si RxLib still alive? Their site is... something
> different now! http://www.rxlib.com/)
>

Formstorage works both, with the registry and with Ini-Files. I prefer
registry, other prefer ini-files. Again, a matter of preference.

Cu, Nick