I have a non-editable text view (I can make it a text field, it doesn't matter). I change it programmatically when a user presses a button. I want VoiceOver to announce the change without moving the cursor. So the VO cursor stays on the textView/Field and when the text changes, just announce the change.
I'm trying to get this to work with a braille display.
I've tried posting an NSAccessibilityValueChangedNotification but so far I get absolutely nothing.
I don't know if it's the same in OS X, but in iOS land, you might accomplish this by posting a UIAccessibilityAnnouncementNotification.
In the OS X 10.9 SDK, it appears that there's a similar notification available in Lion and beyond called NSAccessibilityAnnouncementRequestedNotification. It takes a userInfo dictionary instead of the simple NSString that UIAccessibilityAnnouncementNotification takes, but it should do what you're asking.
Good Luck!
Related
I need to display a tooltip over a window. I'm creating a second window with the tool tip and using SDL_RaiseWindow() to bring it to the top. However, doing that causes the tooltip to steal focus which is not what I want. Is there a way to bring a window to the top without changing focus?
Also, is there a way to set focus (mouse and/or keyboard) without changing the Z order of the windows?
The answer offered by Neil will only work under X11 as SDL_SetWindowInputFocus() is only implemented for that environment. In essence, the desired behaviour is otherwise not achievable. I have seen that there is a feature request in the SDL forums for an overload of the SDL_RaiseWindow() function to include an optional bool parameter to indicate if the raised window should also receive the input focus, or not. I hope they do implement that.
In any case, the support for multiple windows under SDL 2.x is a little weak. There is no built in support for the Z-order of different windows, and trying to build one based on the "painter's method" works, but leaves one no control over the input focus.
Old question, but this came up during my own search. You could try SDL_RaiseWindow() to bring your tooltip to the top, then use SDL_SetWindowInputFocus() on the main window to switch focus back to it.
I got this working sufficiently for my tooltips on mac by using SDL_WINDOW_ALWAYS_ON_TOP flag with SDL2:
SDL_CreateWindow(tooltip_window->name, x, y, w, h,
SDL_WINDOW_OPENGL | SDL_WINDOW_BORDERLESS |
SDL_WINDOW_ALWAYS_ON_TOP);
SDL_RaiseWindow(windowThatShouldHaveFocus);
// ...render what you want on that tooltip (SDL_RenderClear, SDL_RenderCopy, SDL_RenderPresent) & hide it with SDL_HideWindow
And when showing the tooltip:
SDL_ShowWindow(tooltipWindow);
SDL_RaiseWindow(windowThatShouldHaveFocus);
My MacOS Cocoa application displays a window of static text, meaning it should not be changed by the user, should not be first responder, etcetera. The only thing that happens to the text is that each word of it changes color (from "idleColor" to "highlightColor", and then back again) at a specific point in time. It is similar to a Karaoke display - individual words change color, and then change back, under program control, based on a list of timed events.
All of this works beautifully under MacOS 10.7 and 10.8. BUT, under 10.9, the text color does NOT change UNLESS I click in the window and continually move the cursor around, so I am manually highlighting (and un-highlighting) some of the text, continuously. If I do this, the regular words behave as intended. Essentially, it feels like the OS is refusing to update the window under program control, unless I am forcing it to update by manually performing something that requires the UI to respond.
The code that performs the color changes is as follows:
if (sEvent.attribute == HIGHLIGHT_ON) {
[sTextView setTextColor:highlightColor range: currentRange];
textIsLitUp = YES;
}
else {
[sTextView setTextColor:idleColor range: currentRange];
textIsLitUp = NO;
}
[sTextView setNeedsDisplay:YES];
(sTextView is a subclass of NSTextView.)
Now, if I comment out that last line, then I get the same, incorrect behavior under 10.7 and 10.8. In other words, under 10.9, the setNeedsDisplay method is not working, or not working the same way.
Does anyone have any ideas about working around this, or have any other light to shed on the problem? Or am I doing something terribly wrong? It is CRITICAL to the application that the changes to the textColor happen without latency!
EDITING MY QUESTION - to answer it:
Found the answer elsewhere here! I needed to call setNeedsDisplay on the main thread - it was in a secondary thread. The weird thing is that it always seemed to work fine under 10.7 and 10.8. It only broke under 10.9. So I just changed this:
[myTextField setNeedsDisplay:YES];
To this:
dispatch_async(dispatch_get_main_queue(), ^{[myTextField setNeedsDisplay:YES];});
…and it seem to have worked. Hope this helps someone else…
You don’t want to do any of the changing of AppKit objects in non-main threads—it’ll work sometimes, maybe even often, but then every once in a while it’ll crash, and you’ll wonder why. So:
[sTextView setTextColor:idleColor range: currentRange];
needs to be on the main thread, too.
I have a simple form (NSWindow) with 3 text fields. NSWindow's initialFirstResponder is 'pointing' to the first field (NSTextField). All three text fields are circularly linked to each other via nextKeyView.
Problem that I have is that when I start the application from Xcode it'll focus on the text field that was last active (in focus) when the application closed.
So for example, if I name text fields A, B and C and initialFirstResponder is set to A. Now if I start the application, focus on B, and close the application, next time I start it, the focus will be on B.
Why is that and how would I fix this?
(Sorry if this is a trivial question, these are my first steps in cocoa...)
EDIT:
This is on OS X Lion 10.7.1, Xcode 4.1.
EDIT 2:
I found a way to "fix" this... In the main window (or any window for that matter) XIB/NIB file, click on "Attributes Inspector", then uncheck "Restorable" box. Now the application will not store the last position and so the initialFirstResponder seeing will be respected and followed accordingly.
Welcome to Cocoa! :) I suspect this is happening as part of the new user interface preservation features in OS X Lion. (In fact, I just created a simple app with 3 text fields, and I see this behavior too.) Because windows automatically restore themselves, you will see a lot of this behavior happening automatically even if you didn't implement it. This is probably desirable — most applications will work this way, and the user will come to expect it.
However, if you really want to disable it, you can probably do so by subclassing NSWindow or perhaps NSTextField and overriding -encodeRestorableStateWithCoder:. But, I definitely recommend you leave the default behavior alone.
Edit with a little further information: the app state seems to be stored in ~/Library/Saved Application State/com.yourapp.savedState. There you can see a plist file with information about the windows. The other files don't seem easily readable, but they probably contain information about which field is first responder, etc.
Despite this thread being almost 10 years old I'll gonna add an answer. Just about one month after the answer from jbandes OS X 10.7 Lion was introduced.
Following a quote from NSWindowRestoration.h
#interface NSWindow (NSUserInterfaceRestoration)
/* Determines whether the window should be restored on relaunch. By default, windows with NSTitledWindowMask set in the styleMask are restorable, and windows without it set are not.
*/
#property (getter=isRestorable) BOOL restorable API_AVAILABLE(macos(10.7));
this is my first post, wish your help.
In Mac OS (10.5 or 10.6), I want to find the element at the specified coordinate in screen.
If you have ever used UIElementInspector, you will konw exactly what I mean. Move mouse cursor around with UIElementInspector running, you will get a detail description, which is what I want, about the element under the mouse cursor.
I know Applescript is powerful enough to do many things, and we can add additions to it to fit some special needs. Extention can be performed using Object-C, Python, perl, etc.
And since UIElementInspector is implemented and provided in Mac OS 10.6, there must be ways to realize my requirement.
Any language, any implementation will be helpful.
You won't be able to do this in applescript. There's the problem of getting the mouse coordinates and the problem of knowing which application to ask for its UI Elements. You mentioned UIElementInspector... apple provides the source code for that so just download it and study it.
I'm using the Cocoa Accessibility API to try and modify the value of a text field (AXTextField) in another application, but I've run into a problem: my code correctly identifies and modifies the contents of the text field in question, and the text of the field visibly changes, but the changes aren't registered by the program I'm trying to control. Is there a way to do this in with the API without having to generate keyboard events?
Sample code:
AXUIElementCopyElementAtPosition(appRef,
clickPoint.x,
clickPoint.y,
&boxRef);
NSString *valueToSet = [NSString stringWithFormat:#"%f",amount];
AXUIElementSetAttributeValue(boxRef,kAXValueAttribute,valueToSet);
And the text field changes to the value specified in "amount" but the other program doesn't recognize the change - I have to go type the number in myself to get it to pick up the change (I can tell the difference, because the program responds when a new value is typed in the box). Can anyone point me in the right direction?
For posterity: Informed sources tell me that this is actually a bug in the application I'm trying to control. You can tell the difference by using UI Browser (http://prefabsoftware.com/uibrowser/) to try and set the value of the textfield; if UI Browser can't make the change stick, then the matter is out of your control.
Try telling the text field:
perform action "AXConfirm"
This is Applescript, but whatever the Cocoa equivalent is, it may make the change stick even if UI Browser can not (I've used it before).