in case others are interested...
here's what i found in google.
so... subform, it'll have to be.
------------------------------------------------------------------------
You real problem here is that you are being given code to let you select
options from a list box, and then send the results to a single field. This
is a bad idea, and when you finally get a working solution, you will simply
have been given enough rope you hang your self with.
I am sure that you know that this is a *VERY BAD DESIGN*. In addition, while
some of the code might help you move selected things from a list box to the
text box, when you go *BACK* to that record, the list box will NOT have
those values from the text box selected.
In other words, to really make a nice user interface, you would now need to
grab the values from the text box, parse out each individual entry, and then
send the results back into the list box. Those selected entries *should*
show in the list box. Since you are using code to move in one direction, you
will also need to move back in the other direction.
Anything that does not work as above is going to cause sheer and utter
confusion on the user part. What happens when they go back, and see entries
in the listbox are not now selected. This means they are likely to select
them again. When they select them again, and you run your code the existing
entries in the text box will be lost. You could *always* add selected items
from the list box to your text box field, but then if you keep the existing
entries it will be very easy to wind up with duplicates in you text box.
We are of course assuming that your list box is UN-bound. Since you are
allowing more than one entry to be selected, then the list box must be
un-bound.
You would be much better to create a small sub form, and placed a combo that
allows the user to select a value from a drop down list. They would have to
move down to the next line to add another selection. This is better, since
the user can then add/remove entries to the list in a much easier fashion.
You also eliminate any problems when the users navigate from record to
record. If you use your list box idea, then as mentioned moving from record
to record will requite code to update this list box as you move from record
to record. This is due to the fact that the list box is un-bound, and will
not change from record to record. This will be confusing to the user.
Thus, unless you also have code to move the data from the field to the list
box, then you will confuse your user. In addition, you can see that quite a
bit of code here is required to do what you want. In addition, this code is
fairly advanced.
The addition of a sub form, and table to hold multiple values will also make
searching, and any kind of reporting a million ties easier. Especially any
kind of counting or reporting. You can use the standard access tools to
report on this kind of data. With all your data "stuffed" into a single
field, you now cannot use the standard access reporting tools to work on
this data.
So, by splitting each value from a text box into another relational table,
you solve all of the above problems. Not only that, you don't need code, and
your data will be far more normalized, and thus much more flexible from a
design and maintenance point of view.
-------------------------------------------------------------
Facebook
Twitter