I have a XAML form on a desktop application running .net 4.5 that dynamically changes the forms displayed on the window based on the selected comboBox.
My issue is that JAWS accessiblity software is reading the my combobox name incorrectly. Instead of reading the correct label for the field it's reading a hidden label.
Is there a .Net accessibility class that will help for screen readers or is there a XAML .Net attribute similar to the "aria-hidden"? Which hides fields from screen readers, which I could do dynamically.
So as we hashed out in the comments, JAWS adopted full UI Automation support years ago which provides folks on the dev end multiple quick/easy ways to get around some of the Accessibility hurdles.
For your instance it's all about AutomationProperties to instruct the reader what it actually cares about. Kind of an adhoc equivalent to aria stuff you're probably familiar with from the HTML world.
In any event, AutomationProperties.LabeledBy (or in other scenarios AutomationProperties.Name) give you a quick way to define the readers only respected string context to define an object or a section with a description it will apply only to that object, or to that object/panel and it's children as the source of truth as far as the reader is concerned.
Hope this helps, I mean who doesn't love being a hero? heh, cheers!
Related
I am modifying a Winforms application to be accessible via Dragon Professional 15. I have also recently added support for screen readers (including JAWS and MAGic) so the application has been, for the most part, reviewed in order to ensure that the AccessibleName (and, where appropriate, AccessibleRole) property is filled out.
Dragon does fairly well with most of this application but there are parts with which it utterly fails to operate. After a lot of trial and error, I was able to determine that the cause of the problem was the use of TableLayoutPanels in my application. Any control that resides in a TableLayoutPanel is not consumable by Dragon (ie. when I speak the AccessibleName value, Dragon cannot find the control). As an example, the button in this document tree works just fine in the following configuration:
(NB: The noFocusCueButton class derives from Button and has only minor changes concerning visual aspects of the class.)
In this configuration, I can speak the AccessibleName of the noFocusCueButton and Dragon will recognize it and click it. However, as soon as I move to this configuration:
...Dragon can no longer detect and interact with the noFocusCueButton. I have searched for some property on the TableLayoutPanel that might explain this but I do not see anything obvious. I have also searched for other people encountering this problem but have not come up with anything. Any SO experts out there know anything about this?
In what can only be described as "the story of my life", I found the problem in less than a few minutes after posting the question (though I had spent hours on it beforehand).
Evidently, at some point, the AccessibleRole property of the TableLayoutPanel had been set to List. Setting it back to Default fixed the problem.
MSDN's documentation for the TextBox's ShortcutsEnabled property states that:
The TextBox control does not support the CTRL+A shortcut key when the Multiline property value is true.
... but why? Kaitlyn has mentioned below that both the TextBox and the RichTextBox derive from the same base class TextBoxBase, and yet the RichTextBox control supports the shortcut natively.
It's easy enough to add it back in manually, and there's plenty of questions answer how to do this, but I can't think of why they would go out of their way to disable this feature in this specific circumstance.
What are the technical reasons?
To quote someone else on SO, it is:
probably because TextBox wraps the native Windows EDIT control, which only supports a subset of the shortcuts.
Quoted from Frédéric Hamidi at https://stackoverflow.com/a/5893879/3472690
After some research, it seems that the native Windows edit control that Frédéric mentions is this one, at MSDN, regarding Edit Controls.
And as Alan Macdonald says in a comment to that very same answer linked above...
Terrible feature of multiline text boxes
EDIT:
Found another potential reason. As quoted from DMA57361 of SuperUser,
As a shortcut, Ctrl+A = Select All is not something implemented by Windows.
It will only work in those programs that implement this shortcut themselves, not universally across the system.
An additional comment to DMA57361's answer by KCotreau of SuperUser also corresponds with what xpda said about compatibility (names removed from the quote):
it is not implemented in XP or Server 2003, but it is implemented in Windows 7 and Server 2008 (and probably Vista), at least for the Run box. So your system does not technically have a problem...it just lacks a feature.
As for more information from MSDN themselves, and which corresponds with the other quotes above... the "About Edit Controls" article says that:
Rich edit controls support many features not available in system edit controls. For more information, see Rich Edit Controls.
Additionally, there are limits on edit controls, as they are, as quoted from this article, also from MSDN (but the Developer Network section rather than the Windows Dev Center, which I'm not sure what difference that makes...)
Edit controls were designed to enter, display, and edit small amounts of text. They were not meant to be the basis for large-scale text editors.
It also, as xpda said, seems to have been very well intended to act like so, or they simply didn't want to bother fixing it, as quoted by a reply to an issue regarding multiline textboxes not supporting the Select-All shortcut on the Visual Studio feedback section:
We have evaluated the issue that you have reported and at this point in the product's lifecycle, it does not meet the criteria to be addressed. This evaluation is carefully done and considers many aspects including the cost of the fix, implications of the change, and the number of reported instances of the issue.
And finally, to further explain why this is by design... and why it would be for "compatility"... there is this quote from a Shuja Ali on a certain CodeGuru forum, saying:
It never used to work in VB 6.0 and .NET 1.1
To further "support" the quote from Shuja Ali, the TextBoxBase.ShortcutEnabled Property is new for .NET Framework 2.0, and the Ctrl+A shortcut already doesn't work at that stage, as evident by the comment by a hemantpurkar to that article.
Therefore, to condense all the above research into a single sentence...
The inability to use the shortcut "Ctrl+A" has existed since the very first version of the .NET Framework where shortcuts are supported properly (2.0), and Microsoft has been too lazy to fix it ever since, thus it is claimed to be "by design" and left like that for "compatibility".
The official answer is that it's "by design." Probably this was done to maintain compatibility once a long time ago. You can use a RichTextBox to get all the shortcuts by default, including Ctrl-A.
Is it possible to visualize an object (its properties along with their values) and print it out (dump it - similar to serialization) to a WPF control, such as TreeView or PropertyGrid to inspect the object?
The goal is to display the contents of any arbitary object (not only for debugging purposes).
For further clarification: I'm not looking for any debugging tools or ways to show the WPF Visual Tree. This question has only partially something to do with WPF -> WPF is only the media to display the object dump because controls may vary between WPF and WinForms.
The output should be hierarchical for nested object instances, lists etc.
I think you should take a look at Snoop
http://snoopwpf.codeplex.com/
This program will allow you to navigate the WPF tree of any running application. Debugging is not required for this tool and it's possible the tool doesn't work with debugging. Typically I use it in non-debugging scenarios to see how my WPF controls are actually laid out and what values they have for various properties
I believe what you are looking for is the System.Diagnostics.DebuggerDisplayAttribute
You mean besides the WPF Tree Visualizer? there is Mole, which is not free anymore, but very good.
Edit:
Reading your edited question. You are explicitly naming the PropertyGrid, I take it you've already tried Extended WPF Toolkit's PropertyGrid?
So you want a control that displays at runtime the fields of a class. You will find plenty of articles regarding that by looking for "Property grid". Its not directly what you want but its a start. You basically iterate via reflection over the fields of a class, and display them in a ListView/TreeView. But, and this is were the difficult part starts, determining which fields to show and which to hide, handling with very different types and primitives and allow to edit them with type conversion (like string to Rect, point, color etc) is a very complex matter.
This control might give you a good starting point.
There are various existing controls that lets you view properties as Property Grid.
http://www.codeproject.com/Articles/87715/Native-WPF-4-PropertyGrid
https://wpftoolkit.codeplex.com/wikipage?title=PropertyGrid
https://wpg.codeplex.com/
Based on complexity, License and features they present, you will have to choose one, all of them are free for sure.
I've been searching for the answer to this for months; Snoop, Spy and all the others didn't work for me, due to thread ownership violations.
Microsoft has a windows-tool that allows you to select any running UI Element and view the Element's accessibility data:
inspect.exe
https://msdn.microsoft.com/en-us/library/dd318521(VS.85).aspx
It's available in the windows Software Development Kits which need to be downloaded and installed, and located in:
C:\Program Files\x86\(win-version)\bin\(cpu-architecture)\inspect.exe
Ive been working on a C# project for a while now and I fell it needs change its look.
I have found a UI kit that I really like, which can be seen below:
http://medialoot.com/item/transparent-ui-kit/
Does anyone know how to do this?
Thanks
EDIT: Im using WinForms
EDIT2: Maybe I should convert over to WPF? Is this doable?
You can subclass most common controls and draw their appearance yourself. However, unless for novelty applications I doubt your users will thank you for doing so.
Your example is a library of controls. For you to have an appearance such as that you'll have to create or acquire a similar library of controls and replace all your controls in your project to get that appearance.
If you want to update colors (background, foreground, etc.) and such you can make a class that recurses through controls and sets the settings using reflection and a switch statement to process each control. Then just run this on each form before you show it. One word of caution about this, some controls don't respect your changes and get overridden with themes from the OS (datetimerpicker being the biggest culprit). You'll also need to consider whether your users will appreciate the extra work put in for color/appearance changes.
If you don't have very good design skill and have a good know how about creating such templates, its better to buy them.
And C# is just a language. You're looking to create templates and skins for either for ASP.NET website/application or for windows forms.
Have a look at DevExpress Skins
If you can afford it.
I've been struggling for a long time with basic controls that Windows Forms offers to developers, but... right now, I am developing an application that requires more advanced control than normal "TextBox".
Since, at this time, my application is about memory management, I have to show in the form, the process memory in bytes (or other type of data) to the user, giving it the ability to modify it as he wants.
The problem comes here, because... if I show the data in a TextBox, it only allow me to display the data in read-only text because if I let the user modify the textbox directly, it will be very messy and unaesthetic.
I was reviewing some projects on SourceForge about C# and the handling of hexadecimal data, and i found a good project, called Be.HexEditor, which has a control developed and designed by its creators, but in GDI+.
The control is called HexBox, and that's just what I need to get.
Do any of you know how to develop a control like this?... I would greatly facilitate things. What kind of manuals/books should I read to learn this kind of development? I ask this because I ignore everything about GDI+.
Or... is there other way for do it?
I would use a textbox to show to the user the current value and another textbox to enter the desired value (maybe a slider will work better).
I think you'll find it's GDI+ that you have to learn
http://www.amazon.co.uk/GDI-Programming-Creating-Controls-Programmer/dp/1861006314
You may still be able to write controls in WPF and then include them somehow into your winforms app, but if you need to push pixels GDI+ is the only way.