Solved Click button on Enter WITHOUT USING DEFAULT BUTTONS (1 Viewer)

[dev_omi]

Hi all. I've found many threads on this topic, but most of them are forcefully shut down by someone insisting that the OP give up and use default buttons. This is not the right option for me, so please don't suggest it.

I have a search box (unbound text box) and, next to it, a search button. The search button checks whether the search box is blank or null, and if it's not, it searches the form's table--if it finds no match, a message box pops up and says so; if it finds a match, it filters the form to that record.

When the user hits the Enter key in the search box, I want it to click the search button. I'm using this code:

Private Sub SearchText_KeyPress(KeyAscii As Integer)

    If KeyAscii = 13 Then 'Enter key
        KeyAscii = 0
        Call SearchButton_Click
    End If

End Sub

I also changed the Enter Key Behavior property of the text box to "New Line in Field" rather than Default, since Default just moves to the next control in the tab order (even with the KeyAscii = 0 line, which seems necessary to prevent hitting Enter from actually inputting a new line before the search is executed).

If I hit Enter twice, it works, but I have to hit it twice. If I hit it once, it just highlights the string in the text box. What is going wrong?

Attaching a sample database.

 

[dev_omi]

Okay, I half figured it out! The problem is that the KeyPress event runs before the textbox value is "committed". Hitting enter the first time runs the code, which also "commits" the text box at some point. Then, when I hit enter again, the textbox value is up to date from the prior commitment.

I tested this by "committing" the data by just clicking to another text box, clicking back, and then hitting enter. That works just fine.

So I guess I need code to "commit" the data in the textbox. Sorry that I keep using that word, I just don't know what to call it--you're not really saving/unDirtying a record because it's an unbound text box. It's just that the data in the text box is not set as the value of it until something confirms or commits it.

I hope this makes sense. I know it sounds insane, I'm just missing the words I need at the moment.

 

[arnelgp]

use the Textbox's KeyDown (or KeyUp) event and not the Keypress.

 

[theDBguy]

Hi. Can't check your file right now, but I would normally use the AfterUpdate event to start the search. However, I do that with the Enter key behavior not set to new line.

 

[Pat Hartman]

The form worked for me as you intended.

Why in the world you you change the function of the enter key??????? Every good interface conforms to certain known behaviors and we should NOT change them. Access offers a button which the users understand and will know how to use.

If this is a "hands on the keyboard" issue, tab and then enter solves all problems with no code. You just have to set the tab order so that the button follows the text box as the next control in the tab order. I had to resize the button to fix the tab order automatically but that was because the button was taller than the search box. You can also fix the tab order manually by changing the tab index property. This is a zero based array. So, the first control in the tab order has an index value of 0, the second is 1, etc. If the search box has a higher value than the search button, just manually type in a new number to "move" one control before/after the other. Access renumbers all the other controls as necessary.

 

[dev_omi]

Relax, man. The Enter key has a variety of functions, even within Access. It can be set to create a new line, to tab to the next control, or to activate the form's default button. Outside of Access, it is *extremely* common to be able to hit Enter to execute a search after entering search terms. Google works like that. All web browsers do. Plenty of commercial database softwares do. I actually polled the employees I was working with this morning about how they would expect to execute a search after entering search terms, and literally every one of them said they would hit Enter and expect that to work.

I love the help on this forum, but the unsolicited advice is insane, especially when I deliberately try to head it off in the OP.

 

[dev_omi]

Other people, thanks so much for the suggestions. I will be testing them this afternoon

 

[MarkK]

Here's how I typically do a search form...

 

[Pat Hartman]

but the unsolicited advice is insane

Not a problem. I'll keep it to myself.

 

[MarkK]

I love the help on this forum, but the unsolicited advice is insane, especially when I deliberately try to head it off in the OP.

In the coming years this thread will be consumed by possibly thousands of other users, one or more of whom may find the exact advice they were seeking in a response you've called insanely unsolicited.

Unsolicited responses are exceedingly valuable. You don't own this thread.

Have a nice day,

 

[dev_omi]

