Re: Invalid variant type conversion

From: Bjørge Sæther (bjorge_at_hahaha_itte.no)
Date: 01/21/04 

Date: Wed, 21 Jan 2004 10:40:02 +0100

Maarten Wiltink wrote:
> "Bjørge Sæther" <bjorge@hahaha_itte.no> wrote in message
> news:Sy7Pb.2471$hd.44652@news2.e.nsc.no...
> [...]
>> I have yet to hear good arguments why a string variable or field
>> should be able to reflect the distinction NULL / "", other than
>> the more theoretically oriented arguments that you've used. And
>> it results in errors and extra work, every day. For little purpose,
>> if you ask me.
>
> Well, when you rule out theoretical considerations, you leave me with
> practical examples only. So let me give you one such example.
> Cascading Stylesheets let you specify what formatting properties
> apply to given bits of a marked-up document. The default value for a
> child element is inherited from the parent (usually and other
> disclaimers). In the case of a string property, after explicitly
> setting it to a value, how do I make it revert to inheriting that
> from its parent?
>
> This is a case where you have a domain and really want one extra value
> that is not in the domain. The convention in CSS is that the string
> "inherit" makes the property revert to inheriting its value from the
> parent element. But what if I want to set a property to the string
> value "inherit"?

Good example. I've been up to the same kind of trouble, the [Inherited] <>
[Set to EmptyString] <> [Actual String value to set].
What you're doing when you use a NULL value to specify the "inherited", is
IMHO giving the NULL a specific meaning in your application, not unlike
interpreting a component 'tag' property. It's not obvious at all what NULL
means here. You're simply utilizing a "benefit" of the technology. The NULL
value of a database may be used for this purpose, but you can't reflect this
in application programming unless you limit your coding to types that have a
NULL value.
BTW, using database fields for holding CSS data would normally be done in a
BLOB/MEMO field text, rather than putting CSS' properties in dedicated
fields. There is no such thing as a NULL value in CSS format, only a missing
value ("tag"), AFAIK.

I've been dealing with a similar problem in my DataObjects handling. I need
to know whether a field value is NULL (not for string fields, but for the
numeric/ordinal ones), and I don't want to reserve "magic values" for this
purpose. The solution is using a block of bits to indicate nulls. the
sequence will then be like with TField:

  if Obj.IsNull('Price') then...

...but there is one thing I don't need: 'IsNull' for string fields. The
empty string tells it all. I will not write an application that gives NULL
value of a string field any meaning. Databases require NULLS for referential
integrity, but the distinction is superflous, since using a '' for a key
value is madness. Thus, the "inherited"/"override" problem should be handled
otherwise. How to show it in a GUI ? I developed a special vertical grid
type, having an extra column of check boxes indicating whether the value was
to be left unchanged or specifically set - e.g. to EmptyString. No control
can show the difference between the two for a string value, unless some
extra functionality is added.

When you 'Clear' a TMemo using your keyboard, what value do you write in the
underlying field ? You have to decide, right ? It's not obvious at all, it's
an utterly meaningless ditinction. 

-- 
Regards,
Bjørge Sæther
bjorge@haha_itte.no
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.
Quantcast