RowSource vs ControlSource?

Steepleboy04

Registered User.
Local time
Today, 01:13
Joined
Aug 3, 2006
Messages
11
What is the difference between the two?

I'm a newbie messing around with both of these properties in a form and need some help.
 
RowSource is a table/query for a ComboBox or ListBox. ControlSource is a field to which a control is bound.
 
This is obviously a confusing concept for most of the novice programmers. But to make it clarified, I want to make it simple.
Row Source - It is used to fetch the data to the control for which the property is set.
Control Source - If more than one field/column is retrieved in the Row Source property, then this property can be used to filter the required field.

Thats it.
 
Very impressive, StreetHawk. You have managed not only to revive a thread to which a suitable answer has already been provided, but also to provide an answer even more confusing to the novice User.

I look forward to more of your invaluable input for newer threads.
 
ByteMyzer,
Your sarcasm doesn't help.
I am trying to figure out why I can assign a value to a bound control with VBA.
StreekHawk added some useful information. You gave me nothing.
 
Last edited:
ByteMyzer,
Your sarcasm doesn't help.
I am trying to figure out why I can assign a value to a bound control with VBA.
StreekHawk added some useful information. You gave me nothing.
StreetHawk gave some incorrect information. The Control Source, as was mentioned by Rural Guy, is the property of a control which is normally set to a field name that exists in the form's Record Source (table, query or select statement). You can type a formula in there too but then it will not update a table. It has to be "bound" to a field from the table, query, or Select statement so that Access knows where to store or edit the data for that control.

It is NOT, as StreetHawk wrote, for filtering.


Is that any better?
 
It does Bob, Thank you.

Here is what I am trying to figure out. Perhaps you can help me out. I am at a loss.

I have a combobox that I am trying to update one of two ways: 1) user chooses item from a QRY or 2) Assigning a calculated value. It is 2) I am having trouble with.

My Row Source is - SELECT [Footprint].[Footprint Ref] as [Footprint Ref], [Footprint].[Footprint Ref_Legacy] FROM [Footprint] ORDER BY [Footprint Ref];
And my Control Source is - [Parts].[Footprint Ref].
[Footprint] is the table that either 1) gets a Footprint Ref or 2) gets updated with a new Footprint Reference.
[Parts] is the table will the final Footprint Ref in the end.

The goal is that the user can choose [Footprint Ref] or in another area of the form, he inputs data that creates a new Footprint Ref, I have code that updates the Footprint table with a new footprint, (Successful), but when I try to assign the new footprint to the form field

Me![Footprint Ref] = New_FP

I get the error:
"To make changes to this field, first save the record."

I get the same thing even if I try to save first with
DoCmd.RunCommand acCmdSaveRecord
Me![Footprint Ref] = New_FP

Am I right in thinking that the form holds the data until the underlying table is updated, [Parts]? Why can't I assign a value to the form, Me![Footprint Ref]?

Appreciation and thanks in advance!
 
If the combo is bound to the same field for which you are trying to use the code, it won't work. You can't do it that way if the value doesn't exist in the combo already. So, a workaround would be to have a separate text box which is bound to the field. Unbind the field from the combo by deleting the field name in its control source. In the After Update of the combo you have it set the value of that text box to its value. You can also use your current code for setting it from the other location. But if it is saved from the other location you should set

Me.YourComboName = Null

to clear it so it isn't confusing to anyone. You don't have to worry about the after update event of the combo firing because after update events do not fire when a control is set via code. If you ever do want the after update event to fire after setting something via code you need to call that event directly.
 
Bob,

Thanks you for your response. It makes sense. I am still having some problems with this though. Could you give me a little more time to bang my head and see if I can figure it out and check back here again? I don't want to waste your time if I can do it myself.

Jerry G
 
Bob,

Thanks you for your response. It makes sense. I am still having some problems with this though. Could you give me a little more time to bang my head and see if I can figure it out and check back here again? I don't want to waste your time if I can do it myself.

Jerry G

Best thing is to start a new thread when you are ready and someone will most likely be along to help. It really isn't the best to post in old threads. One reason is the number of replies sometimes just puts off people when they are searching for who to help. If there are more than one or two, many just bypass them.
 
Very impressive, StreetHawk. You have managed not only to revive a thread to which a suitable answer has already been provided, but also to provide an answer even more confusing to the novice User.

I look forward to more of your invaluable input for newer threads.

This thread was useless up to this point, but at least somebody spoke up with truth, which is refreshing.

It's amazing how much utter and complete bullsh$t there is "out there."

<resume scrolling in hopes of finding a useful answer...>
<fughedaboudit>
</scrolling>
 

Users who are viewing this thread

Back
Top Bottom