How assign in a form, a function key to a command button.

[CJ_London]

But, as someone with ocular and motor disabilities, I'm sensitive to how others have to suffer with minuscule controls.
Are you more likely to make an error on a big-fat command button, or with a 1mm2 control that sits next to three other such controls?

Personally I wouldn't make any control 1mm2 - either nothing or a size that works. I do a fair amount of stuff that works on touch screens so my controls have to be 'finger sized'

Or make the f-key keystroke transfer to the code for the command button?

terminology - but in principle yes - or have both button and f-key utilise the same function - really depends on what it is doing.

As an aside I find the option and checkboxes irritably small - so, depending on requirement, I very rarely use them, I use a textbox instead which can be resized, use different colours and display a wider range of characters such as smiley face in addition the the usual tick or cross. All done using the format property plus a little bit of code

Other chars I've used is thumbs up/down, arrows up/down or left/right and utilising text on/off, parking/no parking, wheel chair access/stairs to name a few

see this link if you want the detail https://www.access-programmers.co.uk...eckbox.305659/

[orange]

Here's a video re Big Checkboxes by Crystal for consideration.

[twgonder]

This is old but still might work and give you what you want

https://bytes.com/topic/access/answe...n-keys-f12-etc

EDIT - forgot to say you'd need to set Key Preview property for form to Yes if you want the form to take precedence. Otherwise I believe the key press will be associated with the control that has focus.

So, the link is talking about doing fkeys for particular text boxes. And that's cool too, because I used to change the field entry fkeys when in a particular data entry field too. Unless a particular text box has a custom fkey enabled, I want to do the default form fkey for all text boxes. I can set the Key Preview, but then where is the best place to place the code so that one set of code works for all text boxes? I'll want to shift all the working code to a non-class module, so that the fkey and command button procedures just call the subroutine in non-class module (named mod_Au_Forms) where I keep code to do lots of stuff to the forms. If a custom fkey is set for a particular text box, then the code should reside in the particular class code for the text box.

As I think about it, if one presses the command button, that has focus (I think that's what they call it). But if one is in a textbox, and presses a fkey, then I would want to restore the textbox to it's unedited state (restore the old data if it was changed) before doing any of the fkey code. Also, I wouldn't want to have the system checking 10 different case statements on every keystroke in every text box on the form.

As I recall, in the old dumb terminals, the function key code only worked as long as the fkey was pressed before any other keysrokes were made, because dumb terminals sent an esc code+ with a <cr>. As best as I can recall, after an input statement, I looked for all kinds of strange input that could be control codes or fkeys and just tossed the user entry if found, returning to the input command to give the user another try. I have no idea how this will all work in Access text boxes.

Alternatively, if any key is first pressed in a text box other than a fkey, code could just disable the fkey for the field as well as the form until focus moves to the next textbox. Does that make sense?

Or should I just settle for those &s in the caption? But that doesn't solve fkeys for fields. Best to do it right I suppose. No short-cuts to good design.

[twgonder]

Personally I wouldn't make any control 1mm2 ...
Other chars I've used is thumbs up/down, arrows up/down or left/right and utilising text on/off, parking/no parking, wheel chair access/stairs to name a few

see this link if you want the detail https://www.access-programmers.co.uk...eckbox.305659/

So I got my previous and next buttons working, only requiring three lines of code in the class module for each button (so each form can use the same called code).

Private Sub cmdPrevious_Click()
  Dim obNm As String
  obNm = Me.Name
  Call subFrmCmdBtns(3, obNm, "")
End Sub

And I was just about to go to the header and add undo redo buttons with the arrow left and right symbols, and here is your post that might help with that. Very timely!

Off to do a search on how to do undo/redo in a form.

[twgonder]

Back to the original topic, here's how you program function keys as alternate to click on form button.

Attachment 48455

Clicking the button or pushing the function key produces the same result.

It seems to me this approach makes the fkeys universal, in all forms, and even if a form isn't active.
That would be a problem, as fkeys can change with subforms or control forms.

And of course, some would say, use code not macros.
I've yet to see how to make fkeys specific to a single form, but that can be modified for a field, returned back to form mode on a new field that uses the form fkeys, and is disabled when the form closes, returning all fkeys to their native Access function.

Also, I got lost in a prior conversation on functions vs subs. I tend to use subs for anything that isn't meant to return a sole value. I'm still not sure if that is a proper approach in Access. I'll have to see if I can find that older thread again, and read it again. I may have asked if subs can run from a macro.

Thanks for showing what can me done with a macro though.

[Micron]

That would be a problem, as fkeys can change with subforms or control forms.

I guess that's when you either a) have keypress event code per form, or b) pass the form name and decide whether or not the code should be executed or exited.

[twgonder]

I guess that's when you either a) have keypress event code per form, or b) pass the form name and decide whether or not the code should be executed or exited.

as to a): is this very processor intensive if every keypress is evaluated? I've yet to see a working model of it and how to get it to work, despite searching.

