This should be a really simple thing that for some reason I can get to work.
I have an MS Word document which has a drop-down field. If I double-click it - a dialog comes up to add or remove things from the drop-down field.
I just need to be able to get out of this mode so that the drop-down field behaves like it should from a user's point-of-view rather than from a design point-of-view. Basically I just need it to display the items rather than a dialog to allow me to add and remove the items.
According to what I've read, it looks like I should be able to do this by going to Developer, and then toggling the Design Mode button. This doesn't work; whether the Design Mode button is on or off I still can't get it to just act like a drop-down.
Thanks much
It sounds like you're using a legacy form field dropdown. For those to operate as a dropdown, you must protect the document for forms:
On the Developer tab, click on Restrict Editing. The Restrict Editing task pane opens.
In the task pane, check the box beside Allow only this type of editing in the document.
In the next dropdown, choose Filling in forms.
Click on Yes, Start Enforcing Protection.
Protected forms don't allow text to be edited in protected sections. In those areas, only form fields allow you to enter text. If that's too restrictive, look into Content Controls, which don't require document protection.
Related
I am developing an application for the desktop with Flutter. I had to implement the form with multiple input fields. I really need to make the whole focus flow and I have used the FocusNode class to move from one input field to another. Everything is based on the submit event, so when I hit the Enter button on the keyboard it moves to the next field. It is pretty ok, but I have to change it from Enter key to Tab key which is more natural for the desktop users. Have you got any idea what can I do here to achieve such a result? Is there a way to trigger the submit event by different key (than Enter)?
This bug is for making it easy to bind keys to actions. Once that's complete, one of the intended use cases is to add tab support for form field navigation. There's been a lot of work in that area recently, so I wouldn't recommend putting time into working around this yourself.
I have a continuous form which displays an overview/summary of my data. A user can select a row and click a button I created in the footer to open another form which has all the detail for that particular record and be able to edit it. This works fine. However I would also like for certain fields to be editable from the continuous form. I enabled two fields I would like users to edit directly (One is a combo box selection and the other a text box) When users click the combo box for any record it works fine and they can go back to the same record and select another value if they wish. All great but the text box behaves rather differently - The text box will allow the user to initially enter a value but after entry the box appears disabled and the only way to change the initial data entry is to go into the detail form which still works. Why can't users change the text box from the continuous form after an initial entry?
I found the issue!
There was a conditional filter on that particular field
I have a multi-page form, using a vertical tabs UI, in redux-form, and I'd like to track the current tab selection in the redux-form store.
What's the best way of doing this?
I would track the current tab selection outside of redux-form, but I've integrated redux-form with redux-undo, and I'd really like for undoing a form change to go back to the tab of the modified control.
I tried using a selected redux-form field, but this means that changing the selected tab marks the form as dirty.
From reading the docs, I could probably use reducer.plugin to add arbitrary properties to the redux-form store, but I don't see any documentation of which arbitrary property names are "safe," and I'd have to update the plugin for every form that should behave this way.
Any ideas?
I would like to add two optional properties for every page in sulu, the name of a menu-icon and an additional long title for every menu-item. I thought the best place to add those would be the "Settings" tab which shows up when editing an individual page in the admin, underneath the "Show page in" option.
Is there any way to add my own fields to this tab, or do i have to make it an individual property in every page-template? And why isn't the mandatory page-title an option like "Show in page" which doesn't require inclusion in individual page-templates?
We already thought about removing the title from the structure, but it grow that way, and it is not that easy to remove. Apart from that we are not sure if we want that at all, because this way you can place the title in the form where ever you want.
And it is currently not possible to easily add fields to the settings tab. Either you add them to the content tab using the XML files, or you create an own tab for your data as described in the documentation.
I am trying to find the most usable/accessible way to implement a simple form dropdown list which will sort a list of products by pice and alphabetical order.
In your opinion is the dropdown more usable when there is a button that governs its submission or when it automatically submits onchange of the dropdown?
The research I have read is both for and against such methods and there is a variery of implementations on the web so interest to hear the thoughts of the community.
Thanks in advance
As a blind computer user either method works fine. I find that having a button to click is slightly easier for me then the onchange event firing. I wouldn't say it's a big enough difference to take into account though assuming the majority of your users will not be disabled. If your targeting specifically blind users I would not use the onchange event.
So long as you do not change focus or navigate to another page when the selection changes, either approach should work. The classic example of a problem dropdown is where it contains a list of other pages on the site, and navigates as soon as the selection changes. This prevents a keyboard user from using the list; they can't browse it, and can't navigate to any pages beyond the first selection, since it's impossible to navigate past those. So in cases where focus changes or the page navigates as a consequence, having a separate action (eg. Go button, or handling enter) to cause the navigation to take place is essential. This is likely where the advice you've read is coming from.
In this case, however, it sounds as though you are just updating content elsewhere on the page, and not changing focus or doing navigation. Simply resorting existing content should be fine.
Depends on your users and their respective expectations and the context in which it's presented.
As a blanket, general statement, you should have the drop down accompanied by very obvious submission button. That is the safer approach.
If you are refreshing page data or if the focus moves away after the dropdown option is selected, you should use a button to be accessible. If you fire the event on change, blind or keyboard-only users will not be able to use the dropdown menu at all if they are on windows with ie and chrome (so added together, a majority of the people on windows). As soon as they use the arrows to scroll down and make a selection, the first option they hit will be selected and the page data will refresh or the focus will move, making it impossible for them to navigate or select the second option, third option, etc. Below is a thorough explanation with examples so you can see what I mean.
Designers definitely don't like the buttons, but if you are blind and on chrome/ie, it is impossible to use a lot of dropdowns without it. I'm guessing Jared uses firefox or a mac.
http://pauljadam.com/blog/javascript/onchange-event-on-a-select-inputjump-menu-accessibility-problems/