--- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:

> 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.

Sorry, but in IB 4.2Fxx I've found nothing with those names, even if
I've unzipped all what I've found in the AddOns. Could be more
specific? Or there is another place where to go?

> 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.

I was referring to the situation, I think very common, when the user
is inserting the master record AND the detail ones (like
master=customer, detail=customer phone numbers). Otherwise I user
referential integrity (on cascade delete) instead of triggers... any
drawbacks?

> You should only use rollback if you want to cancel the users work as

a

> whole.

That was my meaning. But I don't think a normal use can easily
understand and manage a two level of doing things for simple
situations like the above (post-commit / cancel-rollback). So I think
it would be better "hide" the innermost level and make post behave
like commit, and cancel like rollback.

> 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.

I'm looking forward. Using a tool (IBO for the specific) not the way
it was designed for is always frustrating and with modest results.

>
> 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.

This kind of application should be (Helen, are you lissening? ;))
discussed in a huge chapter of GSG. I think that master IBO big list
of properties is one step, use it effectly is the most important and
less explained one. I've the feeling I'm freezed at that point :(

> The big bonus of it is there is very little code needed on top of

this.

What can I say? Fantastic as usual. Even trying to use IBO my own way,
I'm getting more and more convinced that it's a great set of
components, really well designed. I would like to put my contribution
to it, if any good idea comes out from this tired brain...
Regards,
Marco Menardi

>
> Regards,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "Marco Menardi" <mmenaz@l...>
> To: <IBObjects@y...>
> 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/

> >
> >