b) I'm not sure what you're describing, as what I was originally hoping for was some way that Access would handle a fkey keystroke in a manner similar to a command button press for the individual text box and if not defined for that textbox then to use the default for the form. In both cases, code is executed in any of many different purposes (as my buttons show in post #3). If you meant pass the form name to the macro, then I'm not sure that's a solution as to what's shown in post #14 that's ultimately desirable.

[twgonder]

Back to the original topic, here's how you program function keys as alternate to click on form button.

Attachment 48455

Clicking the button or pushing the function key produces the same result.

Thanks for taking the time to add your 2 cents. I wrote several observations and questions, and then lost it all when this forum software, decided that I needed to login yet again. I'll spare you the rewrite.

However, what you wrote leaves ne with a simple question to a complex problem. Were you or anyone else able to protect sensitive "control tables", like user access, from the hacker user? If any user can get to datasheet view of an unencrypted control table, then all security goes out the window. I know we can play games that make it harder for the hacker user, but ultimately, all those can be defeated (which is what hackers love to do) unless their is a solid bit of protection.

[CJ_London]

Were you or anyone else able to protect sensitive "control tables", like user access, from the hacker user? If any user can get to datasheet view of an unencrypted control table, then all security goes out the window.

if data security is your concern then access may not be for you. Yes you can protect tables, use encryption on individual tables, use obscurity but as with any system, nothing will save you from a determined hacker or talented user. Isladogs has some pretty good examples of what can be done - doubt he will tell you how as as that kind of defeats the objective. But you can test your hacking skills.

PS that is another reason for supplying .accde's rather than .accdb's to your users. It is really easy to break into the .accdb code and then all your encryption, passwords and the like will be fully visible. At least with a .accde you need to reverse engineer the code first - which is not an easy task.

As for using an ACE back end, if data security is your beef, then use sql server, mysql or other better protected BE. If only because someone can simply delete the ACE BE or take a copy to work on at their leisure. Encryption is pretty good but unless you do things right, easily discoverable by inspecting the FE.

Security is a whole subject in its own right and not one that can be dealt with piecemeal. With your years of experience you must have come across the need to develop a security policy which clearly defines what you want protecting, from whom and from doing what which then becomes part of the overall project specification.

[Micron]

is this very processor intensive if every keypress is evaluated?

Comparatively speaking, I would say yes. Would it be too much for the hardware or network traffic? Would depend on the capabilities of those things. I didn't mention it because it was a great idea; only that it was an answer to your question.

handle a fkey keystroke in a manner similar to a command button press for the individual text box and if not defined for that textbox then to use the default for the form.

If written for controls and the form, key events for the form are supposed to happen before key events for a control IF the keypreview property for the form is set to true so that seems to be the opposite of what you want.

Maybe this will help (it even mentions the idea of using function keys in user actions).
https://docs.microsoft.com/en-us/off...orm.keypreview