Environment: Version 11.0 beta 3 (11M362v)
Here's the full text:
invalid mode 'kCFRunLoopCommonModes' provided to CFRunLoopRunSpecific - break on _CFRunLoopError_RunCalledWithInvalidMode to debug.
This message will only appear once per execution.
Hello World
This message only appears when I click on a UISwitch button that is connected to an action; here, printing "Hello World".
Apparently the behavior of the action isn't affected.
As a comparison, I've created a UIBarButtonItem in the toolbar which behaves normally. So there's something fishy about the switch button.
Question: why would this appear and what does it mean? Remedy?
I think it's a warning that Apple should fix it itself. Even in this sample project which is from WWDC19 this problem exists. There is a UISwitch in a cell of a table. When I tap it, the mentioned warning is raised.
So, in my view, it is a bug that Apple should deal with.
Judging from the replies by Apple Developer Relations to this post, this is a bug in UIKit and one that Apple is tracking. Until the bug is fixed, the advice is to treat this as "log noise".
I had a similar problem:
When I got the call-back from the UISwitch, I reloaded the UITableView.
I think that the call-back is initiated before the UISwitch finishes changing its context, and reloading the cell in that state creates some conflict.
With that theory, I solved my problem like so:
I separated the cells into sections, where the cell with the UISwitch was in its own section.
When I got the call-back from the UISwitch, I reloaded all the sections except the section that has the cell with the UISwitch.
Related
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 Cocoa Form (xib) which contains some NSTextFields and an NSMatrix of NSButtonCells. I can use the "Tab" key to tab though the NSTextFields, but the NSMatrix gets skipped over.
I want to be able to tab into the NSMatrix, and tab from one button to the next within the matrix.
I have put in the following line of code, but it is having no effect:
[mtxMyMatrix setTabKeyTraversesCells:YES];
Can anybody help with this problem or point me to an example? I have searched for hours with no success.
I had a similar problem and the solution I found was fiddling with the "first responder" setting. Specifically, making sure that the entire form didn't refuse, and each individual field likewise accepted first responder status. Again, the whole form, and each field as well. I too searched for a while... :( I'm also noob.
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));
I have two basic practical problems:
1) The first one is really stupid. I receive a message saying: "Method definition for 'aIncreasedSelection' not found, together with an "Incomplete Implementation".
Well, that is quite strange, because I don't have this method in neither my .m or .h file (and the class name is mentioned in the remark).
I used to implement this method, but I deleted it because it was redundant. In a certain way, it appears as if my Xcode project can't let go of the method...
2) The second question is also a very mysterious one. I have a couple of viewControllers in which I have put the identical same background, and the identical same buttons. It's really identical in size and position in the screen as well (I defined the pixels). For an unknown reason, when I switch between the views, one of the buttons changes very slightly its color (it is a Photoshop created button with mirror effect on the bottom, it's the mirror that becomes lighter). That is really annoying because it's supposed to be identical; when the user switches views now, he can see that there is a color difference in the button (supposed to be planted as a button in a dock, which should be identical over the entire app)...
Very frustrating as I cannot solve these small mistakes... Any ideas? Thanks!
Regarding your first problem, if you have verified that it no longer exists in your .h or .m file, try to cmd+shift+k and clean your project, then rebuild. This should update everything and in theory solve that issue for you.
As for the second problem, it sounds strange indeed. Is there any chance you could provide pictures somehow? Are you statically loading the image into similar buttons, or are you doing something differently?
Re - opening my project solved my first problem (unlike the refresh - cmd + shift + k, which didn't work). The color problem is not solved despite :-/
It was definitely a bug since I didn't change anything. It is in fact - very confusing!
I really enjoy using RBSplitView, an open source replacement for NSSplitView, but I have a problem in my shipping app and am experiencing it again in a new project.
The problem is I'm telling the RBSplitView to autosave its position state by giving it an autosave name. When my app launches the RBSplitView doesn't seem to honor the saved state till a second after the window is drawn.
I've spent the night trying to debug the behavior but have had little success. Anyone out there use this lib and have some advice?
You can scrub this quicktime movie to the issue at work:
http://media.clickablebliss.com/billable/interface_experiments/rbsplitview_delayed_autosave_reload2.mov
I've still been unable to figure out why this is happening but I do have a workaround.
First, make sure your main window is not visible at launch and then at the end of applicationDidFinishLaunching in your app delegate add something like:
[mainWindow performSelector:#selector(makeKeyAndOrderFront:) withObject:self afterDelay: 0.1];
The delay is the key. If you just tell the window to makeKeyAndOrderFront: I still see the issue. However as long as it has a beat of time it looks good.
This likely is happening because the RBSplitView instance needs to wait until it's first moment to get to set its frame to the autosaved value, which happens to be after the user can see it. This 0.0-delay trick simply delays showing the window until the very next runloop, which gives the split view a chance to do its magic (and other views) so that when the user sees the window, it's already nice and sexy. So just do the delay at 0.0 and you'll be fine.
I have a similar, but slightly different workaround in my app that uses RBSplitView. In applicationDidFinishLaunching:, I call adjustSubviews on the split view before calling makeKeyAndOrderFront: on the window that contains it. This seems to knock the split view in to order before it gets displayed on the screen.