i have a bounded, continuous form with some textbox that users can modify.
I want to use some code to auto capitalize what ever the users typed, like
Private Sub textbox_BeforeUpdate(Cancel As Integer)
Me.textbox = UCase(Me.textbox)
End Sub
but it causes error... Any suggestions?
And I noticed that in a bounded, continuous form, I can't move the pointer in its recordset.
Me.Recordset.MoveNext
This causes error (number 3462). Why?
Put the UCase expression in the text box control's After Update event.
Private Sub textbox_AfterUpdate()
Me.textbox = UCase(Me.textbox)
End Sub
As for the second question, this works without error for a command button on my form.
Private Sub cmdMoveNext_Click()
Me.Recordset.MoveNext
End Sub
This is what I get in the Immediate Window for your error number.
? AccessError(3462)
Failure to load a DLL.
Is that the error text you see? If so, I don't know the cause, but I would wonder if your database is corrupt. Can you re-create a simplified version of this form in a new database to see whether it works there? If it also fails then, perhaps your Access installation is broken.
Frankly, I'm just grasping at straws. This seems very unusual to me.
For the first question:
Use the Keypress event to check for lower case letter and then return it's upper case counter-part:
Private Sub textbox_KeyPress(KeyAscii As Integer)
Const ASCII_LOWER_A = 97
Const ASCII_LOWER_Z = 122
Const UPPER_MODIFIER = -32
If KeyAscii >= ASCII_LOWER_A And KeyAscii <= ASCII_LOWER_Z Then
KeyAscii = KeyAscii + UPPER_MODIFIER
End If
End Sub
UPDATE: Since I received criticism and a downvote for my answer, I will elaborate on when and why you might use the code above.
First, let me say that the *After_Update* event fires after the control tied to that event loses focus (either via tab or actually moving to the next record). *After_Update* also recognizes a paste if the user cuts and pastes text; admittedly, my code does not. If your only concern is storing the text in the database in upper case, by all means use *After_Update* to UCase the value.
However, there is one advantage that *KEY_PRESS* press will give you: the ability to correct the letter pressed in real time.
To the purist developer, this event may seem wasteful. However, anyone who’s received a paycheck from a company should recognize that keeping their paying client happy is imperative. If that paid client says “I want to see capital letters when the user starts typing”, then you would use the code above. It will have little (if any) impact on how the application behaves and will meet your boss's requirement.
In fact, maybe the client says “Hey, this field is for putting in serial numbers for our inventory. All of products’ serial numbers use zeros, not the letter O. So please make sure they do not enter O for this field.”
Now *KEY_PRESS* has an additional use. You could either negate the letter O being pressed or you can replace the letter O getting pressed by the value you need:
Private Sub TextBox_KeyPress(KeyAscii As Integer)
Const ASCII_LOWER_A = 97
Const ASCII_LOWER_Z = 122
Const UPPER_MODIFIER = -32
Const UPPER_O = 79
Const LOWER_O = 111
Const ZERO_ASCII = 48
Select Case KeyAscii
Case UPPER_O, LOWER_O
KeyAscii = 0 'Cancel it out
'KeyAscii = ZERO_ASCII 'OR Replace it with the number zero
Case ASCII_LOWER_A To ASCII_LOWER_Z
KeyAscii = KeyAscii + UPPER_MODIFIER 'The old familiar code that will capitalize all other letters
Case Else
'Whatever other validations you want to do on the textbox here.
End Select
End Sub
So what about cutting and pasting invalid values? That is what Form_BeforeUpdate event is for. You can check all values before you save and set Cancel = True if something doesn’t jive.
It’s a very useful event and completly applicable if you want to UCase letters in real time.
Have you tried putting it in the TextBox1_Change Sub ???
Try
Private Sub textbox_BeforeUpdate(Cancel As Integer)
Dim strBuffer As String
strBuffer = Me.textbox
Me.textbox.Focus
Me.textbox = UCase(strBuffer)
End Sub
Related
I am having a trouble while trying to conditionally format the exhibition of records in a report inside a MS Access 2007 form.
I have search the Internet and I have seen lots os fellows stating that it is possible to perform visual changes in a single record via code implementing the method Detail_Paint() for the event Paint of the Detail section in a Report. Those people say that something like this is going to work:
Private Sub Detail_Paint()
val = CStr(Me.someTextBox.Value)
If val = "constraint" Then
Me.lineStrikethrough.BorderStyle = 0
End If
End Sub
The problem is that although the reading statement Me.someTextBox.Value returns the value of each record when the Paint event is thrown, the writing statement Me.lineStrikethrough.BorderStyle = 0 writes the value of the property BorderStyle for every single line in my report, not only for the one respecting the single record whose value I read from someTextBox field.
Can anyone tell me why such is happening? If this is the correct behaviour (although it does not seem right to me), how can I achieve my goal?
Note: lineStrikethrough is used to perform a strikethrough effect over the record in a Report. If there is another way to do that I would be happy to know.
Two things:
1 - Use the Detail's On Print event and not On Paint event.
Private Sub Detail_Print(Cancel As Integer, PrintCount As Integer)
val = CStr(Me.someTextBox.Value)
If val = "constraint" Then
Me.lineStrikethrough.BorderStyle = 0
End If
End Sub
2 - To see the conditional formatting, always open your report in Print Preview and not Report View.
You are really close!! :-) In my testing, it appears that the Detail_Paint() event allows you to change the formatting of controls, but changes will continue in subsequent records until you change/reset them to something else.
In your code sample, you just need to add another line to turn the strikethrough BorderStyle back on when the condition is no longer met.
Private Sub Detail_Paint()
Val = CStr(Me.someTextBox.Value)
If Val = "constraint" Then
Me.lineStrikethrough.BorderStyle = 0
Else
Me.lineStrikethrough.BorderStyle = 1
End If
End Sub
I found this clue on a code sample on MSDN which demonstrates conditional formatting using the Detail_Paint() method.
I found that Select Case to work best in the detail paint over if statements for a continuous form.
'Private Sub Detail_Paint()
Select Case CStr(Me.someTextBox.Value)
Case "constraint"
Me.lineStrikethrough.BorderStyle = 0
Case Else
Me.lineStrikethrough.BorderStyle = 1 'or what the default value is
End Select
I have an Access 2002 database/application where my clients can enter multiple information about their own clients, including a code which follow some rules.
However, when they view these information after they have been entered, I need to hide every characters in this code except for the 4 last characters. However, the agent needs to be able to edit this code if it needs to be modified.
So basically, I have 3 phases possible:
First time information are filled, empty data. The field must show the characters entered.
At a later date, the code must be hidden in some way to show only the last 4 characters. It can be with * or simply the last 4 characters, but the user must not be able to see what is before these.
The agent edit the code, the code must then be properly modified in the database. The characters must be shown.
I tried to show only the 4 last characters, however my database gets modified... So the code gets cut in the database.
I wrote the following function to obscure sensitive data. Its primary use is to discourage shoulder surfing. I'm not sure if it will meet your particular needs, but it is simple, straightforward and may help others who stumble upon this question.
'Use to hide data in sensitive fields (e.g., BirthDate, PhoneNum, SSN)
'Usage: Ctl OnEnter property: =ObscureInfo(False, Form.ActiveControl)
' Ctl OnExit property: =ObscureInfo(True, Form.ActiveControl)
' Form Open property: =ObscureInfo(True, [BirthDate], [HomePhone], [SSN])
Function ObscureInfo(HideIt As Boolean, ParamArray Ctls() As Variant)
Dim Ctl As Variant
For Each Ctl In Ctls
If HideIt Then
If IsNull(Ctl.Value) Then
Ctl.BackColor = vbWhite
Else
Ctl.BackColor = Ctl.ForeColor
End If
Else
Ctl.BackColor = vbWhite
End If
Next Ctl
End Function
Wow - I'm shocked that this hasn't been answered sufficiently. The best answer is to use an unbound text box in your form instead of a bound one. First you'll need to make your unbound text box populate the actual field. You'll do that in the AfterUpdate event.
Private Sub UnboundTextBox_AfterUpdate()
[MyField] = Me.UnboundTextBox
End Sub
Then you'll need to set an OnCurrent event to populate your unbound text box with the protected view whenever the agents view the record:
Private Sub Form_Current()
Me.UnboundTextBox = String(Len([MyField])-4, "*") & Right([MyField], 4)
End Sub
However, you also want to let your agents edit or view the full code later, if necessary. The best way to do this would be to set the OnEnter event for your unbound text box to pull the whole field value, so the agent can see and edit it - effectively the reverse of your OnUpdate event.
Private Sub UnboundTextBox_Enter()
Me.UnboundTextBox = Nz([Field1]) 'The Nz deals with Null errors
End Sub
I've used this with a field displaying SSN's and it works like a charm.
Can someone help me understand why this code isn't producing expected results?
I have a form with a text box called TxtVendorSearch.
When a user begins typing into this text box, I'd like for it to start filtering the results in the form's subdatasheet.
I am starting with a fully populated datasheet, and I'm not sure why the filter blanks out the whole thing as soon as I start typing a valid filter that should leave results.
Private Sub TxtVendorSearch_KeyPress(KeyAscii As Integer)
Dim str1 As String
str1 = "[VendorID] LIKE '*" & Me.TxtVendorSearch.Value & "*' "
Me!subOrderDS1.Form.Filter = str1
Me!subOrderDS1.Form.FilterOn = True
End Sub
I had a similar problem and i searched the internet for the keyword "find as you type" AND "ms access"
i found this great article. hopefully it will solve your problem.
N.B. this article also contains the source code to use.
Do not use the KeyPress event, you're not going to be able to easily reconstruct the actual input data from within the event handler itself (when the event is triggered, the key just pressed is not yet added to the text of the textbox, meaning you're always short a the last keystroke).
Instead, use the KeyDown event, and use the textbox' .Text property instead of .Value.
.Value is only set once the focus has moved away from the box.
So your code can be simply rewritten as (make sure your KeyDown event is set in the textbox's events on the form):
Private Sub TxtVendorSearch_KeyDown(KeyCode As Integer, Shift As Integer)
' If there is no filter criteria, disable filtering '
If Len(Trim(TxtVendorSearch.Text)) = 0 Then
subOrderDS1.Form.FilterOn = False
Exit Sub
End If
' Do nothing if user hits RETURN or TAB '
If KeyAscii < 32 Then
KeyCode = 0
Exit Sub
End If
Dim str1 As String
str1 = "[VendorID] LIKE '*" & Trim$(TxtVendorSearch.Text) & "*'"
subOrderDS1.Form.Filter = str1
subOrderDS1.Form.FilterOn = True
End Sub
I used Trim() to remove any leading and trailing white-space that the user may have typed.
Last thing: you don't need to use Me. or Me! from within the form's code itself.
Doesn't hurt if you do, but it makes things a bit less legible without adding anything to the code.
I'm using Access 2007 and have a data model like this...
Passenger - Bookings - Destinations
So 1 Passenger can have Many Bookings, each for 1 Destinations.
My problem...
I can create a form to allow the entry of Passenger details,
but I then want to add a NEXT button to take me to a form to enter the details of the Booking (i.e. just a simple drop list of the Destinations).
I've added the NEXT button and it has the events of
RunCommand SaveRecord
OpenForm Destination_form
BUT, I cant work out how to pass accross to the new form the primary key of the passenger that was just entered (PassengerID).
I'd really like to have just one form, and that allow the entry of the Passenger details and the selection of a Destination, that then creates the entries in the 2 Tables (Passenger & Bookings), but I can't get that to work either.
Can anyone help me out please?
Thanks
Jeff Porter
Actually the best suggestion I can give here is to not actually pass parameters. Simple in your form's on-open event, or even better is to use the later on-load event is to simply to pick up a reference in your code to the PREVIOUS calling form. The beauty of this approach is that if overtime you go from one parameter to 10 parameters then you don't have to modify the parameter parsing code, and you don't even have to modify the calling code. In fact there's no code to modify AT ALL if you decide to examine previous values from the calling form.
So, keep in mind using open args is only a one way affair. You can not use it to return values to the calling form. Furthermore all of the open args params will have to be strings. So, you lose any ability of dating typing such as real integers or even date and time formatting which can be quite problematic to parse out. And as you can see the example here the code to parse out strings can get a little bit messy anyway.
The simple solution is that in each form where you want values from the PREVIOUS from, simply declare a module level variable as follows
Dim frmPrevous as form.
Then in your forms on load an event, simply pick up the name of the previous form as follows:
Set frmPrevious = screen.ActiveForm
That is it. We are done!
We only written one line of code here. (ok two if you include the declaration statement). At this point on words ANY place in your form's current code you can reference the events properties and any field or value in the previous form by doing the following
Msgbox "PK id of previous form = " & frmPrevious.ID
And let's say for some reason that you want the previous form to re-load records as in a continues form. Then we can go:
frmPrevious.Requery
Or, force a record save:
frmPrevious.Dirty = false
So, the above becomes almost as natural and handy as using "ME" in your current code. I find this so simple and easy I think this should have been part of access in the first place.
And as mentioned the uses are endless, I can inspect ANY column or value from the calling form. You can even declare variables and functions as public, and then they can be used.
And, note that this works BOTH WAYS. I can stuff and change values in the calling form. So I can update or change the value of any value/column/control from the calling form.
And there is absolutely no parsing required. Furthermore the above code step even works if the same existing form is called by different forms. In all cases the forms calling ID can be picked up without modifying your code.
And even in the case of that I have many different forms launching and calling this particular form, you can still pull out the ID column. And, in the case that columns could be different from different forms, you can simply declare public variables or public functions in the calling form of the SAME name. So, if I wanted to call a form that needs the DateCreate, but each form did NOT have a consistent column name of DateCreate (maybe invoiceDateCreate and inventory Date Create), then you simply declare a public function in the calling forms with a constant name. We then can go:
Msgbox "Date created of calling form record = " & frmPrevious.DateCreated
So, Date created can be a public variable or public function in the previous form that could be any conceivable column from the database.
So don't pass values between forms, simply pass a reference to the calling form, not only is this spectacularly more flexible than the other methods showing here, it's also an object oriented approach in which you're not limited to passing values.
You can ALSO return values in the calling form by simply setting the value of any control you want (frmPrevous.SomeContorlName).
And as mentioned, you not limited to just passing values, but have complete use of code, properties such as dirty and any other thing that exists in the calling form.
I have as a standard coding practice adopted the above for almost every form. I simply declare and set up the form previous reference. This results in a handy previous form reference as useful as "ME" reference when writing code.
With this coding standard I can also cut and paste the code between different forms with different names and as a general rule my code will continue to run without modification.
And as another example all of my forms have a public function called MyDelete which of course deletes the record in the form, therefore if I want to delete the record in the previous calling form for some reason, then it's a simple matter to do the following
frmPrevious.MyDelete
So I can save data in the previous form. I can requery the previous form, I can run code in the previous form, I can return values to the previous form, I can examine values and ALL columns all for the price of just ONE measly line of code that sets a reference to the calling form.
I do this by defining properties in the form with Property Let and Property Get and passing values to those properties after opening the form, like this:
in the destination form:
Dim strCallingForm As String
Dim lngKey As Long
Public Property Get callingform() As String
callingform = strCallingForm
End Property
Public Property Let callingform(NewValue As String)
strCallingForm = NewValue
End Property
Public Property Let PrimaryKey(NewValue As Long)
lngKey = NewValue
End Property
in the calling form:
Sub btnGo_Click()
Const cform As String = "frmDestinationForm"
DoCmd.OpenForm cform
Forms(cform).callingform = Me.Name
Forms(cform).PrimaryKey = Me.PrimaryKey
Me.Visible = False
End Sub
(end)
I would use the openargs method of the form. That way you can pass one piece of data to the new form from any other form. You can also expand of this by sending a delimited string of arguments and then splitting them out. For example I have a form for editing agent activity that is passed the date, the agents name, agents ID and team in the open args
DoCmd.OpenForm "frmEdit_agent_activity", , , , , acDialog, Item & "|" & Me.txtDate & "|" & Item.ListSubItems(1) & "|" & Item.ListSubItems(2)
The form then uses this to pre populate the controls
Private Sub Form_Load()
If IsMissing(Me.OpenArgs) = True Or IsNull(Me.OpenArgs) = True Then
'no args, exit the form
DoCmd.Close acForm, "frmEdit_agent_activity", acSaveNo
Else
'this form has 4 open args
'1 Staff ID
'2 Date
'3 Team_ID
'4 Staff Name
Me.txtStaff_ID = GetDelimitedField(1, Me.OpenArgs, "|")
Me.txtDate = GetDelimitedField(2, Me.OpenArgs, "|")
Me.txtTeam_ID = GetDelimitedField(3, Me.OpenArgs, "|")
Me.txtStaff_name = GetDelimitedField(4, Me.OpenArgs, "|")
End If
End Sub
Ohh and here is the GetDelimitedField function
Function GetDelimitedField(FieldNum As Integer, DelimitedString As String, Delimiter As String) As String
Dim NewPos As Integer
Dim FieldCounter As Integer
Dim FieldData As String
Dim RightLength As Integer
Dim NextDelimiter As Integer
If (DelimitedString = "") Or (Delimiter = "") Or (FieldNum = 0) Then
GetDelimitedField = ""
Exit Function
End If
NewPos = 1
FieldCounter = 1
While (FieldCounter < FieldNum) And (NewPos <> 0)
NewPos = InStr(NewPos, DelimitedString, Delimiter, vbTextCompare)
If NewPos <> 0 Then
FieldCounter = FieldCounter + 1
NewPos = NewPos + 1
End If
Wend
RightLength = Len(DelimitedString) - NewPos + 1
FieldData = Right$(DelimitedString, RightLength)
NextDelimiter = InStr(1, FieldData, Delimiter, vbTextCompare)
If NextDelimiter <> 0 Then
FieldData = Left$(FieldData, NextDelimiter - 1)
End If
GetDelimitedField = FieldData
End Function
Have you considered subforms? There are ideal for one to many relationships. The Link Child Field(s) will be automatically completed from the Link Master Field(s).
If you need an example of subforms in actions, the Northwind database ships with all versions of Access, or you can download which ever is relevant.
2007
http://office.microsoft.com/en-us/templates/TC012289971033.aspx?CategoryID=CT102115771033
2000
http://www.microsoft.com/downloads/details.aspx?familyid=c6661372-8dbe-422b-8676-c632d66c529c&displaylang=en
You can use OpenArgs.
But I would also suggest that you also consider using a tab control.
That allows you to have different sets of controls on the same "screen real estate", using one single recordset, or using sub forms to show child recordsets.
In that case, you could use the "Next" button to just switch to the next page of your tab control.
Is there a way to disable entering multi-line entries in a Text Box (i.e., I'd like to stop my users from doing ctrl-enter to get a newline)?
I was able to do it on using KeyPress event.
Here's the code example:
Private Sub SingleLineTextBox_ KeyPress(ByRef KeyAscii As Integer)
If KeyAscii = 10 _
or KeyAscii = 13 Then
'10 -> Ctrl-Enter. AKA ^J or ctrl-j
'13 -> Enter. AKA ^M or ctrl-m
KeyAscii = 0 'clear the the KeyPress
End If
End Sub
The way I did it before (and the last time I worked in Access was around '97 so my memory is not so hot) was raising a key-up event and executing a VBA function. It's a similar method to what you do with an AJAX suggest text box in a modern webform application, but as I recall it could get tripped up if your Access form has other events which tend to occur frequently such a onMouseMove over the entire form object.
Using the KeyPress event means that your code will fire every time the user types. This can lead to screen flickering and other problems (the OnChange event would be the same).
It seems to me that you should use a single event to strip out the CrLf's, and the correct event would be AfterUpdate. You'd simply do this:
If InStr(Me!MyMemoControl, vbCrLf) Then
Me!MyMemoControl = Replace(Me!MyMemoControl, vbCrLf, vbNullString)
End If
Note the use of the Access global constants, vbCrLf (for Chr(10) & Chr(13)) and vbNullString (for zero-length string).
Using a validation rule means that you're going to pop up an ugly error message to your user, but provide them with little in the way of tools to correct the problem. The AfterUpdate approach is much cleaner and easier for the users, seems to me.
Thanks Ian and BIBD. I created a public sub based on your answer that is reusable.
Public Sub PreventNewlines(ByRef KeyAscii As Integer)
If KeyAscii = 10 Or KeyAscii = 13 Then KeyAscii = 0
End Sub
Private Sub textbox_KeyPress(KeyAscii As Integer)
Call PreventNewlines(KeyAscii)
End Sub
Screen flicker should never be an issue, as these are handled events, not constant polling (and it's per control further limiting the scope). Seems to me like an invalid argument, as every text editor is executing some code per keystroke.
Thanks
not entirely sure about that one, you should be able to remove the line breaks when you render the content though, or even run a vbscript to clear it out, you just need to check for chr(13) or vbCrLf.
If you don't want an event interfering, you can set up the Validation Rule property for the textbox to be
NOT LIKE "*"+Chr(10)+"*" OR "*"+Chr(13)+"*"
You will probably also want to set the Validation Text to explain specifically why Access is throwing up an error box.
Jason's response works well. Just to add to it..
If you want to allow the user to leave the text box blank, you could use this:
Not Like ""+Chr(10)+"" Or ""+Chr(13)+"" Or Is Null