Results 1 to 3 of 3
  1. #1
    Join Date
    May 2009
    Posts
    104

    Unanswered: Setting the control source of a text box

    I want to change the control source of a text box using an after update event from a combo box. I tried to use the Set Value action in the macro builder but i don't know the syntax for setting the property "control source".

  2. #2
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    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
    or
    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
    or
    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 16:13.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  3. #3
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Macros are the problem here. Give em up. VBA is far far better and it's NOT that hard to get your head around if you are coping with macros.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •