I'm working on a library system in MS Access 2010. One of the challenges is that we have blind and other visually impaired users accessing the system.
They use NVDA, a screen reading software, and the issue is that the software doesn't read the content of comboboxes straight away. To get around this, one would have to press CAPSLOCK+UP or INSERT+UP (NVDA commands) which read the current line in focus. So they are currently doing this line by line manually to know where they are.
I thought of automating this through Sendkeys, but as far as I know there is no way to combine keys other than Alt, Shift and Ctrl. This is a small piece of code I'm using just so that down key drops down the combobox:
Private Sub Username_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyDown Then
Me.ActiveControl.Dropdown
End If
End Sub
I would like to add to this code so that the pressing of Up and Down keys trigger the reading of the combobox through Sendkeys of INSERT+UP or perhaps some other way I'm not aware. Is this possible? Any ideas?
I wonder if the right question is being asked. It sounds like a problem in Access that you're trying to work around. I'm not familiar with Access itself (so I probably shouldn't be commenting) but I am very familiar with accessibility.
Are you tabbing to a checkbox in a cell, or a checkbox that is in a popup dialog such as when you sort a column and want to select/deselect some of the filters? Is the problem that the checkbox itself does not have a label to be read, or that it does have a label but the label can only be read using a "read all" shortcut key (such as ins+down) or "read current" (ins+up)?
To put this in html terms, the follow code will display a checkbox that visually appears like the checkbox has a label, but the screen reader does not know there is a label.
<input type="checkbox">Do you feel well today?
The screen reader will just say "checkbox". However, if you tie the label to the checkbox using the <label> element
<input type="checkbox" id="mycheck"><label for="mycheck">Do you feel well today?</label>
then the screen reader does know the checkbox has a label and will say "Do you feel well today?, checkbox, not checked".
I know that's a tangent from the original question, but I'm wondering if you are creating a checkbox in Access or if you are trying to navigate to a checkbox that natively exists in Access (such as the sort dialog). If you are creating a checkbox, then similar to how you have to associate a label with a checkbox in html, I wonder if there's a way to associate a label with a checkbox in Access. If so, then you wouldn't need your workaround.
Related
Update **
I found that the event is firing but there is no visual clue for the user. Is there a way to make it obvious to user that these labels are clickable.
Adding a gif to illustrate the issue.
I looked for an obvious answer on web but I could not find the solution. Hopefully, it is a property setting somewhere.
I have a continuous form with labels in form header. We have an event on double click on one of the labels. However, when the form is displayed, none of the labels are clickable. If it allows us to write events (click / dbl click) then obviously these labels should be clickable.
I looked through the properties of label but there is no "enabled" property. So, question is that how to make the label clickable? I hope it is a simple property setting.
Thanks
Labels are fine for clickable..i use them a lot to perform various operations like dynamic sorting.
EDIT : because i just noticed it...when textboxes/checkboxes/optionboxes are dropped in a form the labels that are associated with them don't have any events...you have to put explicitly an unassociated label to have its events exposed
We've got a checkbox on a form that we'd like to be able to check/uncheck even whilst the form is opened as read-only (it's a sales/product form and when an order has been invoiced, we want to prevent changes).
I know I could add a command button in its place and even make that button look like it's a checkbox with some images, or even set up a key combination to be used instead of the checkbox, but first I'd like to know if it's possible to simply exclude one checkbox from being read-only on a read-only form.
No. You must go the other way around:
Make the form read-write, then disable all controls bound to data fields except this single checkbox.
I have a form including listboxes. I'm trying to change order of listboxes. I tried bring front or send back but they are not working in form view. I found z index property for arranging their priority. However, following codes are not working. Is this correct way to do it? Or is there any other way with or without codes to do this?
Me.Controls.SetChildIndex (Me.List0 , Me.List1)
Thanks for any help.
Without using code:
You can change the z-order by right-clicking any control and selecting "Position" then selecting either "Bring to Front" or "Send to Back."
Unfortunately, Access does not support the ZOrder method for manipulation using code. Microsoft Forms does support the ZOrder method which can get confusing when it comes up on Access Help.
As I reread your question, I wonder if you're talking about tab order. If so, right-click and bring up "Properties," select the "Other" tab, then adjust the "Tab Index" property. Also, make sure that the "Tab Stop" property immediately beneath is set to "Yes." In code you would use FormName.ControlName.TabIndex=0 to set a control to the first tab position.
Hope this helps!
Reference: Personal experience (and hours of frustration)
docmd.RunCommand acCmdDesignView
forms("form1").Controls("text0").inselection=true
docmd.runcommand acCmdSendToBack '(or docmd.runcommand acCmdBringToFront)
docmd.RunCommand acCmdFormView
Also, ZOrder is still not supported by Access 2016. As such, I have not yet learned a way to write a single line of code that puts a control in between two others, I just send the middle to back and then the back to back, and expand this to however many controls have to overlap.
And last, even though you use the VBA for ZOrder, your English does ambiguously sound like forms("form1").Controls("text0").TabIndex=34, which as Olek suggested, is also quite simple.
I did this on one Access form: The control I wanted on top I just cut and pasted it back to the form, then moved it over the one I wanted to cover. In this case, it was a text box (bound), almost the same size as a combo box (unbound); only the dropdown of the combo extended a bit to the right of the text box, so when the form was loaded the text box looked like a combo box. The user clicked the dropdown and made a choice and the record(s) pulled up were reflected in the text box.
I am making a very simple feedback form for an MS-Access application I'm working on. It consists of a textbox (for comments), a Submit button, and a Cancel button.
In your opinion, when the focus is on the textbox, is it more intuitive for the Enter/Return key to click the Submit button or move the cursor to the next line within the textbox?
Edit: The textbox is obviously multi-line.
Standard Access UI is that in a data entry form, the ENTER key is equivalent to the TAB, i.e., moves to the next control in the tab order.
The exception to this default behavior is textboxes that are bound to memo fields. In that case, the default is to have the ENTER key insert a CrLf in the bound memo. Textboxes have a property for this.
In a feedback form, it seems to me that the ENTER key should create a new line when the focus is on the textbox where the user is to type the feedback. ENTER should submit the form only when the focus is on the SUBMIT button.
All that said, your terminology sounds very web-like (nobody uses "submit button" in database forms programming, and certainly not in Access). I like certain aspects of HTML forms and the ENTER key, but have learned from watching others that 99% of the users out there don't know that in an HTML form the ENTER key submits the form (when the focus is not on a multi-line input box).
It's possible to set a command button on a form as the default button, such that hitting the ENTER key will click the command button, but for anything other than a dialog form, that's usually inadvisable in my experience. Users don't expect the ENTER key to execute a command button and making it do so is just likely to confuse them, even if it does make the Access form behave something like HTML forms.
I'd suggest that this depends on your layout: in an obviously multi-line textbox, the average user might expect Enter to move to a new line. In a single-line textbox, we generally don't expect that behaviour.
Depending on the structure of the form.
If the form has several textboxes, I expect it not to send the data when I hit Enter, except maybe on the last text box. Hitting Enter should do nothing, or move the focus to the next text box if you're feeling creative (most users will find this behaviour strange - it is not common in WinForms to move between input fields on pressing Enter).
If the form really consists of one text box and a submit button, then maybe sending the data when i hit Enter is ok, but I'd still be careful - users will not expect this behaviour, except in obvious places (like Google's search text box), and it will annoy the users if they accidently hit Enter and have their incomplete form being sent.
For a multi-line textbox, yes. It's more intuitive for the Enter key to go to the next line. However, in almost every other case (at least for my users), the Enter key should "hit" the "Submit" button.
Caveat: Most of my users use forms with textboxes to do a Search function against the database, which then populates textboxes in another form that disallow editing. My spiffy way to avoid them creating "new" customers that aren't real.
My Access 2000 DB causes me problems - sometimes (haven't pinpointed the cause) the "book" form won't close. Clicking its close button does nothing, File -> Close does nothing, even closing Access results in no action. I don't have an OnClose handler for this form. The only workaround I can find involves opening the Vba editor, making a change to the code for that form (even adding a space and then immediately deleting the space), and then going back to close the "book" form, closing it, and saying "no, I don't want to save the changes". Only then will it close. Any help?
Here's a forum post describing, I think, the same problem you face. Excerpt belows states a workaround.
What I do is to put code on the close button that reassigns the sourceobject
of any subforms to a blank form, such as:
me!subParts.sourceobject = "subBlank" 'subBlank is my form that is
totally blank, free of code and controls, etc.
docmd.close acForm, "fParts", acSaveNo
The above 2 lines is the only way I've found to prevent the Access prompt
from popping up.
http://bytes.com/forum/thread681889.html
Another alternative is
(Me.Checkbox)
or my preferred syntax:
(Me!Checkbox)
It seems to me that there is much confusion in the posts in this topic. The answer that was chosen by the original poster cites an article where the user had a prompt to save design changes to the form, but the problem described here seems like it's a failure of the form to close, not a save issue (the save issue came up only in the workaround describing going to the VBE and making a code change).
I wonder if the original user might have incorrect VBE options set? If you open the VBE and go to TOOLS | OPTIONS, on the GENERAL tab, you'll see several choices about error handling. BREAK ON UNHANDLED ERRORS or BREAK IN CLASS MODULE should be chosen, but it's important to recognize that if you use the former, you may not see certain kinds of errors.
There's not really enough detail to diagnose much more, other than the fact that the reference to the checkbox control seemed to have been causing the problem, but there are a number of Access coding best practices that can help you avoid some of these oddities. The code-related recommendations in Tony Toews's Best Practices page are a good place to start.
That sure is weird. Do you have any timer controls on the form? If you do, try disabling it in the OnClose.
There is a possibility that the message box that asks if you want to save changes is being displayed behind the form. I believe that this message box is modal so you must click yes or no before you can do anything with the form which is why you can't close it.
Does your form have an unload event? That can be canceled, and if it is, the form won't close when it's in form view. It will only close in design view, which, when you edit the vba code is what the form does in the Access window when you're editing the code.
Does your form have a checkbox, toggle button or option button? There's a bug in Access 2000 where Access won't close if you test the value without explicitly using the Value property in the vba code, like this:
If Me.chkbox Then
versus:
If Me.chkbox.Value Then