I have a simple desktop app where a TextField should be focused when the window loads. I have this working, but it's a little annoying that, having loaded the users content into the TextField, the entire contents of the field become selected automatically. The user may want to start editing the content, but they will rarely/never want to replace it all at once (imagine a text editor doing this, to see what I mean).
I see there is an Action for selectAll: but what I want is the opposite Action of selectNone:
I tried passing nil to the selectText method, but that doesn't work:
textField.selectText(nil)
I found a number of answers on StackOverflow that mention a selectedTextRange, but this appears to be outdated, because Xcode 6.3 doesn't recognize this as a valid property on TextField.
Can anyone explain how I do this?
It's been a while since I've dealt with NSTextFields to this level (I work mostly in iOS these days).
After doing a little digging I found this on the net:
NSText* textEditor = [window fieldEditor:YES forObject:textField];
NSRange range = {start, length};
[textEditor setSelectedRange:range];
window is the window containing your field, textField.
This requires the field editor to be managing your field, what can be done simply by previously selecting the whole text of the field using the selectText:sender method.
Here is the final swift code that I got working based on what Duncan C posted:
if let window = NSApplication.sharedApplication().mainWindow {
let textEditor = window.fieldEditor(true, forObject: textField)!
let range = NSRange(0..<0)
textEditor.selectedRange = range
}
Related
What I want to accomplish:
I need a checkbox with a title text that dynamically wraps and breaks on multiple lines depending on a dynamic width established by the parent view. I need a solution that I can use in IB and that will display there as it's shown at runtime. I'm using XCode 13.1, working in a XIB-File targetting MacOS.
What I'm doing:
I create an NSButton in IB. In the attributes inspector I set its style to Check, under "Control" I choose Word Wrap for "Line Break" and finally I set a very long text as the title such as Asd Asd Asd lit tle words and many of them asd asd lit tle ones.
What's happening:
When setting up the button as described above (case 1) and shrinking its width, it will be displayed - in IB and at runtime - like this:
When manually adding a line break to the title as suggested in this similar question by pressing Option + Enter (case 2, here after "them") the title starts wrapping correctly and all the other necessary breaks are generated:
However this solution is not applicable for my case since it only works for a static width, but my checkboxes need to adjust their width dynamically as described above.
Without that additional manual line break it's most interesting that apparently the checkbox is already reacting and changing its position according to the new wrapped height of the title while the title text itself is just clipped by the bounds of the control instead of being displayed in a wrapped fashion.
What I'd expect:
I'd expect the title to wrap in case 1. Since it doesn't: Is this a bug or a feature? How can I make case 1 work and get the title to wrap dynamically depending on its length and the width of the button? Do I just need to set another attribute in the inspector I missed so far? Or is there only a programmatic solution?
To answer the question why I don't use an appropriately short label: Don't ask me, I'm just a developer following specs & reqs and unfortunately I don't have a saying on what would be a good length of text here.
The credits for this answer goes to #Willeke's comment: "AppKit doesn't support multiline checkboxes." The interesting behaviour of the checkbox in case 1 suggesting otherwise seems to be just a glitch or bug.
What I ended up with: I opted for a workaround. I'm placing a checkbox-button (with Image Position "Image only" in IB) right beside a multiline-label, putting both in a custom view, adding the necessary constraints. With a few positioning adjustments I know have a solution that looks exactly like a singleline checkbox, that I can copy-paste in IB and that is solved by Autolayout - in IB and at runtime - without any additional code.
I'm new to the Xcode User Interface testing framework. I can successfully manipulate the screen elements, but cannot work out how to produce a meaningful assertion about what text is visible in a scrolling view.
The test I would like to write would go as follows: launch the app, type lots of text into a text view (enough that the first line scrolls out of view), assert that the first line of text is not visible, scroll the view back up to the top, then assert that the first line is now visible. Note that the purpose of this test is to ensure my app has wired things up correctly, not to test Apple's code.
XCUIApplication allows me to type into my NSTextView instance, and also allows me to scroll the associated NSScrollView. But how do I assert whether the first line of text is currently visible? The value attribute on XCUIElement provides the entire text content of the view, whether or not it is currently displayed.
The accessibilityRange(forLine:) and accessibilityString(for:) methods on NSTextView would be ideal, but I can't see how to access them as the UI test only has access to an XCUIElement, not the underlying NSTextView.
Have I missed something, or is there a better way to approach this?
If you set the accessibility identifier in the storyboard or in code for the text view you can get the text view via (assuming you gave it the id "textview1" and the window it's in has the default accessibility identifier of "Window"):
let textview1TextView = app.windows["Window"].textViews["textview1"]
but that won't actually get you what you need.
Instead, set the accessibility identifier of the scrollview and get that:
let scrollview = app.windows["Window"].scrollViews["scrollview1"]
Then use that to get the scrollbars (you should only have one in this case; you can use scrollbars.count to check.
let scrollbars = scrollview.scrollBars
print("scrollbars count: \(scrollbars.count)")
Then you can use the value attribute of the scrollbar to get it's value:
(you're converting a XCUIElemenTypeQueryProvider into an XCUIElement so you can get it's value):
let val = scrollbars.element.value
it will be 0 at the top and a floating point value when scrolled (one line of text in my test code showed a value of {{0.02409638554216868}}.
Documentation that will help you explore further:
XCUIElementTypeQueryProvider
XCUIElementAttributes
Note that you can put a breakpoint in the middle of your test, run it and then use the debugger console to examine things:
(lldb) po scrollbars.element.value
t = 749.66s Find the ScrollBar ▿ Optional<Any>
- some : 0
(lldb) po scrollbars.element.value
t = 758.17s Find the ScrollBar ▿ Optional<Any>
- some : 0.05421686746987952
and while in the debugger you can even interact with your app's window to scroll it manually (which is what I did between typing in those two po calls), or perhaps add text and so on.
OK OP now noted that they're interested in the specific text showing or not rather than the first line in view or not (which is what I previously answered above).
Here's a bit of a hack, but I think it'll work:
Use XCUICoordinate's click(forDuration:, thenDragTo:) method to select the first line of text (use the view frame to calculate coordinates) and then use the typeKey( modifierFlags:) to invoke the edit menu "copy" command. Then use NSPasteboard methods to get the pasteboard contents and check the text.
Here's a quick test I did to validate the approach (selecting the first line of text using XCUICoordinate as noted above is left as an exercise for the reader):
NSPasteboard.general.clearContents()
// stopped at break point on next line and I manually selected the text of the first line of text in my test app and then hit continue in the debugger
textview1TextView.typeKey("c", modifierFlags:.command)
print( NSPasteboard.general.pasteboardItems?.first?.string(forType: NSPasteboard.PasteboardType.string) ?? "none" );
-> "the text of the first line" was printed to the console.
Note that you can scroll the selection off screen so you have to not scroll after doing the select or you won't be getting the answer you want.
While setting up an NSAlert object to be displayed as a modal sheet in Xcode 5.0.2, I hit an interesting surprise.
I was planning on using beginSheetModalForWindow:modalDelegate:didEndSelector:contextInfo:
As I started to enter it, Xcode autofilled beginSheetModalForWindow:completionHandler: for me (even though I cannot find this in any NSAlert documentation).
I prefer to use completion handlers rather than delegate/selector as a callback mechanism, so I went ahead and tried it. I was pleasantly surprised to find that it worked perfectly.
Three quick questions before I commit to this.
Am I missing something in the documentation?
Is it "safe" to use this feature if it is undocumented? (i.e. will it magically disappear as mysteriously as it appeared?)
I'd rather not hardcode the response values based on what I'm seeing via logging. Does anybody know the "proper" NS...Button constants?
This call is “safe” but it’s 10.9+ only. Here it is from the header file:
#if NS_BLOCKS_AVAILABLE
- (void)beginSheetModalForWindow:(NSWindow *)sheetWindow completionHandler:(void (^)(NSModalResponse returnCode))handler NS_AVAILABLE_MAC(10_9);
#endif
It appears they just accidentally left it out of the current docs. The headers are generally considered the “truth” in Cocoa, though—they authoritatively tell you what’s deprecated and what’s new. (Unlike in X11, for instance, where the documentation was declared to be correct over the actual implementations or the headers.)
These are the constants you want to use inside your completionHandler block:
/* These are additional NSModalResponse values used by NSAlert's -runModal and -beginSheetModalForWindow:completionHandler:.
By default, NSAlert return values are position dependent, with this mapping:
first (rightmost) button = NSAlertFirstButtonReturn
second button = NSAlertSecondButtonReturn
third button = NSAlertThirdButtonReturn
buttonPosition 3+x = NSAlertThirdButtonReturn + x
Note that these return values do not apply to an NSAlert created via +alertWithMessageText:defaultButton:alternateButton:otherButton:informativeTextWithFormat:, which instead uses the same return values as NSRunAlertPanel. See NSAlertDefaultReturn, etc. in NSPanel.h
*/
enum {
NSAlertFirstButtonReturn = 1000,
NSAlertSecondButtonReturn = 1001,
NSAlertThirdButtonReturn = 1002
};
I have a long text in a gas TextArea and I want to scroll a line of text into view. I tried several solutions (setCursorPos, setSelectionRange), but the text is always displayed at the top; i.e. it never scrolls down to the position I want...
I did notice that the doc says: "This will only work when the TextArea is attached to the document and not hidden.". That shouldn't really apply in my case (I want the app to pop up at the specific position...), but I tried to set it before and after the app is displayed.
Here is the code.
....
var cursorPos=15;//just a test...
var fileString = "a very long text that I'm not putting in here....";
var mytextArea=myapp.createTextArea().setValue(fileString).setSize("100%","100%").setName("TextArea").setId("TextArea");
myapp.add(mytextArea.setCursorPos(cursorPos));
var doc=SpreadsheetApp.getActive();
doc.show(myapp);
myapp.getElementById("TextArea").setFocus().setCursorPos(cursorPos);
I must be doing something obviously wrong. Any suggestions?
Issue is here: http://code.google.com/p/google-apps-script-issues/issues/detail?id=1635
The issue response was: "Unfortunately this is a limitation of the underlying GWT technology" :( So no fix any time soon... : i.e setCursorPos(cursorPos) does nothing...
Have you tried wrapping the text area in a scroll panel and setting the position of the scroll panel?
I am exploring the newly exposed framework UI Automation in iphoneOS 4.0. Has anybody tested their application using this framework. I will appreciate any help.
I am trying to test a sample application that just contains a textfield and a button. I have written a script as
UIALogger.logStart("Starting Test");
var view = UIATarget.localTarget().frontMostApp().mainWindow().elements()[0];
var textfields = view.textFields();
if (textfields.length != 1) {
UIALogger.logFail("Wrong number of text fields");
} else {
UIALogger.logPass("Right number of text fields");
}
textfields[0].setValue("anurag");
view.buttons()[0].tap();
The problem is that the value of textfield is not getting set and no button is tapped. When I run the instruments only the view(with textfield and button) appears and then notting is happening.
There is a message in instruments "Something else has happened".
If your main window contains a button and a text field (in this order in the hierarchy) then your first line of code will return you the UIAButton element, so the next line is incorrect, because you're trying to call textFields() on a button.
The first part should look like this:
var view = UIATarget.localTarget().frontMostApp().mainWindow();
var textfields = view.textFields();
if (textfields.length != 1) {
UIALogger.logFail("Wrong number of text fields");
} else {
UIALogger.logPass("Right number of text fields");
}
And in that case I think there are two ways of testing the tap and text field. Like this:
textfields[0].setValue("anurag");
view.buttons()[0].tap();
or like this:
view.elements()[1].setValue("anurag");
view.elements()[0].tap();
And personally I prefer getting objects by using Accessibility Label instead of index. For more information look for a UIAElement Class Reference and take a look here:
UI Automation Reference Collection
All this stuff is gonna work only if the application is made with that accessibility thing (its own accessibility protocol: by tagging all its UI controls in Interface Builder with names, by setting the Accessability label to a unique value for the view). Or if you work with iPhone standard controls.
If the application doesn't contain anything like that, you won't be able to do much with UI Automation and will see only a 320x480 empty canvas.
You can check this link for some more details.
For example, I work on a OpenGL application that was not built with any accessibility tag and I cannot see anything through UI Automation besides a 320x480 empty form.