Helen, you are talking about a different situations/needs.
Put you have a *short list of records* to check Yes/No, or where put
some value, for a later (client) computation. These values are not to
be included in the uderlaying table, since is data that does not need
to be stored, just entered by the user for a particular job against
the items the user selects/the values the user enters. The computation
is mede after the user has worked for some time to the items, trying
the best solution (so you can't work on a record by record base).
With the actual IBO, you should have an array of values, sicronize the
array with the grid, have the value for the array entered in
different, unbound controls in a different place of the form. So bad
and difficoult! Even if you don't do editing in the grid, you have to
provide a syncronized array of values...
If IBO is allocating buffer space for the calculated fields, would be
wonderful having the possibility of define "Buffer fields" to work
with in these situations, don't you agree?
For instance, my actual problem: having a list of unpaied invoices.
The user must select the 'pay it' flag to pay the total amount, or
enter just the money he wants to pay. Now I had to add two more
columns to the table, and clear tha value after all the computation is
made. I must provide a different isolation level too, since the
columns could be changed by someone else in the middle of the work...
Even worse, this (adding work column to be edited) could not be
possible in situation where the dataset has aggregate values.
Maybe I'm missing something, maybe could be a relative easy and
powerfull enhancement of IBO :)

--- In IBObjects@y..., "Helen Borrie (TeamIBO)" <helebor@d...> wrote:
> 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