>> At the client the default is the value applied when you first
>> create the record.

> Right, my point exactly. If a user clicks on a LookupCombo
> selecting a 'favourite book' and then presses DEL, the server
> has not been involved upto this point. So when the user first
> physically creates the record, the key-value will be either
> some foreign-key, or the DefaultValue or NULL if the user has
> pressed DEL. This is inconsistent and wrong.

By pressing the delete key the user is voluntarily changing the
default value. Run your scenario through a BDE setup and see if
it holds...

I started up "Fish Facts" and assigned a default expression
to the Category field. When I created that record the default
appeared as expected so I hit delete to clear that value and
then posted the record. The BDE did not replace my cleared
field with the default - I did not really expect it to, but
thought I would check since it seems to be what you are
expecting IBO to do.

I imagine you may argue that that application does not support
NULL and so the same reasoning does not apply. But it does.
Defaults and NULL states are independent concepts. There is no
rule that says NULL must be replaced by a default if defined.

> You're talking apples and oranges here. Conceptually, a empty
> result-set is a NULL, but we are not talking about the result-set
> here... We are talking about the physical value of how a NULL
> result-set is stored in a integer foreign-key field.. and NULL is
> not a valid integer, and to eliminate this possibility I have
> added a constraint within IBO via the DefaultValues entry which
> is sometimes used and sometimes not.

You have really lost me here. Since you are using LookupCombo I
was expecting that you were looking up a foreign key value. And
from that assumption I imagined you would have defined the server
side foreign key constraint using declarative syntax. And from
that perspective NULL plays a critical role in optional
relationships.

But it seems that either we are not talking about an enforced
foreign key, or you are applying your own enforcement via triggers.
This is not typical, although many of us do still write (at least
some) trigger enforced relationships NULLs are the typical mechanism
to support empty relationships (so you an use declarative NOT NULL
to enforce mandatory relationships).

Perhaps this is irrelevant to the question of using defaults, but
it is not irrelevant to the standard behaviour of LookupCombo. The
standard behaviour (setting to null on clear/delete) is exactly
appropriate to most peoples use of that control against
relationships formed via declarative syntax.

>> If you want different behaviour write it! And you are right,
>> using BeforePost events is inefficient and error prone. You
>> should be deriving your own components.

> Are you saying that a 1,000 IBO developers must write their own
> individual code (BeforePosts or triggers or derived classes) to do
> something that could (and should) be done easily by the component
> library?

No, if there were really a large use for this feature (and perhaps
there is). I would be interested to know what makes you believe
that this feature would be, could be or should be used by so many
IBO developers. It seems like something that is specific to your
implementation to me.

At this stage I imagine that there are 1000+ IBO developers who
are actively using IBO without this feature, which must be worth
considering - although it does not mean that you idea is not worth
serious consideration as an enhancement.

I guess what grabs my attention about your posting was the
insistence that IBO was doing something wrong. As far as I can
see IBO is being entirely consistent and correct in its current
behaviour.

If you want to ask Jason to add this as an optional extra feature
to the LookupCombo control then thats great (as long as it does not
replace the standard behaviour). You may need to expand a bit on
what exactly you expect, for example; does hitting delete during
edit also return to the default value.

I am not saying your objective is unreasonable, my own code does
some interesting things with defaults in places. But I have not
expected Jason to develop such solutions just for my own use.


There are a several choices in this regard...

* Being the only developer I currently know of that wants this
behaviour you could (possibly should) write your own code.

* You could offer to contribute such a change to IBO's code - in
this case as an option, certainly not the standard mode.

* You could offer to pay Jason (or someone else) to develop this
solution for IBO and yourself.

* You could do some leg work and try and discover 1000 IBO
developers that would actively use this feature - as this would be
very likely convince Jason to write it. (He may do so anyway if
you ask him nicely instead of insisting that its a bug in IBO.)


--
Geoff Worboys
Telesis Computing