Jason, I think that what you suggest is really fine.
I would like to take some of your time to share with you all my
"vision" of data entry forms, because if you think that it's right you
will better address my needs, otherwise I ask you all to tell me the
right direction because I'm confused!
Well, I create the form and immediately put the dataset (or the master
dataset) in search mode. This way I've no traffic from the server
getting rows that I don't use. The focus is on the Form.ActiveControl,
if set. This is the "natural state" of the form, to which must return
after each operation.
So the user at this point should have these goals:
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.

If we are dealing with master-detail, the "natural state" is with
master in search while details are open (to prevent different grid and
ib_edit behaviour when the dataset is prepared instead of inactive.
After a close the dataset remains prepared).
Here I've found that having IB_xxxBars jumping focus between master
and detail is terrible. So I have a set of IB_xxxBars linked to the
master dataset and other jumping between the details datasets, if more
than one.
So when master is posted, all the details should be too. Cancel should
behave the same, even if this prevents to have master modifications
cancelled but detail preserved. I think that we should loose some
flexibility in favour of a simpler, better goal oriented user
interface.
So, since master/detail work must be inside the same transaction, I
would have some automation between the master events and the
transaction one, so when a edit/insert in the master begins, the
transaction starts, and when master is post/cancel, the transaction is
Committed or RolledBack.
Is it good and functional? Is there a better way?
Thanks
Marco Menardi

--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> Please use a fresh subject line when starting a new topic.
>
> > I don't know if it's a bug or a feature, but it's causing me some
> > serious user interface problems.
> > There is a difference in behavior:
> > You have:
> > Query with commitaction=caClose
> > Some IBO bars around
> >
> > If you have a dataset opened and press the Insert button, enter
the
> > fields, post, commit: dataset is closed, ok. Data disappears, you
get
> > the feeling that the work is done.
> >
> > If you have the dataset in search mode, press the insert button,
enter
> > the fields, post, commit: dataset stays in a strange state... it's
> > prepared, so you can still see the data just entered in IB_Edits,
and
> > it does not close so it does not automatically return in search
> > state... my user (and me) are lost...
> > This is not a good behavior.
> > I feel that even if starting in search, IBO should close the query
> > after the post or, since it's just closed but was in search,
return in
> > search mode.
> > Or am I missing something?
>
> You have stumbled across something I had not thought out ahead of
time. I
> understand what it is you are describing and I believe I know
exactly why
> IBO is doing what it is doing.
>
> When you are in search mode and go directly into insert state and
post a
> record the dataset has what I call an active buffer but the dataset
itself
> (its cursor) isn't active. Thus, if you test the Active property it
will
> return false but the BufferActive property will return true. Thus,
when the
> CommitAction is carried out it is looking for all datasets which
have (or
> had) an active cursor and they are closed. Because the CommitAction
isn't
> checking BufferActive instead of Active you are getting the behavior
you are
> describing. Is all I need to do in order to give it consistent
behavior is
> to have CommitAction as caClose make sure to close the dataset even
if it is
> just in the buffer active state rather than the full cursor active
state.
>
> Does this make sense? Now that you understand, hopefully, do you
think what
> I am proposing is the best solution?
>
> Regards,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com