I have a number of buttons on a WinForms User Control. I have given each button an AccessibilityName and an AccessibilityDescription. JAWS will read the AccessibilityName however doesn't read the description even if I press [INSERT+B]. I'm unsure why this is happening or if I need to set the AccessibilityRole.
Any help would be appreciated.
At the time of writing this, attempts to expose supplemental
information through the Button.AccessibleDescription property
typically do not work. This is because the AccessibleDescription
string value does not get exposed through the UIA properties that are
commonly used for supplemental information, (for example, the UIA
FullDescription or HelpText properties).
Source: https://learn.microsoft.com/en-us/accessibility-tools-docs/items/WinForms/Button_HelpText
The linked page suggests using Button.QueryAccessibilityHelp event handler.
I am not sure but this bug fix may be relevant, but I am not familiar enough with WinForms accessibility to know if this is the same issue.
Related
Is it possible to customize default user control markup in xaml ?
Let's say i have a user control named MyUserControl.
What I would like to know - is it possible, when I type
<controls:MyUserControl -and then type- >
instead of just ending up with
<controls:MyUserControl ></controls:MyUserControl>
to have
<controls:MyUserControl DependencyProperty="1" DependencyProperty="Person" ... ></controls:MyUserControl>'
Basically I want to create a custom template that would be used when auto-completing user control in xaml editor.
Purpose is to show the user available properties right away ( user that wants to use some control that he did not use before can see how to change important properties without browsing all possible properties on user control )
As far as I am aware, there is no simple way to do that, but I'd say that it was unadvisable to try to do that anyway. You said that you want to show the user available properties right away, but that is what Microsoft's Intellisense in Visual Studio is for. Once you have declared your DependencyPropertys, they'll automatically appear in a popup when a user is using your class.
As the .NET controls do not do what you suggest, then yours shouldn't really do that either. You're more likely to confuse developers with this unusual behaviour and they might even leave these added and quite possibly unwanted properties because they don't know any better. Your best bet to help users of your code is to implement it in as standard a way as possible, so that everything will work as expected.
You know, the most annoying bugs are caused from problems with code that was meant to help us.
How can I determine when a user has updated the text in a textbox before the Binding has updated the source?
I was expecting to find an "IsDirty" property on either the TextBox or the Binding ...
My problem is that the "Cancel" button Enabled property is bound to the ViewModel's IsDirty property and is disabled until the focus moves out of the textbox.
"IsDirty" needs to be defined as ViewModel.IsDirty || TextBox.IsDirty
WPF can't support the typical IsDirty behaviour that users would expect in a high quality application.
The problem stems from the strange design of the Binder class.
Furthermore WPF architecture is kind of hard-coded to using the default Binder implementation, replacing it is a huge job and requires many "dirty tricks" to work around the endless WPF design flaws.
The easiest way I found to workaround this limitation is to move all value conversion logic to the view model and use UpdateSourceTrigger=PropertyChanged, and implement your own IsDirty and IsInvalid logic and flags.
This approach also plays nicely with Caliburn.Micro
First, why is Cancel disabled? It should be enabled all the time. Any other behavior would be odd. The user should be able to cancel although he hasn't done anything.
Second, I would use Commands so that it can determine whether it can be executed or not based on the state of the viewmodel. Should be easy to implement, if the viewmodel also provide the implementation of the command.
I'd recommend to read some articles and/or tutorials about it. Google for the interface ICommand.
And to answer your question. Assuming you're using binding you could use the INotifyPropertyChanging interface to determine when a value is about to change. You could then store the current value in a backup field or something.
EDIT - Regarding "let him lose data"
Sure it's a valid strategy. Think on a larger input dialog e.g. 5 input controls, which must be validated before persisting the input. I'm assuming that the data is very important according to your arguments. Furthermore, you started to hack your data into the dialog. On input control 3 you decide to press 'ALT + F4'.
First, ask yourself, why did the user press the keys? IMHO he doesn't care about what's happening to his data.
If 'ALT + F4' is just an example for being robust. Forget about it. I think absolute robustness cannot be implemented without being very expensive.
Second, regarding consistency and validity after the restart of the application, you have to throw the data away so that you don't start with an undefined state. Remember, the entity the user began to fill is not valid at this state. Neither the states respectively the values of the properties are.
So IMHO the much better strategy is to restart with a clean and defined state, so that the user is able to continue with whatever you want him to do with your application.
Why is this strategy better? Well, it's much easier to implement. And the much more important argument, the user never gets lost because of an odd state.
I have inherited a large MFC application which contains a CComboBox subclass that overrides OnPaint. Currently it does all its drawing by hand (with lines and rectangles), and renders a combo box that looks decidedly Windows 98-style. However, it otherwise works great and provides a lot of useful custom functionality that we rely on, and rewriting the entire control is probably not an option.
I would like to modernize it so that the OnPaint draws in Aero style where available (falling back to the old code when modern theming is unavailable). I've done this with some other custom controls we have, like buttons, and it works great for our purposes. I know there are some tiny behaviors that it won't get right, like gentle highlights on mouse-hover, but that's not a big deal for this app.
I have access to the CVisualStylesXP ckass, so I've already got the infrastructure to make calls like OpenThemeData, GetThemeColor or DrawThemeBackground pretty easily (via LoadLibrary so we don't force Vista as a min-system). Unfortunately, I don't know the proper sequence of calls to get a nice looking combo box with the theme-appropriate border and drop-down button.
Anyone know what to do here?
Honestly, I don't know why they originally tried to override OnPaint. Is there a good reason? I'm thinking that at least 99% of the time you are just going to want to override the drawing of the items in the ComboBox. For that, you can override DrawItem, MeasureItem, and CompareItem in a derived combo box to get the functionality you want. In that case, the OS will draw the non-user content specific to each OS correctly.
I think you best shot without diving in the depth of xp theming and various system metrics is take a look at this project: http://www.codeproject.com/Articles/2584/AdvComboBox-Version-2-1
Check the OnPaint of the CAdvComboBox class - there is a full implementation of the control repainting including xp theme related issues.
Not sure if it's the same situation - but when I faced this problem (in my case with subclassed CButtons), solving it only required changing the control declaration to a pointer and creating the control dynamically.
Let's assume that your subclassed control is called CComboBoxExt.
Where you had
CComboBoxExt m_cComboBoxExt;
You'll now have
CComboBoxExt* m_pcComboBoxExt;
And on the OnInitDialog of the window where the control is placed, you create it using
m_pcComboBoxExt = new CComboBoxExt();
m_pcComboBoxExt->Create(...)
Since this is now a pointer, don't forget to call DestroyWindow() and delete the pointer on termination.
This solved my particular problem - if your control is declared in the same way, consider giving it a try.
I'm using Prism pop-up region and the popup is modaless. When I tried to change Prism sample codes to replace .Show() by .ShowDialog() command, the codes become unstable. So, I need to keep the current codes intact and think of a work-around: change to modaless mode to be modal mode.
I don't know how to do that and/or if that is possible or not. Please share if you know how to. Thank you!
If you are using the Stock Trader Reference Implementation and the RegionPopupBehavior and the DialogActivationBehavior then yes you can. You should only have to change the PrepareContentDialog method of the DialogActivation behavior method from Show() to ShowDialog().
The reference implementation example is not very robust, and I ran into problems creating a more robust popup with the sample code. However, once you tweak the behaviors, you can get it working well.
If you provide more details about your specific problem, I may be able to provide more help.
I have a button on a toolbar that has its command set to "MyControl.Print" (for example).
In the control the command is added to the command bindings including both the Execute and CanExecute.
The control is within a window with other controls docked appropriately.
I am finding that for the Print button to be enabled I have to "select" MyControl first which does not provide a good user experience and indeed causes various "bugs" being raised and lots of confusion.
Is there a way that I can ensure that the button is enabled whether or not the control has been "selected"?
Since the CanExecute doesn't fire, I think you might be looking at the major downside to RoutedCommands - the way they tunnel and bubble can leave a highly composed interface unable to have commands arrive anywhere useful. For this reason we ended up moving to DelegateCommands from (I think) the Microsoft CAG. Not any of the other stuff, just the commands. Works a lot better, and isn't tied in to the interface so tightly.
Oh, the other response raises a good point. I assumed you meant that to ever print, your MyControl needed to have keyboard focus. Is it only the first time and after that it works?
I recommend http://msdn.microsoft.com/en-us/library/ff921126(PandP.20).aspx as a pretty good starting point. You don't have to worry too much about the IActiveAware up front, since you're hoping for this command to be available all the time (or at least let its availablity be determined by CanExecute).
CommandManager.InvalidateRequerySuggested will force the command manager to re-call all of your CanExecute methods and should disable the button. Perhaps call that onload?