Just getting started on iPhone dev today and have run through Apple's HelloWorld tutorial:
http://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhone101/Articles/02_CreatingProject.html#//apple_ref/doc/uid/TP40007514-CH3-SW3
Couple of easy questions for you folks (sorry so long-winded but I'm hunting around in the dark here):
1) So I made MyViewController the delegate for the text field, in order to receive a message when the return key is pressed (textFieldShouldReturn). This seems inelegant because the method has to check which control sent the message. But to handle the touch event on the button the technique is different -- a custom message (changeGreeting) gets sent which could be associated with one or several buttons in Interface Builder, and I could create different messages for different buttons.
That seems much better and avoids the need to test in code which control sent the event. Why these two different approaches in the sample, is it just to demonstrate the two? Would it be possible to rewrite the sample only using the latter approach, or is there something fundamentally different between the text field's textFieldShouldReturn and the button's 'Touch Up' that mandates making the view controller a delegate for the text field?
2) When I position the text field near the top of the view, if it's a certain vertical displacement away from the grey status bar with the battery status symbol then it locks into place and you can see the vertical blue dashed line indicating the lock. In this mode, when I run the app the text field is too high, hard up against the status bar. I can resolve this by moving the text field very slightly so that the vertical dashed blue line no longer appears. Then the positioning seems relative to whatever's above the text field, as I can select a larger Top Bar in the Simulated UI Elements and it moves down nicely.
I'd expect to see some explicit property in the Attributes Inspector that says whether the layout is relative or absolute, but I can't find anything that changes between the two scenarios. Surely this is made more explicit somewhere in the Interface Builder UI?
Hope these Q's represent some easy points for someone...
1) You can connect the UITextField "Did End On Exit" event to an IBAction, similar to the Buttons "Touch Up".
The benefit of using the delegate is that you get a higher level of interaction for free with the UITextfield, without having to assign every event to an IBAction in interface builder.
2) In the Interface Builder Inspector, on the size tab (the little ruler icon) there are a set of controls which allow you to set the automatic positioning of a subview. I believe you are interested in the "Autosizing" section.
Related
I started writing test for a WPF application with FlaUI (UI Automation framework). Now I want to get the Visibility value of a couple of buttons.
These buttons are located on the same position in the WPF window. The first is a start button which will start a measurement. When clicked, the measurement button is replaced with a stop button. The visibility of these buttons are set in the code behind of the xaml and needs to be checked/verified.
With FlaUI I only get IsEnabled boolean and OffScreen boolean. But when using the Offscreen parameter, this boolean is not set or is set to the correct value for a couple of seconds but is changed again while the measurement is still running.
I also tried other ways, like looking for a clickable point of the not visible button. But those are not working.
Can this be done without extending the button class with an AutomationPeer and exposing a ValuePattern? I googled a bit but cannot find an (decent) answer. Hopefully someone can help.
I think an important part of your question is the word "replaced". Commonly a program draws one set of controls (in your case the start button) and later draws another set. Possible on top to hide the first, or possible by deleting them.
Commonly controls, including buttons, are drawn within other containing controls and so it may be that the button controls are not there at all, hence the visibility checks should be done on the parent or ancestor controls.
This Q&A seems related to the problem you are having and it may provide some more insight.
I'm working with an NSOutlineView on a macOS app and it provides disclosure triangles for items that can be expanded.
I'm also creating custom NSTableCellView items rather than using basic cell items. This allows me to create the cell how I want visually.
My issue is that when they're displayed, the disclosure triangle on the left is not centered vertically.
Notice how the disclosure triangles are not aligned properly. They're a bit lower than they should be. If you scroll away and come back, sometimes, they automatically align themselves correctly. Has anyone been able to fix this issue before?
For what it's worth, I'm using the following code as well for the cells.
self.outlineView.rowHeight = CGFloat(integerLiteral: 66)
self.outlineView.usesAutomaticRowHeights = true
It's hard to figure out what the problem is without seeing how you've set up your project, but I'm going to give it shot.
First, when usesAutomaticRowHeights is set to true, the outline view uses Auto Layout to position the cell views. Thus, you need to be utilizing constraints in your Storyboard or Nib file, or things will behave strangely (see: your picture). If I had to guess, the prototype cell view you set up in Interface Builder is having its autoresizingMask translated into Auto Layout constraints (which, generally, causes a boatload of problems).
What I would do is this:
Open up the Storyboard or Nib document containing the outline view.
Locate the prototype NSTableCellView instance that contains the street name text field in the Document Outline to the left of the canvas. (If you don't see the Document Outline, you can open it by clicking the item at Editor » Show Document Outline in the main menu).
Next, see if you have any constraints in place. If you do, remove them by selecting Editor » Resolve Auto Layout Issues » Clear Constraints under the menu item "section" that's titled All Views in ${YOUR_SCENE}.
Now, depending on what you're going for, there are different ways to go about setting up constraints, but here's what I would suggest. Assuming you want the street name to be centered vertically with the disclosure triangle, I would add a vertical constraint between the text field and its parent cell view like so:
With the text field selected in the Document Outline, click the Align icon in the lower right-hand corner of Interface Builder's main canvas area (see image).
In the popover that appears, check the checkbox next to Vertically in Container.
In the text field on the right side of the popover, enter a value of “0”.
Finally, click the “Add 1 Constraint” button.
You’ll probably see a red error (or yellow warning) sign show up, as the view has now opted into Auto Layout, but it only has a metric for its vertical position. So we now need to add some constraints to describe where the text field should be positioned on the x axis. Like before, we’ll define the constraints using the popover buttons on the lower right-hand side of the canvas:
Click the Add New Constraints button (the one to the right of the Align button).
On the diagram at the top of the popover, click the faint red lines on the left and right side of the white rectangle. This is telling Interface Builder we want to add leading and trailing constraints.
Now, enter the desired padding you want on each side of the text field. In the example image, I went with “4” points on both sides, but obviously, you can use whatever value(s) you think works best with your layout.
Finally, click the “Add 2 Constraints” button.
Any warning(s) that were present should now disappear, as we've added enough constraints to describe the position of the text field. In theory, you should now be able to build and run your project, and the text fields should be aligned with the disclosure triangles. With that said, there are plenty of other reasons a layout can get finicky, and considering usesAutomaticRowHeights is a new API in macOS High Sierra (and Steve Jobs is no longer there to beat it into Apple developers to make everything Just Work™), there could be issues that I'm unaware of.
Alternatively, you can set usesAutomaticRowHeights to false and have some object (e.g. a view controller, a NSObject subclass, etc.) conform to the NSOutlineViewDelegate protocol and implement the outlineView(_:heightOfRowByItem:) method to return any arbitrary height you want for different rows. The nice thing about sizing rows this way is that you can allow certain rows to be larger or smaller, depending on the role of the corresponding item. There are lots of tutorials on this, so I won't regurgitate a half-baked explanation here, but feel free to Google “Conforming to NSOutlineViewDelegate protocol” for more info.
Anyway, try the steps above, and see if they do anything for you, and if they don't, let me know. I can go as deep into the rabbit hole with you as you need, so just ask. Good luck!
For those like me who stumbled upon this issue many years later, here's the fix that worked for me, and requires a lot less work.
NSOutlineView has a function frameOfOutlineCell(atRow:) and the documentation states: You can override this method in a subclass to return a custom frame for the outline button cell
You can override the method in order to provide a frame that's actually in the vertical center of the row. And an important point that I learned from trial and error, is that you don't even need to provide that updated frame. Not sure if this is a bug or what, but for me, just calling super.frameOfOutlineCell(atRow: row) in the function override was enough to make the disclosure indicator appear in the correct location.
So my subclass of NSOutlineView is this:
class MyOutlineView: NSOutlineView {
override func frameOfOutlineCell(atRow row: Int) -> NSRect {
super.frameOfOutlineCell(atRow: row)
}
}
That's all. Hopefully that works for others as well!
Short version: I have a working solution using a UISegmentedControl but I don't like how it looks. When I use Safari, it "dims" either previous or next when it's at the beginning or end of the list of input fields. I can't convince a UISegmentedControl to do that, so how did they do it?
Long version:
I have a UITableView with cells that have text fields. The text fields take numeric inputs (floating point numbers, generally). That means I present the keyboard with keyboardType = UIKeyboardTypeDecimalPad. That also means no return button, so I need a good method to move between cells OTHER THAN touching the cells. I'd like to do it the same way as, say, iOS Safari does it - with a little toolbar that says "previous | next ... done."
I have code that does all of that (sets the textField.inputAccessoryView to be an instance of a UIToolbar with the appropriate buttons), using a UISegmentedControl for the previous and next button. I have that working so that next moves to the next cell and previous moves to the previous cell.
So why am I here? I can't get the dimmed previous/next behavior seen in iOS Safari to work with a UISegmentedController and I don't really want to implement all of that myself if I don't have to (at that point, my CCB will invoke one of the two rules it uses to reject changes: Rule 1) If I don't think it's a good idea, then I won't implement it; Rule 2) If it's easy, I'll probably do it).
(I would have posted pictures, but I'm too new to SO - sorry)
When I try to do the same thing it looks and acts like a Safari middle text field, but I can't seem to get it to look like the Safari version of first or last text field.
I've tried enabling, selecting, even changing the bar background color, but none of them seemed to work. The background color seemed to get closest, but I had to have 3 different toolbars based on when it was first, last, or middle, and even then it wasn't great.
Solved. The issue was that the "enabled" setting of the various segments as set in IB does not make it to the executable. I have to programmatically disable the previous or next segment in the view controller. Once I did this, it now appears as I want it.
When I set up the UISegmentedControl in IB, I set one segment to enabled and the other to disabled (== not enabled). In the debugger I started trolling through the settings of the various segments and found that actually setting the segment to disabled makes it work in the way I wanted.
For example, in the "nextToolbar" that contains a UISegmentedControl that is attached to "nextControl," only the Next button should be shown as active. That means I have to set the Previous button to disabled. The Previous button is at index 0, so disabling it means to do this somewhere before it's used (I put this in viewDidLoad:):
[self.nextControl setEnabled:NO forSegmentAtIndex:0]
Similarly, for the prevControl, where only the Previous button should be active, I use:
[self.previousControl setEnabled:NO forSegmentAtIndex:1]
We are trying to write a training manual application for the iPhone. On the top half of the screen is a diagram of a car engine, on the bottom half is some text. At the user repeatedly hits a "next" button, we highlight different parts of the engine, and in concert we highlight different parts of the descriptive text below.
We basically want "living text" in the text half, with the illustration following along on top to where the reader is in the text. What we'd like from the text is 1. user can scroll it using their thumb so possibly a UIScrollView 2. the software can explicitly drive a scroll to any part of the text (when they hit the "next" button). 3. the words in the text are interspersed with hotlinks e.g. "this is the camshaft... this is the piston..." and the user should be able to click on any of the keywords like camshaft, piston, and have the diagram highlight that. (The problem is not highlighting the diagram, its capturing the click). The text would have 300~400 buttons/links/keywords and about 600 words of text.
Since this is fairly similar to using a web browser, we tried using Apple's version of webkit using a UIWebView and handleOpenURL to register a service back to the app itself. But Webkit for internal links a popup comes up asking permission to access that link. Every single the user wants to go to a link (in our case just an internal event that we'd intercept so that we can highlight e.g. the camshaft). Tried to intercept the event from the HTML view, but that didn't work.
It seems like the best we can do is to abandon scrolling text, and make the text part more like flash cards or a power point presentation, breaking the text into custom UIViewCells with buttons inside a UIScrollView. However, this would impose an annoying constraint on the author that they would have to write everything to fit in the UIViewCells, sort of chunky.
Any ideas would be appreciated.
This is definitely something you can use a UIWebView for. Don't use handleOpenURL, rather, set your viewController as the webview's delegate, and override -webView:shouldStartLoadWithRequest:navigationType:. When this gets called, check the request, and pull out your link data from there.
It would probably be easier to implement that completely in JavaScript in the document you load in a UIWebView. You would have to use JavaScript (i.e. [UIWebView stringbyevaluatingjavascriptfromstring:]) anyway to achieve things like scrolling to a certain position.
Does anyone have any examples or resources where i might find information on scrolling text which is too long to display in a button control? I'm thinking something along these lines.
Display as much text will fit within the current rect with a '...' at the end to signify overflow.
Pause for say 1 second then slowly scroll the text to the right edge displaying the right part of the string.
Display as much text will fit within the current rect with a '...' at the beginning to signify overflow.
Start the whole thing over in reverse.
Is there an easy way to do this using the "core" or built in "animation" frameworks on a certain mobile device?
[edit]
Iwanted to add some more details as i think people are more focused on wether or not what i'm trying to accomplish is appropriate. The button is for the answers on a trivia game. It does not perform any speciffic UI function but is for displaying the answer. Apple themselves is doing this in their iQuiz trivia game on the iPod Nano and i think its a pretty elegant solution to answers that are longer than the width of my button.
In case its the '...' that is the difficult part of this. Lets say i removed this requirement. Could i have the label for the button be full sized but clipped to the client rect of the button and use some animation methods to scroll it within the clipping rect? This would give me almost the same effect minus the ellipses.
Here's an idea: instead of ellipses (...), use a gradient on each side, so the extra text fades away into the background color. Then you could do this with three CALayers: one for the text and two for fade effect.
The fade masks would just be rectangles with a gradient that goes from transparent to the background color. They should be positioned above the text layer. The text would be drawn on the text layer, and then you just animate it sliding back and forth in the manner you describe. You can create a CGPath object describing the path and add it to a CAKeyframeAnimation object which you add to the text layer.
As for whether you think this is "easy" depends on how well you know Core Animation, but I think once you learn the API you'll find this isn't too bad and would be worth the trouble.
Without wishing to be obtuse, maybe you should rethink your problem. A button should have a clear and predictable function. It's not a place to store and display text. Perhaps you could have a description show on screen with a nice standard button below?
Update with source code example:
Here is some ready to use source code example (actually a full zipped Xcode project with image and nib files and some source code), not for the iPhone, not using Core Animation, just using a couple of simple NSImages and a NSImageView. It is just a cheap hack, it does not implement the full functionality you requested (sorry, but I don't feel like writing your source code for you :-P), horrible code layout (hey, I just hacked this together within a couple of minutes, so you can't expect any better ;-)) and it's just a demonstration how this can be done. It can be done with Core Animation, too, but this approach is simpler. Composing the button animation into a NSImageView is not as nice as subclassing a NSView and directly paint to its context, but it's much simpler (I just wanted to hack together the simplest solution possible). It will also not scroll back once it scrolled all the way to the right. Therefor you just need another method to scroll back and start another NSTimer that fires 2 seconds after you drew the dots to the left.
Just open the project in Xcode and hit run, that's all there is to do. Then have a look at the source code. It's really not that complicated (however, you may have to reformat it first, the layout sucks).
Update because of comment to my answer:
If you don't use Apple UI elements at all, I fail to see the problem. In that case your button is not even a button, it's just a clickable View (NSView if you use Cocoa). You can just sub-class NSView as MyAnswerView and overwrite the paint method to paint into the view whatever you wish. Multiline text, scrolling text, 3D text animated, it's completely up to your imagination.
Here's an example, showing how someone subclassed NSView to create a complete custom control that does not exist by default. The control looks like this:
See the funny thing in the upper left corner? That is a control. Here's how it works:
I hate to say that, as it is no answer to your question, but "Don't do that!". Apple has guidelines how to implement a user interface. While you are free to ignore them, Apple users are used to have UIs following these guidelines and not following them will create applications that Apple users find ugly and little appealing.
Here are Apple's Human Interface Guidelines
Let me quote from there
Push Button Contents and Labeling
A push button always contains text, it
does not contain an image. If you need
to display an icon or other image on a
button, use instead a bevel button,
described in “Bevel Buttons.”
The label on a push button should be a
verb or verb phrase that describes the
action it performs—Save, Close, Print,
Delete, Change Password, and so on. If
a push button acts on a single
setting, label the button as
specifically as possible; “Choose
Picture…,” for example, is more
helpful than “Choose…” Because buttons
initiate an immediate action, it
shouldn’t be necessary to use “now”
(Scan Now, for example) in the label.
Push button labels should have
title-style capitalization, as
described in “Capitalization of
Interface Element Labels and Text.” If
the push button immediately opens
another window, dialog, or application
to perform its action, you can use an
ellipsis in the label. For example,
Mail preferences displays a push
button that includes an ellipsis
because it opens .Mac system
preferences, as shown in Figure 15-8.
Buttons should contain a single verb or a verb phrase, not answers to trivia game! If you have between 2 and 5 answers, you should use Radio Buttons to have the user select the answer and an OK button to have the user accept the answer. For more than 5 answers, you should consider a Pop-up Selector instead according to guidelines, though I guess that would be rather ugly in this case.
You could consider using a table with just one column, one row per answer and each cell being multiline if the answer is very long and needs to break. So the user selects a table row by clicking on it, which highlights the table cell and then clicks on an OK button to finish. Alternatively, you can directly continue, as soon as the user selects any table cell (but that way you take the user any chance to correct an accidental click). On the other hand, tables with multiline cells are rather rare on MacOS X. The iPhone uses some, but usually with very little text (at most two lines).
Pretty sure you can't do that using the standard API, certainly not with UILineBreakMode. In addition, the style guide says that an ellipsis indicates that the button when pressed will ask you for more information -for example Open File... will ask for the name of a file. Your proposed use of ellipsis violates this guideline.
You'd need some custom logic to implement the behaviour you describe, but I don't think it's the way to go anyway.
This is not a very good UI practice, but if you still want to do it, your best bet is to do so via a clickable div styled to look like a button.
Set the width of the div to an explicit value, and its overflow to hidden, then use a script executing on an interval to adjust the scrollLeft property of this div.