In the coming years this thread will be consumed by possibly thousands of other users, one or more of whom may find the exact advice they were seeking in a response you've called insanely unsolicited.

Unsolicited responses are exceedingly valuable. You don't own this thread.

Have a nice day,

Then one is welcome to politely mention it, not rudely ask a sarcastic question with a dozen question marks. That's why I tried to head it off in the OP, because it's almost always rude, presumptuous, and lacking literally all of the context.

But sure, if your goal is to help users in the future, reply to my threads with unsolicited advice. Just don't expect me to be grateful for it

 

[MarkK]

Then one is welcome to politely mention it,

No sir. You cannot control what other people will say. In fact--in a public forum--one is equally welcome to ridicule other posters as one is welcome to politely mention things. It is your error to expect otherwise, and actually increases the chance that people may ridicule you.

My 2c for public forum users??????? Expect ridicule. Ignore it when it happens. Stay focused on your purpose for being on the site.

Please continue to have a nice day.

 

[dev_omi]

No sir. You cannot control what other people will say. In fact--in a public forum--one is equally welcome to ridicule other posters as one is welcome to politely mention things. It is your error to expect otherwise, and actually increases the chance that people may ridicule you.

My 2c for public forum users??????? Expect ridicule. Ignore it when it happens. Stay focused on your purpose for being on the site.

Please continue to have a nice day.

Excuse me while my eyes roll out of my head.

To everyone else: I wasn't able to get the code to work even when putting it on the KeyUp or KeyDown events. Again, it works but only when the string entered in the unbound textbox is saved as the value of that unbound textbox. It's like there is an Update event that does not take place until the record is saved or the control loses focus or whatever. (This is also why I wasn't able to get it to work with the AfterUpdate event--anything I do that triggers the AfterUpdate event can just be implemented at the KeyPress level, whereupon my original code works fine.)

There are some janky solutions. The easiest seems to be adding Me.Refresh to the code before calling the SearchButtonClick procedure. I don't love that this saves the active record, but if I dislike it enough, I can just add a "do you want to save this record" dialogue box. So problem solved, I think.

Thank you to those who provided helpful responses.

 

[dev_omi]

Hi. Can't check your file right now, but I would normally use the AfterUpdate event to start the search. However, I do that with the Enter key behavior not set to new line.

Glancing back over this, your solution is actually very similar to the one I ended up going with. The text box value gets saved because, in your form, Enter tabs to the next control. I'd just like to avoid that if possible (which it is if you refresh the form).

 

[Gasman]

Welcome to my IL.

 

[theDBguy]

Glancing back over this, your solution is actually very similar to the one I ended up going with. The text box value gets saved because, in your form, Enter tabs to the next control. I'd just like to avoid that if possible (which it is if you refresh the form).

I never implemented something like what you wanted, because I was happy for the value to be saved, since I can also just remove it.

I was finally able to download your file and implemented what I think is probably what you were asking for. Hope it helps...

 

[dev_omi]

Wow, nice! Yes, that works exactly as intended. I can't really figure out why yours works but mine didn't.. the main things I'm noticing are (1) that you used the KeyDown event instead of KeyPress, (2) that you used KeyCode instead of KeyAscii, and (3) that you didn't call a button click procedure but rather used a function that was called by both the button click and KeyDown events. I'm gonna fiddle around and try to find out which of these factors was the difference maker.

Thanks so much!

 

[theDBguy]

Wow, nice! Yes, that works exactly as intended. I can't really figure out why yours works but mine didn't.. the main things I'm noticing are (1) that you used the KeyDown event instead of KeyPress, (2) that you used KeyCode instead of KeyAscii, and (3) that you didn't call a button click procedure but rather used a function that was called by both the button click and KeyDown events. I'm gonna fiddle around and try to find out which of these factors was the difference maker.

Thanks so much!

Glad to hear you got it to work. Let us know if you have any questions. Good luck with your project.

 

[dev_omi]

Glad to hear you got it to work. Let us know if you have any questions. Good luck with your project.

Very much appreciated

 

[arnelgp]

I'm noticing are (1) that you used the KeyDown event

not to mention i already advised you earlier (post #3), since i test first before i advise.