I'm developing a sort of accounting app. For base tables (customers,
etc.) I've got the conclusion that I want some automation when dealing
with transactions/master details.
I've seen the Jason Lobbyist sample application and, even if I can't
make it work to my IB6 in dialect 3 due to some field named "YEAR",
I've got some ideas from it.
My conclusion, to make things going like I like is:
- the development of a substitute of IB_UpdateBar, named
IB_UpdateWorkBar
- the arrangement of a special database base form, from which inherit
my data entry forms.

This because I think that the normal job is (also in some of my
previous posts):
Have the main (master) dataset in search mode so the user can
a) find a record already entered to edit/delete
b) find if a certain record exists, and if not insert it
c) he knows that he has to insert a new record

At this point, for a) and b) he fills some fields and start the
search. In a) after post/cancel/delete he must be put back to the
"natural state", the search state.
For c) he presses the insert button, sets some fields, then presses
post or cancel. Natural state has to be reached again.

The base concepts are that:
a) the user has no clue about the distinction between post and commit
b) user's goal is having the work done, without technical struggling
c) the form must return to a "natural", "base" state, the better
starting point for usual data entry work.

So I've developed IB_UpdateWorkBar. IB_UpdateWorkBar is not a
masterpiece of code, since I've decided to write less code as
possible, so I've derived it from IB_UpdateBar with some "injection"
of IB_TransactionBar. The code is mine only because I've assembled,
tested and designed the component behaviour, but it's entirely based
upon IBO one. Like my IB_Currency component, everyone will be free of
use it under Jason license.

I will briefly describe here some basic concepts under it, in the hope
of having some feedback and suggestions. I'm in a hurry in advancing
with my "killer app" and terminate it before the end of the year, so
it's unlikely I will refine IB_UpdateWorkBar. But when released it
will be workable and useful, I hope.

So IB_UpdateWorkBar, if a transaction is assigned, will perform
PostAll+Commit for the Post button, and CancelAll+Rollback if the
cancel is pressed. If no transaction is assigned, it works like a
normal IB_UpdateBar against the assigned datasource.
IB_UpdateWorkBar will be linked to the main datasource, the master in
the case of a master-detail situation.
When the transaction is committed or rolledback, a AfterWorkDone event
is fired.

The form has a property where you add the datasource that are used by
the form, if they reside in a datamodule. If not assigned, the form
will use all the datasets that finds in the form itself.
Then "main" xxxbars will be linked to the first datasource or the one
the IB_SearchBar is linked to, if assigned.
All non-detail queries will be put in search mode, the detail opened.
When the form will be closed, all datasets will be closed too.
Thanks to IB_UpdateWorkBar.AfterWorkDone, the form will always return
in the "base" state, i.e. focus on the Form.ActiveControl, main
dataset in search mode.

What's your opinion? Suggestions?
Thanks
Marco Menardi