Well, there is some misunderstanding...
- NULL is a state, it means "unknown"
- 0 is an arbitrary value, that you interprete as "no lookup linked"
- Canc in LookupCombo is the action of setting the underlying field to
null

If you want your application with 0 that means "null", you have to
change the behaviour of a lot of things...

[cut]

>
> But this means that I have to write code for every LookupCombo key-
> field in every trigger to force this value to 0 if its NULL. This is
> the same as having all the code in the BeforePost events which is
> alot of work, and can result in alot of bugs.

Write code (triggers) on the server side to reduce bugs.

> Its much easier for IBO to use the DefaultValue specified for that
> field. When you think about it, it is wrong for IBO to take a
> default action which is not configurable by the developer.

Well, if you enter a field in IB_Edit, and you press "canc" while it's
highlighted, the field is blanked, not set to default value, but this
seems reasonable to me. And so reasonable seems the Canc in
LooupCombo. If you want a property for every possible use of a
control, you will end up with a 1,000 property control that is unusable ;)
I don't use default values in lookup fields, this is not a common use
of lookup fields. Lookup fields should have two possoble "sets" of values:
a) null -> no lookup
b) foreign key value
that's all...

> I have
> told IBO that, in the absence of a real value, I want that key-field
> to be 0, and IBO should honour that when the user hits the DEL
> button on the LookupCombo.

That's not the meaning of Default values. It's something that is a
default, not a "basic state". It's wrong, if you want to see something
wrong, that LookupCombo gives no visual clue that it has a value in
the field (0) that has no corresponding in the lookup table.
Just today I had a nasty bug because I deleted some rows from the
lookup dataset, and the "base" table was not "cascade" updated.
LookupCombo presented an empty field, so I thought that a NULL field
was there, not a non matching one...

>
> > If your modifications were included, how can the user set the
> field to
> > null? (canc will set to a default value...)
>
> But I would never want my key-fields to be NULL.

So you use LookupCombo to "build" your primary key in the table? i.e.
the primary key is a composite key, with some fields that have values
taken from lookup tables? mmmmm....
You could have an generator to build the unique primary key of that
table, and a "unique" index upon the fields that now are composing the
primary key... so NULL would be allowed.

> I use Generators
> for all my keys so storing a NULL into a integer field is
> semantically incorrect. NULL is not a proper integer value.

In SQL database, you have NULL as "unknown", so it's semantically very
correct in a database field :)

> I use the DefaultValue KEYVALUE=0. This means that no masterkey
> matches this value so no 'favourite book' is displayed.

Well, tomorrow I will insert a book with 0 as primary key. Ok, you can
avoid it, but you have to write code in the triggers, that you don't
like to ;)

Eric, I understand your fristration in this conversation, it's like
when I ask for some "obvious" IBO enhancements and someone tells me
that it's not desiderable... I think "how can that **** don't see how
usefull it would be???"
But sometime I see that things can be arranged in a different way, and
that thet way is better than the old one (maybe this is not the
case, anyway).
So be patient with me :)
If a tool is designed for some logic in mind, you must have very
strong reasons to ask for it's change, often is better change the way
you use it.

regards
Marco Menardi