Re: Can a variable hold 2 values simultaneously - a string value and a numeric?

"Jana" <Bauer.Jana@xxxxxxxxx> wrote in
news:1135133162.622269.215790@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

> David was saying that a combo box on a form always stores its
> value as a string. . . .

I said NO SUCH THING:

"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in
news:Xns9732A40E6556Ef99a49ed1d0c49c5bbb2@xxxxxxxxx:

> Well, since combo boxes always return strings, you'd have exactly
> the same type coercion issues.

I said they RETURN strings. What gets stored depends on where that
value is going. If the combo box is bound to a numeric field, the
string is implicitly coerced to the appropriate type. And that's the
central problem of this thread, avoid the side effects of implicit
type coercion. You recommended as a solution to the implicit
coercion problem the use of a control that depends on implicit
coercion to work.

> . . . My point was that an unbound combo box with only numbers as
> "the values" and with the format property set to a number would
> indeed treat the user's selection as a number, not text. . . .

No, it would work exactly the same as MLH's original quandary, where
"2" stored in a variant was both a number and a string (because of
implicit type coercion).

> . . . For that matter, any
> combo box that is a lookup to another table with the bound column
> being a number would return a number. . . .

They all return strings. This is why combo boxes that return dates
are a problem.

> . . . Case in point, combo box that looks up
> EmpID and EmpName, with bound column as 1 (EmpID) would display
> the employee's name, but store the EmpID. (or am I losing my
> mind?)

Aha, just checking this, I discoverd that I've mis-spoken above. If
you check the value for the bound column, it returns the appropriate
type. If check it by column number, it returns a string, no matter
the type of the source data. It's hard to tell what happens with
dates, though, as there are always strange formatting things going
on with implicit type coercion.

So, my original statement was incorrect as it stood -- so far as I
can tell, it applies only to values returned by specifying the
column.

Now, I was about to say that your solution would avoid the type
coercion problem, but it depends on setting the format to General
Number for it to work, as just typing a list without the format
returns a string.

However, this has problematic side effects.

If you have a two-column list, such as -1;Yes;0;No, and you hide the
first column but it is bound, if you set the format to General
Number, the column right aligns (like a number), which looks wrong
for Yes/No values. You then have to right align it.

I guess it's a workable solution, but it has an awful lot of steps
in it that are required to make it work. And it's not exactly what
you said in your original post:

"Jana" <Bauer.Jana@xxxxxxxxx> wrote in
news:1135024465.024316.127970@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:

> I may be way off base, but maybe it would be easier to use a form
> with either a text box format to an integer, or maybe even a combo
> box with the values 1 through 10 that would GUARANTEE that you get
> proper input...

I don't know how to format something as an "integer", only as
numeric *display* format. That apparently works, but it still seems
to me as though it's a matter of a display format being recognized
by the type coercion functions, seems to me. There still seems to me
to be a degree of action on your values over which you have no
control.

The original solution used InputBox(), which doesn't require the
creation of a form. That function returns a string (a ZLS if no
answer is given). What MLH needed was better data typing in his
results. He was storing the result in a variant, and there is simply
no justification for that, as InputBox() cannot return anything but
strings.

So, everything that's returned has to be coerced if the desired
result is not a string.

He could do two different things with the InputBox() solution:

1. store in the string, then explicitly coerce it to the correct
data type and handle errors accordingly.

2. store the return value in an integer variable and handle the
error if the value is invalid (and can't be stored in an integer
variable).

My rule about explicit type coercion should lead me to choose #1,
but, in fact, I'd be more likely to use #2, since there, the
implicit coercion works exactly the way I want it to, with no
unpredictable side effects.

Now, the downside of InputBox() is that it allows people to input
invalid data, and the only way to find that out is *after* the
InputBox() has been removed from the screen, and then you have to
pop it up again to get a corrected value (this is generally done
with a WHILE ... TRUE loop). That's not very good UI, in my opinion,
but it's very *easy*.

So, for the best UI, you'd obviously want to code a dialog form,
anyway, but a combo box does not seem to me to be the best control
for the context of choosing the number of copies to print -- I'd do
a spinner control, instead. This guarantees no coercion issues, and
limits the values to incrementable values. Of course, I would never
make a spinner locked -- you always want the user to be able to type
in a number, so you'd have to trap for an accidentally typed letter,
but that's most easily done in the OnChange event and just throw
away anything but digits.

Interesting discussion, actually, as it shows the importance of two
major topics:

1. correct variable typing.

2. correct control choices.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.

Relevant Pages

  • Re: Is this a bug of Intel Fortran Compiler 10.1?
    ... string a_fmt will be used for the output format of integer a ... string a_fmt is used as a format descriptor ... -| implicit none ...
    (comp.lang.fortran)
  • Re: Date variable - seconds always set to zero
    ... Never ever implicitly convert datetime to a string. ... you what format that string would have. ... but it seems the implicit conversion is using ...
    (microsoft.public.sqlserver.programming)
  • Re: What is wrong with this code?
    ... VB doesn't care and won't complain about sticking an int into a string ... ... it's internal data type coercion will ... Dim y As String ... :> Public lname As String ...
    (microsoft.public.vb.general.discussion)
  • Re: Can a variable hold 2 values simultaneously - a string value and a numeric?
    ... > variable to have 2 values - one numeric and the other a string. ... useful message for anything that can't be stored in an integer. ... that the value you are comparing can be coerced to a data type ... important to never rely on implicit type coercion. ...
    (comp.databases.ms-access)
  • Re: Which variable to use?
    ... I suspect your problem is from the type coercion that ... occurs when you use .AddItem. ... Read the combobox value leaves it as a string, which is maybe not what you ...
    (microsoft.public.excel.programming)