At 01:18 PM 28-01-02 +0000, Mirco wrote:

>Yes, 'normally' I would have tried to just do the calculation in a
>form and then do the work in edit boxes not directly bound to the
>dataset.
>However, this approach doesn't work when I want to edit in a
>TIB_Grid, because AFAIK you can only display columns of the dataset,
>not some additional 'custom' columns.

The following is my opinion, based solely upon my views about good and bad GUIs for client/server applications...

Here you encounter one more GOOD reason not to design editing GUIs that depend on in-grid editing. My editing apps display rows of "informative" columns from the dataset in a read-only grid and individual edit controls in a neat, clean editing panel to the right, all connected to the same datasource as the grid.

In the edit panel are all the user-editable fields in data-aware edit controls and all the non-editable ones (like COMPUTED BY columns, calculated fields, etc.) in TIB_Text controls. Included in the panel will be any TEdits or other non-data-aware controls into which the user might need to enter input that will be used for a calculation, e.g. enter a birthday and have the app calculate Birthdate...as well as lookupcombos, lookup lists, incremental search controls, etc.

The data in the panel scroll with the grid so, at all times, the current row's data is seen in one "eyeful" and can be edited on the spot. Even if you absolutely insist on letting the user browse 20,000 rows in the grid, s/he can race through the scroll by holding down the Next and Previous buttons on a TIB_Navigator...you can include a searchbar and/or other search controls.

I LIKE this as an editing interface, both to program and to use. It is easy to implement and intuitive to use. In-grid editing is for spreadsheets.


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at www.ibobjects.com