I have a simple image view. Which I don't want to be read by the accessibility clients. I tried the solution given here. However this solution didnt work. Also I have one limitation. I want to support OSX 10.9 Hence I cant use accessibilityElement Property provided by AppKit since its only available from 10.10
Please let me know a simple way to make certain elements inaccessible for voiceover clients.
Also I would to know the 10.9 equivalent of accessiblityElement.
Most methods in the NSAccessibility informal protocol were deprecated in 10.10 in favor of property-based accessibility configuration. Prior to 10.10, you would mark elements as accessible (or not) by overriding accessibilityIsIgnored().
In modern versions of macOS, you can use accessibilityElement for this. When seeking to hide an NSControl, though, it's important to use the control's cell to hide the element from all flavors of accessibility. (VoiceOver, Switch Control, Hover Text, etc.) So in the case of an NSImageView you would use:
myImageView.cell?.setAccessibilityElement(false)
Related
The NSTabViewController was only introduced in OS X v10.10, so NSTabView already provides everything you need for creating a tab view. When would you use a NSTabViewController, and is it only there to be subclassed?
I would use NSTabViewController to get rid of a lot of code I used to have to write to have a tab view and transition between those views (most often done in Preference windows in Mac apps).
You'd obviously have to be 10.10 only, but these days that's a safe bet.
As for subclassing it, judging by the api I'd start without sub-classing it. You can set the style, the transition options (a nice benefit of using it!), and then call addTabViewItem: and let it do it's stuff.
If you compare iOS & OS X, you will feel OS X is bit deviated from MVC. OS X default 'new project' opens with AppDelegate as compared to iOS with 'ViewController'!
Now, it seems, Apple decided to make it by adding Controller as well. So that the view NSTabView is controlled by NSTabViewController.
And yes if you design to subclass it and use that should reduce your job. Same thing is mentioned even in Apple Documentation.
Context:
OS X Application implemented in Cocoa/ObjC
Xcode 6.1
Base SDK: 10.0
Deployment Target: 10.8+
Question:
In my app, I have a custom NSView subclass which implements NSDraggingSource. I'm using the new NSDraggingSession-based API (not the old deprecated one).
I have my dragging source fully implemented, no problems.
I am already implementing:
-[NSDraggingSource draggingSession:movedToPoint:]
I would like to additionally do some hit detection within this method and depending on the results of that hit test, possibly cancel the current drag session programmatically.
So: What is the best way to cancel/terminate the current NSDraggingSession programmatically? (preferably from -[NSDraggingSource draggingSession:movedToPoint:])
It might be nice to also be able to specify the NSDragOperation upon termination too.
Notes:
I've tried calling -[NSResponder cancelOperation:] on my custom view, thinking this might have something to do with dragging sessions, but that doesn't work. I get an exception with unrecognized selector.
I DO NOT need help doing hit detection.
I DO NOT need help implementing NSDraggingSource in general.
We have a nice functionality in IOS to know whether UIAccessibility Voice over is active. The function to use is UIAccessibilityIsVoiceOverRunning(). I would like to know whether we have a similar functionality for UIAccessibility switch control. I am not able to know whether the user is in switch control mode or not i.e whether scan is happening or not. How to identify whether the user is in switch control mode of UIAccessibility?
Since iOS 8 there is UIAccessibilityIsSwitchControlRunning.
It's not as easy as you'd like. From my interactions with Apple, the switch control and possibly other aspects of the UIAccessibility API isn't as thoroughly implemented as VoiceOver.
What I have found is the following:
Note that this container view creates the array of accessible elements only when methods of the UIAccessibilityContainer protocol are called. As a result, if iPhone accessibility is not currently active, the array is not created.
At this link.
Which suggests that one way is to record when if calls are made to methods of the UIAccessibility Container, and if they are, then accessibility can be considered to be ON, be it VoiceOver or Switch Control.
I have checked the restorable option on my NSWindow
When I move my application and change its size and close/reopen my application it sets the window size and position to the last size and position
but this doesn't happen on every computer where i test it. it only happens to a few computers
they don't have special settings regarding the resume.
Does anybody have any experience with this?
But this doesn't happen on every computer where I test it. It only
happens to a few computers. They don't have special settings regarding
the resume.
Actually, they do. Take a look into the System Preferences > General pane. There should be an option named “Close windows when quitting an application” which is responsible for the restoration behavior. Additionally, in OS X Mountain Lion, Apple changed default behavior and now the app restores its state only when you quit using Command-Option-Q.
So, you probably should check which OS X version is installed on another Mac, and which preference is selected in the General pane. Hope this helps!
One thing you should know is that checking the "Restorable" option in IB only changes a window property. The actual restoring and saving is in your hands.
First, you have to conform to the NSWindowDelegate protocol and implement the
-window:willEncodeRestorableState:state and -window:didDecodeRestorableState:
methods that encode and decode your window properties (For example your windows frame, which you obviously get by calling [myWindow frame]).
You also need to conform to the NSWindowRestoration protocol and implement +restoreWindowWithIdentifier:state:completionHandler:. (make sure you set your class to restoration class, with the setRestorationClass method)
For additional, more in depth, information, you can visit this Apple Documentation document here.
If all you want is to restore the window's frame use setFrameAutosaveName:.
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/WinPanel/Tasks/SavingWindowPosition.html
I have a general question for Xcode programming and the usage of the Xcode tools.
I am quite new (4 months) in iOS development and I almost never used the Interface Builder for my purposes. I always created instances programatically. My question is basically if you think i should get used to work with IB or should/can i proceed like i do now?
If you are fine with defining your UI programmatically, then I do not see any issues with that.
Interface Builder allows you to "graphically" define your interface, and this can be an invaluable tool for playing with your UI prototypes, but apart from that there is nothing that you can do in IB that you cannot do programmatically.
In my case, I see that it depends on the kind of UI that I design. When I need a pretty basic UI, the IB is unbeatable for me. On the other hand, when my UI tries to be a bit custom, then I prefer doing everything programmatically.
An interesting point is that you could use IB to design your UI, deciding on sizes and positions of your elements, and the create it programmatically.
Yes you should use IB, basically xcode having IB for ease of development, no need to setting controlls by using coordinates and each time see their visibility by running the app.
just drag and drop and at the time of making the views, you can see hows your screen going to look.
Also using IB is not a typical task so,start development using IB.