On 1 Apr 2014, at 3:07 pm, Varun Chandramohan varun.chandramo...@wontok.com
wrote:
Ok, Setting it to 1 solved it. Looks like it should not be 0.
Right, it has to be 1. It's annoying that it emits a warning, since this value
is totally ignored AFAICS.
--Graham
On Mar 31, 2014, at 11:51 PM, Ronald Hofmann wrote:
I´m using tableViewSelectionDidChange to find out which row of myTableView
was clicked.
Works fine so far. I´m taking some action than.
- (void)tableViewSelectionDidChange:(NSNotification *)notification
{
NSInteger row =
I can report the same error in my own project. It's a view based table view,
single selection not firing on deselect.
The table view bound is bound to an NSArrayController for data.
On 01 Apr 2014, at 15:11, Keary Suska cocoa-...@esoteritech.com wrote:
On Mar 31, 2014, at 11:51 PM, Ronald
I found what was wrong, mea culpa :(
At the very beginning I have some lines to to take over if row == -1 and that
intercepted.
It works like this:
- (void)tableViewSelectionDidChange:(NSNotification *)notification {
NSInteger row = [_tableView selectedRow];
On Apr 1, 2014, at 12:25 AM, Jens Alfke wrote:
On Mar 31, 2014, at 10:16 PM, Trygve Inda cocoa...@xericdesign.com wrote:
I need to be able to set a new myDict and not have it happen between the
reading of different values from the dictionary by other threads.
Don’t expose the dictionary
Hi,
in a project using the default Spritekit template all works fine until one
leaves the app and switches to another process, which results in random crashes
without a backtrace. After having switched to another process and returning to
the running or also paused game, it's only a question
On Apr 1, 2014, at 2:19 PM, Alexander Reichstadt l...@mac.com wrote:
It always seems to involve the main window. The trace is not very helpful as
it crashes outside the app's own code. The last calls that I can see in the
debugger are sometimes [NSApplication updateWindows], other times
Perhaps do an NSLog on the [NSWindow becomeKeyWindow] / [NSWindow
updateWindows] and see if an NSLog on NSNotification willEnterForeground fires
before either of those methods. If so, then you have a good chance of closing
down whatever SpriteKit is doing when your app is going to background
