Initial zeros in combo boxes

  • Thread starter Thread starter Darrell
  • Start date Start date
D

Darrell

I am pulling from 3 hidden text fields on a main from to
populate 3 combo boxes on a subform with default values.
When these default values begin with a zero, the initial
zero is dropped. The table fields underneath are text
fields, there are no input masks at the table or control
level, and the controls are formatted "@@@@;"None"".
These are the only things I know to troubleshoot. Can
somebody help me retain those initial zeros? These are
account numbers, and they must be there!

Thanks!
Darrell
 
Darrell said:
I am pulling from 3 hidden text fields on a main from to
populate 3 combo boxes on a subform with default values.
When these default values begin with a zero, the initial
zero is dropped. The table fields underneath are text
fields, there are no input masks at the table or control
level, and the controls are formatted "@@@@;"None"".
These are the only things I know to troubleshoot. Can
somebody help me retain those initial zeros? These are
account numbers, and they must be there!
Click to expand...

There are as many as three tables involved here -- the table to which
the main form is bound (if it's not unbound), the table to which the
subform is bound, and the table that is the rowsource of the combo
boxes. Make sure that the relevant fields in *all* these tables are
defined as text, not number.
 
Thank you for the suggestion. I had checked that, and
have now rechecked it--same result. What else can I try?
 
Darrell said:
Thank you for the suggestion. I had checked that, and
have now rechecked it--same result. What else can I try?
Click to expand...

Do you have a numeric format applied to any of the controls involved?
If that doesn't help you solve it, and if you can create a cut-down copy
of the database that contains just the elements necessary to demonstrate
the problem, you may send that to me at the address you get by removing
NO SPAM from the reply-address of this message, and I'll have a look at
it, time permitting. Please be sure to compact your copy and
zip-compress it to less than 1MB in size.
 
Dirk,
Thank you so much for your time. I'm going to hang on to
your e-mail address and the content of these messages. I
was already preparing the suggested e-mail when I asked a
colleague to have a last look at this problem.

He inserted "Chr$(34)" and "Cstr" before the main form
control reference in the AfterInsert event, and Chr$(34)
after it, and it seems to be working ("Cstr" alone was
not enough). I guess if you find enough ways to tell
it "this is a string," it eventually gets the message.

If this stops working at any time, I'll have your info.
handy.

Thanks again.
 
Darrell said:
Dirk,
Thank you so much for your time. I'm going to hang on to
your e-mail address and the content of these messages. I
was already preparing the suggested e-mail when I asked a
colleague to have a last look at this problem.

He inserted "Chr$(34)" and "Cstr" before the main form
control reference in the AfterInsert event, and Chr$(34)
after it, and it seems to be working ("Cstr" alone was
not enough). I guess if you find enough ways to tell
it "this is a string," it eventually gets the message.
Click to expand...

I'm curious as to what the code in the AfterInsert event was before your
colleague modified it, and what it is now. That might explain what was
going on. But if you've got it working now, you may not feel like
posting it.
If this stops working at any time, I'll have your info.
handy.
Click to expand...

Just be sure to remind me that this is in reference to a newsgroup post
in which I invited you to contact me outside the newsgroup.
Thanks again.
Click to expand...

You're welcome.
 
Back
Top