Subject | Re: TIB_EditEnh Questions |
---|---|
Author | ehandbury |
Post date | 2002-07-22T05:50:13Z |
Geoff,
Thanks for the detailed answer. I think I will convert the fields
to INTEGER since I do not use the decimal. (I think I used NUMERIC(X)
since the IBO CURRENCY ColumnAttribute wouldn't work on a INTEGER.
One question though:
Your TEditEnh allows left-justification, whereas the TIB_EditEnh
does not. I like left-justification since, if the user clicks on the
field the whole field is highlighted, whereas in right justification,
if the user clicks on the field, the cursor will not be right-
positioned and you will get data like:
$ 0
$ 10
$ 120
$ 1230 etc.
(Tabbing into the field generates no problems).
This is a problem that I mentioned to Marco in his IB_Currency.
Do your data-aware controls support left-justification, and is
there a solution for the above-mentioned problem.
Thanks. Eric.
Thanks for the detailed answer. I think I will convert the fields
to INTEGER since I do not use the decimal. (I think I used NUMERIC(X)
since the IBO CURRENCY ColumnAttribute wouldn't work on a INTEGER.
One question though:
Your TEditEnh allows left-justification, whereas the TIB_EditEnh
does not. I like left-justification since, if the user clicks on the
field the whole field is highlighted, whereas in right justification,
if the user clicks on the field, the cursor will not be right-
positioned and you will get data like:
$ 0
$ 10
$ 120
$ 1230 etc.
(Tabbing into the field generates no problems).
This is a problem that I mentioned to Marco in his IB_Currency.
Do your data-aware controls support left-justification, and is
there a solution for the above-mentioned problem.
Thanks. Eric.
--- In IBObjects@y..., Geoff Worboys <geoff@t...> wrote:
> > Field: INCOMEAPPL1 numeric(18,2)
>
> If you have not already, please read the article on
> http://www.ibobjects.com/TechInfo.html called "Working with
Currency
> and Scaled Numeric" (or something like that anyway). It has words
to
> say about using numeric(18,2) with Delphi apps and IBO in
particular.
>
>
> > FieldEditMask: INCOMEAPPL1=::NM::!\$\ 999],999],990;0;0;0
> > DefaultValues: INCOMEAPPL1=0
>
> > 1) When I click on the TIB_EditEnh field and enter it, a beep goes
> > off. Why is that?
>
> > 2) When I exit the field (after entering 250000), the field shows-
> > up as $ 25,000,000. It looks like the numeric 2 decimals are also
> > used to format the number.
>
> When IBO sees a scaled numeric it treats as it is defined. That is
> a value with fixed decimal places. So a value of zero AsString
> becomes 0.00, and value of 250000 becomes 250000.00.
>
> The control displays text, which means it asks IBO to give it the
> text to display, and from the above you can see that IBO will give
> it a value containing a decimal point.
>
> The decimal point is an invalid character in the mask you have
> supplied and so the control goes "beep" - indicating an invalid
> character was received.
>
> When you enter 250000 it gets written to the field, when you tab out
> the control refreshes from the column, goes beep again (hopefully)
> with the invalid decimal point character and so ends up reading
> 250000.00 as 25000000 (invalid character was ignored).
>
>
> So thats what is happening. Its an interesting issue, I've not
tried
> to setup a numeric mask that displayed less that the whole field
> before. I would be tempted to try and fix this in the mask
processing
> but...
>
> The mask processing is purely a text/character arrangement. It does
> not actually know that the characters make up a number, as far as
the
> mask is concerned it is simply processing a string of characters
> against a defined set of rules. If I setup the ::NM:: numeric mask
> processing to handle this specially it would truncate the apparent
> value and not round - which seems inappropriate to me.
>
> Note that it would be possible to ask IBO to handle the AsString
> differently (not outputing the ".00" when no decimal place values
> exist). However you would still experience the problems described
> above if your value was 250000.01 (you would get 25000001).
>
> I am happy to consider this issue in more detail, but I doubt if a
> fix will happen quickly. It may actually need a new derivation,
> something like TIB_Number, that can deal with the column number
value
> directly.
>
> You could alter the mask so that it does not show decimal places if
> none exist but supports decimal places if they do. Of course this
> means it would support the input of decimal places - which is
> presumably not what you want or your mask would have supported it
> to begin with.
>
> If the value was readonly you could cast the field to NUMERIC(16,0)
in
> the select statement and that would solve the problem. To make the
> field properly editable in the current situation probably means
using
> stored procedures - or at least a custom insert/edit statement. Not
> sure I have not tried it for something like this.
>
>
> --
> Geoff Worboys
> Telesis Computing