Sure wish Microsucks would get their head out of their collective a** and fix that bug!
There could be absolutely no reasonable explanation why values can not be set to controls at run time whether they had the focus or not! Purely and simply and absurdly rediculous!
Sure wish Microsucks would get their head out of their collective a** and fix that bug!
There could be absolutely no reasonable explanation why values can not be set to controls at run time whether they had the focus or not! Purely and simply and absurdly rediculous!
What is the exact code you are using and which event are you doing it on, because you should be able to set it without the focus. Can you post a sample where it isn't working for you so we can take a look?
The point is that Access isn't Excel, VB, etc. it's Access! Every language has its own rules, and if you want to program in it, you have to take the time to learn the rules, not sit around carping because you have to learn the rules!
Actually it does make sense. .Text and .Value are used in totally different ways. The text typed into a textbox doesn't represent the value of the textbox until the cursor leaves the box and it is assigned to the textbox, and that’s as it should be. If you entered the word hemisemidemiquaver into a textbox, and each time a character was entered the Value changed, Access would have to update the field 18 times!
There are times when a programmer needs to check to see whether the current/new Value is the same as the OldValue for the textbox. Say this field was critical, and if it were changed you needed to confirm this change with the user.
Code:
If CriticalField.OldValue < > CriticalField.Value Then
Resp = Msgbox ("Are you sure you want to change the CriticalField Value?", vbYesNo)
If Resp = vbNo Then
Me.CriticalField.Value = Me.CriticalField.OldValue 'Revert to original Value
Else
'Do nothing, accept the changed Value
End If
End If
Now say this field originally had as its Value the word paradiddle. Using the above code and comparing paradiddle with hemisemidemiquaver would cause the code to execute and the warning message would appear. But if Access updated the Value every time a new character was entered, the OldValue and the current/new Value would both be hemisemidemiquaver, and the code wouldn’t execute!
So what do you use .Text for? You use it to check the text that been entered before it’s assigned as the textbox’s Value! Say you have a textbox for Comments, and since the field’s datatype is Text, it’s limited to 255 characters. As the user is entering data, you want to let them know how many characters they have left that can be entered. You’ve seen this before, on websites, for example, where you’re entering comments in response to a query. So you place a textbox named CharactersLeftTextbox beside your Comments box and use this code:
Code:
Private Sub YourTextbox_Change()
Me.CharactersLeftTextbox = 255 - Len(Me.YourTextbox.Text)
End Sub
As each character is entered into the Comments box, the length of the text is subtracted from 255 and the results (the characters left that may be entered) is posted in the CharactersLeftTextbox. Obviously, YourTextbox has to have focus for this to work.
Or you have an unbound textbox for entering search criteria and you want to limit the search string to 12 characters. In a textbox bound to a field, you can set the Field Size to 12 in it’s table definition, and Access will stop allowing characters to be entered after 12, but that’s not possible in an unbound textbox, because there is no underlying field in a table! So you’d use code similar to the above to keep track of how many characters have been entered, then throw up a messagebox. Things like that!
