command button on a form, what is the VBA code to ask user a question and user reply

[LittleRock Z]

The question to the user will be like enter LOT number, and the user reply would be a 3 characters. The purpose of the command button is to position the table / file to a specific record.

[Bob Fitz]

The question to the user will be like enter LOT number, and the user reply would be a 3 characters. The purpose of the command button is to position the table / file to a specific record.

You could use a message box to get the users reply but a better way, might be to use the wizard to create a combo box. Select the 3rd option (Find a record on my form based on the value I selected in my combo box). Access will then do all the work for you using macros. Access will even convert the macros to vba code for you with the click of a button.

[Welshgasman]

Input box Bob, not message box?
I would probably just use a normal textbox.

[Bob Fitz]

Input box Bob, not message box?
I would probably just use a normal textbox.

Thank you Welshgasman. Another "Senior Moment" I'm afraid. I was, of course, thinking of an Inputbox.
Curious to know why your preference would be for a textbox to find a record rather than a combo?

[Welshgasman]

Thank you Welshgasman. Another "Senior Moment" I'm afraid. I was, of course, thinking of an Inputbox.
Curious to know why your preference would be for a textbox to find a record rather than a combo?

I too would use a combo, but only for a set number of options?
If the user has 60k+ records etc and each has a unique value that is going in the combo, then finding it would be a little laborious, even typing character by charcter?. I now use a FAYT class for my combos as well, but that is a step up from normal VBA. Easy to implement though TBH.

[Micron]

What's not known is if the user already knows the value to be input. They may be reading it off of an invoice or similar source, in which case there's no need to look it up?

[LittleRock Z]

The Combo box provides a list for the user to choose from.
What I want is for the user to tell me the part number, and I will move to and display the matching record.

[LittleRock Z]

The user does know the number, and I want to locate the record and display it.
If the number is not found, the user can get a "No Find, try again"

[madpiet]

The Combo box provides a list for the user to choose from.
What I want is for the user to tell me the part number, and I will move to and display the matching record.

Why would you do that? The whole point of a good UI is to not make the user guess or pick invalid options.

[Bob Fitz]

The user does know the number, and I want to locate the record and display it.
If the number is not found, the user can get a "No Find, try again"

So why not use a textbox (perhaps in the forms Header section)

[Micron]

If you still want an input box, there are millions of posts about how to code for it so why not research that instead of us recreating the wheel here?
Here's but one - https://www.youtube.com/watch?v=-3Z7DMTf_Pg

What you'd also want is code that uses GoToRecord method - as long as you're not doing this directly on a table. Or you could simply apply a filter to the form (assuming you're even using one) after user OK's input box. There doesn't seem to be a lot of code examples for using input box for this, probably because it's not common to use one. Input boxes require validation, otherwise errors are commonly raised due to bad inputs. Also, the returned value is a string, which means you have to convert values in order to use them as dates or other numbers. That's why combos or listboxes are used to provide the input, which often contains the actual record ID, meaning you don't need clumsy commands like GoToRecord. If you want the best of both, use a FAYT combo to filter the combo list and then choose. Or use a listbox that automatically requeries itself as you type, thus filtering the list as you go. Then choose from the filtered list.

[LittleRock Z]

If you still want an input box, there are millions of posts about how to code for it so why not research that instead of us recreating the wheel here?
Here's but one - https://www.youtube.com/watch?v=-3Z7DMTf_Pg

What you'd also want is code that uses GoToRecord method - as long as you're not doing this directly on a table. Or you could simply apply a filter to the form (assuming you're even using one) after user OK's input box. There doesn't seem to be a lot of code examples for using input box for this, probably because it's not common to use one. Input boxes require validation, otherwise errors are commonly raised due to bad inputs. Also, the returned value is a string, which means you have to convert values in order to use them as dates or other numbers. That's why combos or listboxes are used to provide the input, which often contains the actual record ID, meaning you don't need clumsy commands like GoToRecord. If you want the best of both, use a FAYT combo to filter the combo list and then choose. Or use a listbox that automatically requeries itself as you type, thus filtering the list as you go. Then choose from the filtered list.

Thank you for the in-depth reply. I find it very useful thank you.
Now for the rest of the story, which is more than than you probably care about. I am an old time assembly language programmer, and I have volunteered to resurrect the cemetery management program for a small country church cemetery. The original system was developed under contract and has since died for lack of funds to pay for its upgrades, The previous manager maintained the records by taking a page out of the master book, placing it in a typewriter, making the changes on the typewriter and putting the page back in the master book. I have one table which has 723 Records, one for each LOT, and each LOT has eight PLOTs. it is a flat table with no sub parts. All the updating forms have been completed to their satisfaction. now I have a report form for the user to review and select one for printing as a replacement page in the master book. The lot numbers are unique all 723 of them, And keyboard keys allow the user to page up and down to the record of Choice and print it, case closed. But I would like the user to tell me the LOT number and let me proceed up or down to that record for their printing,

[Welshgasman]

I would have an unbound textbox in the form header.
You enter a lot number. AfterUpdate event does a FindRecord on that lot number.
Validate that it is not > than 723.

Job done.

[Bob Fitz]

Thank you for the in-depth reply. I find it very useful thank you.
Now for the rest of the story, which is more than than you probably care about. I am an old time assembly language programmer, and I have volunteered to resurrect the cemetery management program for a small country church cemetery. The original system was developed under contract and has since died for lack of funds to pay for its upgrades, The previous manager maintained the records by taking a page out of the master book, placing it in a typewriter, making the changes on the typewriter and putting the page back in the master book. I have one table which has 723 Records, one for each LOT, and each LOT has eight PLOTs. it is a flat table with no sub parts. All the updating forms have been completed to their satisfaction. now I have a report form for the user to review and select one for printing as a replacement page in the master book. The lot numbers are unique all 723 of them, And keyboard keys allow the user to page up and down to the record of Choice and print it, case closed. But I would like the user to tell me the LOT number and let me proceed up or down to that record for their printing,

Well, IMHO, the best and easiest solution would be to use a combo box in the Header section of the form.

[Micron]

I find the management of what happens to some of us after we pass on to be an interesting subject, so it's not more than I care to read about your problem as you say. I created a columbarium db as an exercise in design because of a similar posted situation, but I think that is overkill for your case. Point is, whatever your db is designed for, there is probably somebody waiting in the wings here who has some knowledge of the need, or at least is willing to help and perhaps interested in the concept.

Not sure a flat file is best for your application, but something tells me you're not going to change that and are only interested in a quick solution to an immediate problem. That is OK, but just letting you know that should you ever decide to turn this into something more robust, you'll probably find that there is no shortage of help (albeit it usually comes with a lot of questions that are needed to flesh out whatever proposal someone has in mind).

So for now, you have had a few suggestions, and they all seem to fit the requirement one way or another. You just have to decide on which way to go?