You have some good ideas going and most if it is very much like I do, but
there are some better ways. Look at the Lobbyist sample application in the
ZIP in the AddOn folder. Particularly the FRM_LOB.pas form/unit and
FRM_PPB.pas form/unit. You will see how I have master detail relationships
on those forms as well as how I make these forms both master and detail to
eachother. Be patient with it and I think you will have some neat things
click for you if you give it due diligence.

I use a base form which uses a transaction in a way that allows you to
easily allow a user to interact with master-detail relationships. I use
triggers to wipe out detail records if a master is deleted, not a rollback.
You should only use rollback if you want to cancel the users work as a
whole. Please get familiar with the IBF_Base.pas form/unit. It has a lot of
useful functionality built into it. The lobbyist sample application makes
very heavy use of it.

Once you see what is going on in there it should become apparent how easy it
is to create powerful and yet easy applications for your users to work with.
The big bonus of it is there is very little code needed on top of this.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Marco Menardi" <mmenaz@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, November 14, 2001 10:41 PM
Subject: [IBO] Data entry user interface (was: Re: Master Detail: strange
behaviour)


> 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
>
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>