It's easier to just do this:
1. Click on the combobox field in design view (viewing the field's properties).
2. In the AfterUpdate Event, select [Event Procedure] in the dropdown.
3. Click the 3 dots ... next to the dropdown box.
4. Add this code:
- To change the controlsource of the text box (which I think you mean):
me.MyFieldName.controlsource = me!MyComboboxFieldName
me.MyFieldName.controlsource = me.MyComboboxFieldName.column(1)
But make sure your form's recordsource supports the new text box's controlsource or you'll only get errors! Hence, you typically don't modify controlsources (and especially not using a Macro routine.) These types of scenarios are for developers who utilize vba coding.
- To change the value in the Text box (which I'm hoping you mean):
me!MyFieldName = me!MyComboboxFieldName
me!MyFieldName = me.MyComboboxFieldName.column(1)
MyComboboxFieldName is the name of your combobox field. Substitute MyFieldName above with the Text field your using. The Text field should have the controlsource based on the correct field in the table but if you're trying to change the controlsource for a global type 'var' variable text box (which I sometimes have to do), then use the first code above.
I wouldn't recommend the macro method. I'd recommend using the vba coding method above.
Also note: If you're working with a form design where you're changing the controlsource of a field and using a 'var' type global variable in your tables (which is usually a sign of someone wanting to change controlsources), be careful. These are heavily dependant upon code working exactly as it should in close coordination with the form's recordsource. I've personally found it to be a bit more problematic changing a field's controlsource property and setting up a 'global' type var system than it was to setup a non-var-global type structure and instead use a simple relational table structure more specific to the program's needs. Global type structures can often double/triple your development time and have little pay-off if you end up continuously modifying the design (as I often see) to support the next program so you can use that structure. Then you have to continously go back to your other designs (which use the same tables), and maintain them versus only maintaing the table structure specific to your program's needs.
If you're trying to globalize on a company scale (or larger), pay very close attention to what you share among programs. Try to keep these at their most basic form (ie. customer info tables, certain lookup tables). It's often problematic trying to globalize certain tables (ie. such as survey type tables which are program specific.)
Last edited by pkstormy; 10-11-09 at 15:13.
Expert Database Programming
MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)