I have implemented custom Win32 control based on RichEdit. I insert custom OLE objects into the rich text using method 'InsertObject' of the IRichEditOle. Custom objects just show some text and some more additional functionality.
This my control is similar to the Outlook's control which allows user to enter email addresses.
I have a problem with accessibility support. I want to implement functionality the same as Outlook. I want that screenreaders (for example Narrator or Thunder Storm) reads all the text including content of the inserted OLE objects.
I have tried to implement IAccessible interface which is returned on the message WM_GETOBJECT.
I return some reasonable value from the 'get_accRole' and 'get_accName'. Accessible role is 'editable text'. Also I return string which represents the whole control content from the method 'get_accValue'.
I tested my implementation using application Inspet.exe from Windows Kits. I see acc role, name value which I provides in the IAccessible methods.
THE PROBLEM IS: Screenreaders do not read the whole content of the control. Screenreaders read the only text entered to the control, but not the content of the inserted objects.
I suggest that Screenreaders do not use IAccessible interface for RichEdit control.
My question to the comunity: does anybody have experince with Accessibility support for the RichEdit control with inserted OLE objects. What I should provide for Screenreader?
Related
I’m able to get a reference to, for instance, the “Scripts” panel; but, although its constructor’s name is 'Panel', it doesn’t seem to have the show and hide methods like panels created through scripting, or the window property, etc.:
var scriptsPanel = app.panels.item('$ID/Scripts')
scriptsPanel.window // → “Object does not support the property or method 'window'”
scriptsPanel.show(); // → “scriptsPanel.show is not a function”
It does have some of script-created Panels’ properties, though:
scriptsPanel.visible // → true or false
What are standard panels’ methods and properties, and where are they documented?
There are several places where the DOM objects are documented, Adobe's official way would be to use the ExtendScript Toolkit to browse the objects and their methods and properties (in the ExtendScript Toolkit go to Help > Object Model Viewer).
Having said that, most ExtendScript users seem to find this browser cumbersome to use, so there are a few pages online that document the InDesign Object Model.
I personally use and prefer the InDesign ExtendScript API by Gregor Fellenz, but another popular one is Jongware's Adobe InDesign CS6 (8.0) Object Model JS viewer (that seems to be not updated anymore for more recent versions of InDesign). I prefer Gregor Fellenz' page, because it has a search function and I find it a bit easier to navigate.
The properties and methods of a panel in InDesign you could find here. Note that there is also the panel object of the ScriptUI, which is documented here. ScriptUI is Adobe's script language to create user interfaces. So the two panel objects have different methods and properties, that's why one of them didn't have the show() method.
As you have noted, this leads to the somewhat confusing fact that there are two different types of objects with the same constructor name Panel. However, there is no real ambiguity in the use of them, as the panels that are native to InDesign's UI are always children of the app object, whereas the panels that you create in a script via ScriptUI are always children of other ScriptUI objects. The same goes for other DOM/ScriptUI name pairs, such as window.
Note that the fact that there is a panel object in InDesign means that there is also a panels collection object, which has properties and methods to work with a collection of panels. This panels object is documented here.
The application I'm working on uses a custom text editor. The problem is that it therefore doesn't employ the Mac's now-standard long-press key accent popup, i.e., holding down 'A' will produce "aaaaaaaaa" instead of the "à á â ä..." window.
Anyone know if it's possible to programmatically call/otherwise implement that accent popup?
Properly handling key events so that they interact properly with the system is discussed in the Creating a Custom Text View section of the Cocoa Text Architecture Guide. You should also familiarize yourself with the Handling Key Events chapter of the Cocoa Event Handling Guide (although it's a bit outdated; in particular, it refers to the deprecated NSTextInput protocol which has been replaced by NSTextInputClient).
The basic gist is that you should send key events through either -[NSTextInputContext handleEvent:] or -[NSResponder interpretKeyEvents:], implement action methods on your view, and also have your view class adopt and implement the NSTextInputClient protocol.
You acquire a reference to the appropriate NSTextInputContext object from the inputContext property of NSView.
Sending the key events through one of those handler methods is how that press-and-hold feature gets activated. The NSTextInputClient protocol methods are how it ultimately interacts with your text view's document model. When the user selects a character from the popover, the feature uses that protocol to actually replace the initial character with the final one.
This will also allow your text view to handle Asian input methods.
I'm working with VB6 and I have one form with multiple tab controls.
When I drag and drop any control in form it shows me this error:
VB6 has a limited number of named controls per form. To add more controls, you can use a control array. That means, give some related controls the same name, then you can access them by name and index number. So instead of OptionAlways, OptionMaybe, and OptionNever, you could have Option(0), Option(1), and Option(2).
Also, if your dialog is very complex and most of its features are rarely needed, consider moving some options to additional dialogs behind an [Advanced...] button.
In my WinAPI program I use PropertySheet for a settings dialog box. I use property sheet with pages (tabs), i.e. I use PSH_PROPSHEETPAGE flag. But the software now have too many parameters for such a type of property sheet. So I want to use PropertySheet with treeview: the treeview on the left and the page with paramerets for the currently selected item in the treeview - on the right.
How can I do this? Can my current property sheet be modified for this and how?
(using only WinAPI, no MFC)
Standard property sheet is no longer good enough for you, so you basically have two choices here. You can either design a window (modal or modeless, dialog based or not) to host all your controls in a single view, with tree view, possibly tab control as well, and showing/hiding elements to follow tree view selection. And you will move all your controls into this window.
Or instead, you can create a similar window which hosts property pages. On tree selection change you will switch property pages as if they are selected by tabs in standard property sheet. The point is that you can use your existing pages intact making this new settings windows imitating behavior of standard property sheet. This is perhaps a more complicated thing to do, but should be flexible enough to do once and accept various pages, and you don't also need to touch your existing pages code leaving it good for both standard and this custom sheet with a tree.
Both ways assume you need to do quite some work since you are giving up using a standard piece of code - the property sheet window.
I have a grid control in my language which needs to be recognised as a grid (or table) control in order to get its all properties, when I'm using accexplorer32, it's recognising the grid as a valid table and giving back all properties, where I try to read these properties with api, it's giving an error, what could be theproblem?
Im using oleacc from system32 and trying to read properties using IAccessible interface.
Random guess - did you CoInitialize()? Without this, some IAccessible stuff will work - mostly for plain HWNDs and the system-provided controls like buttons - so it's easy to forget it because lots of stuff works at first. But without it, custom IAccessibles won't work. (Also, what error are you getting? Always give as much information as possible in your SO questions!)