in my app I use an NSOpenPanel with an accessory view. This view has, among other things, a NSSecureTextField. Every time I open the panel this notice shows up in the log:
NSSecureTextFieldCell detected a field editor ((null)) that is
not a NSTextView subclass designed to work with the cell. Ignoring...
Does anybody know what exactly this means and how to get rid of it?
For now it isn't causing any problems but I would like to remove this.
Thanks a lot!
Related
I'm frustrated with the wall that using storyboards seems to put between NSWindows/NSWindowControllers and NSViews/NSViewControllers. A specific example: What good is the initialFirstResponder outlet on NSWindow if the whole view hierarchy is in a separate scene and can't be referenced?
I'd like to make the window called "progred"'s initialFirstResponder the "Content View" view from the View Controller Scene, but you can't make IBOutlet references across scenes. I'd be perfectly happy to put the ViewController and the Window in the same scene, but I can't seem to get that to work with all of the dragging/dropping I've tried to do from one scene to another, or even trying to add a new one from the toolbox. It seems that you're required to use a segue relationship to assign a NSViewController to a NSWindow.
I've googled but I'm not finding anything on this problem which might just mean I'm missing something obvious as I'm pretty new to Storyboards as I can't imagine I'm the first to notice this :).
I've been going through just this in swift (Xcode 6.3.1). IB appears to be unable to do what we want despite all the doco and advice saying "control drag....". My (eventual) solution/workaround was to set it in code, in viewWillAppear, of the view controller. I'd tried a variety of approaches until I encounter some apple doco that declared that the initialFirstResponder must be set BEFORE the window displayed. Hope this helps.
By the way, watch out for the default Window behaviour being "restorable" which seems to restart the (rebuilt) app with the focus in the last field the app was killed in....sigh
I'm trying to get the split view controller working properly but apparently there's a bug in there or I'm missing something.
First of all, I've started a blank OSX Obj-C application, and in the Storyboard I've dragged the split view controller. Next, I've linked the segues from the main window controller to the split view and added two labels.
http://i.imgur.com/dlFObaF.png
When I build the project, it shows only the second page. Not to mention strange window size in the final build.
http://i.stack.imgur.com/IqRqr.png
I've tried everything.
This occurs in both vertical and horizontal split view.
Any suggestions?
I had the same issue myself today, but it's just the split line wasn't initiated properly.
To see, this, once you run your app, move your mouse toward the edge of the window and drag it, you will now see another view emerging.
To my best knowledge, I do not know how to fix this in IB or in code. Apparently NSSplitViewController does not have a property like UISplitViewControllerAutomaticDimension. Would appreciate if someone can contribute to this.
Edited: Found an answer via another thread. Basically, try to add some constraints to the subviews inside each view and that should prevent the size of a view to be zero. In my toy example, adding margin constraints to my buttons worked out well.
There is section in my app which has a popover in which a UITableView is presented each time the popover is presented. It's easy to navigate between the UITableViews calculating the paths of the files that are supposed to be in the next view controller and using pushViewController, as easy at it is also to popViewController when it is necessary to go back to the former UITableViews.
The problem becomes when the popover is dismissed to do some other tasks and, after that, it is necessary to get back to the popover.
Which are the best practices to get a structure capable to retain the last presented UITableView with its properties and its former UITableView so the popover is presented exactly the way it was when dismissed?
It's a basic concept issue. I hope it helps somebody else.
I was initializing the UINavigationController each time the popover was dismissed. Of course, the information I needed from the "current table view" was lost. I just turned the UINavigationController from local variable into property and now the popover is every time shown with the "current" UITableView.
What do you advise? should I programmatically draw my textfields, labels, images or should I use IB?
Would it make any difference? I have scrolling issues (bit jerky) but not something I cannot live without!
I would use IB to help maintain the app. Jerky performance is usually a result to memory management issues and not specific to IB. IB just does the object creation and sets common properties, so do it in code, or in IB the end result is the creation of objects and setting of properties.
ok. problem solved. you were right and wrong regarding the IB...
to explain myself:
I was loading my cell from a nib file.
The trick and thanks goes to this site: http://iphoneincubator.com/blog/tag/dequeuereusablecellwithidentifier
i forgot to set my cell identifier to the nib file so i was creating the cells every time they were scrolled off the screen!
so tip!
When you load from nib ALWAYS put the right identifier in the "identifier" place!!!
thanks to nolimitsdude who actually pointed to the right way!!
I have a UIView filled with buttons that are all nicely hooked up to actions and outlets. However, in my infinite wisdom, I decided that I really would rather have the button behavior to be different and subclassed a UIControl.
My plan was to hop into Interface Builder, change the class of the buttons to my new UIControl subclass, and then be up and running. This would preserve all of outlet and action connections.
In IB (View Identity Inspector) when I type in my UIControl subclass into the class field, it reverts back to UIButton when I tab out. Any UIButton subclass works, but not a UIControl. I can go down the inheritance tree but not up....
The first plan was to go to XCode and change the superclass of my new control temporarily to UIButton, change the 'class' of my IB buttons, and then change the XCode code superclass back to UIControl. IB accepted and changed the class, but running the app gives me non-visible buttons. The IB Attributes inspector still shows it as a button.
Creating the control from scratch and rewiring works, but I was hoping to not rewire all the buttons if it could be avoided. (This is a change I was hoping to roll across multiple apps, so it is a bit more painful that it sounds)
Anyone know any way around this?
many thanks!
I'm a year late on this, but maybe it will help someone in the future. Perhaps you could open the .xib in a text editor and figure out what text you would have to change to get it to work (try it on a sample project first), then use find and replace to fix all of them at once.