Re: Capturing 'self' strongly in this block is likely to lead to a retain cycle
On 09.07.2012, at 18:03, Fritz Anderson wrote:
You can break this by having a strong reference to self that the block
can manage independently.
__block MyClass * blockSelf = self;
[self.operationQueue addOperationWithBlock:^{
[blockSelf bar];
blockSelf = nil;
}];
Thank you Fritz for your answer.
But if I break the cycle and if I understand it correctly, 'self' won't be
retained anymore within the block. If there are no more references to
'self' (except one possibly within the block), I fear 'self' will be
destroyed before the block executes. I do require, though, that 'self'
will be valid as long as the block is not finished.
Note: I'm using ARC in which case a retainable pointer declared with
__block will be retained (as opposed to manual ref counting), so I should
use __weak or __unsafe_unretained instead of __block to break the cycle
(if that is what I have to do).
Andreas
No, if you use the syntax Fritz suggests and there is no need to fear self
being destroyed before the block is finished. This is also in the
Transitioning To ARC release notes.
blockSelf is retained by the block, since blockSelf just points to self,
that retains self. At the end of the block, but not before, you're setting
it to nil, which gets rid of that strong reference. All this little trick
really does is 'rename' self to something else so you can manage its
lifecycle.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: One more try - NSCollectionView multi-selection problem..
Ok, So in the meantime, I have a bunch of customers filing bugs/feature requests to implement this ability.. (Its a popular request, shall we say..) Is this something that can be overridden, turned on/off? Has anyone done this? Thanks! bob. On Jul 10, 2012, at 3:48 AM, Graham Cox wrote: I believe for icon-type views, the idea that shift-selecting selects a range of items is no longer considered best practice these days. For example, the icon view in the Finder doesn't do that (list view does). command-click and shift-click are the same thing for icon views, i.e. they toggle the clicked item. --Graham On 09/07/2012, at 5:34 PM, Robert Monaghan wrote: Hi Everyone, In a previous posting, I had a problem with NSCollectionView not selecting a range of objects, when shift-selecting items. For example, if I were to click on object 3 and then shift-click on object 5, I would expect a range of 3,4,5 to be highlighted. Instead only 3 and 5 are selected. Ok, so multi-selection works. Sorta.. (BTW, this same behavior happens with Imagebrowser sample app from Apple.) I added an observer to my NSArrayController's selectionIndexes to see what it think is happening. Sure enough, the NSArrayController is getting a bunch of ranges that look like this: NSIndexSet: 0x100648650[number of indexes: 2 (in 2 ranges), indexes: (2 4)] I would have expected something like this: NSIndexSet: 0x100362a50[number of indexes: 3 (in 1 ranges), indexes: (2-4)] Suggestions? I see a setSelectionIndexes: selector in the NSCollectionView object. Do I need to do something here? It seems like a huge headache to teach NSCollectionView to do a properly shift-selection of a range. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: One more try - NSCollectionView multi-selection problem..
On 10/07/2012, at 4:37 PM, Robert Monaghan wrote: Ok, So in the meantime, I have a bunch of customers filing bugs/feature requests to implement this ability.. (Its a popular request, shall we say..) Is this something that can be overridden, turned on/off? Has anyone done this? I haven't done it, but it should be easy enough. When the delegate is told that the selection has changed, check if the shift key is down for the current event, grab the selection index and fill in the gaps. Then call -setSelectionIndexes: --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Why would UIBarButtonItems simply not show up?
I have a screen that can be flipped over to show a map, and from the map
the user can invoke a detail controller for an item on the map. So I
instantiate a navigation controller, make the map controller its root-view
controller, and then invoke it:
- (void)showMap
{
StashMapController* mapController = [[StashMapController alloc]
initWithNibName:@StashMap stashes:_ownedStashes];
mapController.delegate = self;
UINavigationController* mapNavController = [[UINavigationController alloc]
initWithRootViewController:mapController];
[mapController release];
mapNavController.modalTransitionStyle =
UIModalTransitionStyleFlipHorizontal;
// Do flip transition.
[self presentModalViewController:mapNavController animated:YES];
}
In the map controller's viewDidLoad, I add two bar-button items as the
right buttons:
UIBarButtonItem* globeButton = [[UIBarButtonItem alloc]
initWithImage:[UIImage imageNamed:@globe_white]
style:UIBarButtonItemStyleBordered target:self action:@selector(zoomOut:)];
UIBarButtonItem* homeButton = [[UIBarButtonItem alloc]
initWithImage:[UIImage imageNamed:@location-arrow_white]
style:UIBarButtonItemStyleBordered target:self action:@selector(home:)];
self.navigationItem.rightBarButtonItems = [[NSArray alloc]
initWithObjects:globeButton, homeButton, nil];
They're allocated, but they just don't show up. Adding one of them as a
single button doesn't work either.
Setting *self.navigationItem.title* DOES work, so I know I'm dealing with
the right structure.
Any insight appreciated!
Gavin
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why would UIBarButtonItems simply not show up?
Ugh, never mind. The graphic files hadn't been added to the project. I would've expected a warning message to the console or a blank button, but got neither. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
cocoabuilder closed?
Sorry, this is O.T. a little. Does anyone know what's going on with Cocoabuilder.com? I haven't been able to get there for more than a month, on work or on home computers. But Google shows a cached page with a recent date, which seems weird. Is there any other similar site to browse topics easier than the Apple list archive pages (and doesn't have search either)? Thanks, Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: One more try - NSCollectionView multi-selection problem..
On Jul 10, 2012, at 12:51 AM, Graham Cox wrote: On 10/07/2012, at 4:37 PM, Robert Monaghan wrote: Ok, So in the meantime, I have a bunch of customers filing bugs/feature requests to implement this ability.. (Its a popular request, shall we say..) Is this something that can be overridden, turned on/off? Has anyone done this? I haven't done it, but it should be easy enough. When the delegate is told that the selection has changed, check if the shift key is down for the current event, grab the selection index and fill in the gaps. Then call -setSelectionIndexes: Except that you're thinking about NSTableView--NSCollectionView doesn't have any delegate methods for selection semantics, that I know of. It sounds fragile to me but maybe this check could be done in -setSelectionIndexes: ? HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Capturing 'self' strongly in this block is likely to lead to a retain cycle
On 9 Jul 2012, at 6:35 PM, Shane Stanley wrote: On 10/07/2012, at 2:03 AM, Fritz Anderson wrote: In practice, NSOperationQueue probably releases the block when it's done with it I'm curious about your use of the word probably here. Can you explain? The documentation for -addOperationWithBlock: does not _explicitly_ say that blocks are released after they are executed, so I didn't say so for a fact. But doing so is the only thing that makes sense, and conforms to the design pattern that containers retain (copy)/release the objects they contain. So the release is at least probable, if not certain. — F ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Capturing 'self' strongly in this block is likely to lead to a retain cycle
In practice, NSOperationQueue probably releases the block when it's done with it I'm curious about your use of the word probably here. Can you explain? This is probably not what the OP had in mind, but I might mention that I've seen situations where autoreleases associated with NSOperationQueues and GCD queues have still been outstanding five minutes later under conditions of extremely high load. (My suspicion is that a mouse click or other user event causes these to be carried out, but I didn't test that one systematically). ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
MaxOS 10.7 full-screen animation corrupts my UI --- how to avoid?
Hello everyone. My main window restricts the user to a range of window sizes, using [myWindow setContentsMaxSize:maxSize] [myWindow setContentsMinSize:minSize] The minimum size prevents corruption of some complicated views loaded from several nib files. When the user presses fullscreen button, Lion starts an animation that will 1. shrink the window below its current size, 2. in several steps, increase its size until it reaches the full-screen representation size. If the window started in its minimal size, this animation will SHRINK IT BELOW THE MINIMAL size and will corrupt my UI beyond repair. My views are receiving setFrameSize: with unsupported size. Can this be considered a Cocoa bug? Am I doing something wrong? Can I somehow prevent the corruption, without replacing the OS standard animation for full-screen? Why doesn't the animation base on a snapshot of the window contents, instead of live-resizing of the whole view-hierarchy throughout the animation? Can someone spare a few lines of code that will do a simple linear resizing animation that will NOT go below minimum? Any advice will be greatly appreciated. Thanks. Motti Shneor - Ceterum censeo Microsoftinem delendam esse ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Bottom-edge constraint not enforced in IB but is in runtime?
The default value of translatesAutoresizingMaskIntoConstraints for top level views in IB is YES on both Lion and Mountain Lion. But this can be disabled using the Attributes Inspector and uncheck Translates Mask Into Constraints Kevin On Jul 9, 2012, at 12:09 PM, Rick Mann rm...@latencyzero.com wrote: On Jul 9, 2012, at 7:57 , Marc Respass wrote: I'm also finding that NSSplitView's pane views seem to have the translatesAutoresizingMaskIntoConstraints property set to true by default, even when built strictly in IB. Is this correct? Xcode 4.3.2. Hi Rick, I really encourage you to watch all three WWDC 2012 videos on constraints. That will answer a lot of questions. Constraints are tricky for me and those sessions cleared up a lot of things including priorities. You'll watch someone setup constraints to do things that previously required a split view to handle. Well, see, this is the problem. I watched the first two videos (still have to watch the examples video), and IB and Lion are not behaving as advertised. According to the videos, if you're using constraints, the translates property should always be no (I may have misunderstood that). It should only be on for a NIB that isn't using autolayout, and in that case you can apply constraints in some places, and it'll apply them in others. But that's not what I'm seeing. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/cathey%40apple.com This email sent to cat...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Bottom-edge constraint not enforced in IB but is in runtime?
Thanks a lot, Kevin. I didn't realize it was only for top-level objects; now I see it. It is correct that I should turn off translatesAutoresizingMaskIntoConstraints when using auto-layout? Thanks again Marc El jul 10, 2012, a las 11:01 a.m., Kevin Cathey escribió: The default value of translatesAutoresizingMaskIntoConstraints for top level views in IB is YES on both Lion and Mountain Lion. But this can be disabled using the Attributes Inspector and uncheck Translates Mask Into Constraints Kevin On Jul 9, 2012, at 12:09 PM, Rick Mann rm...@latencyzero.com wrote: On Jul 9, 2012, at 7:57 , Marc Respass wrote: I'm also finding that NSSplitView's pane views seem to have the translatesAutoresizingMaskIntoConstraints property set to true by default, even when built strictly in IB. Is this correct? Xcode 4.3.2. Hi Rick, I really encourage you to watch all three WWDC 2012 videos on constraints. That will answer a lot of questions. Constraints are tricky for me and those sessions cleared up a lot of things including priorities. You'll watch someone setup constraints to do things that previously required a split view to handle. Well, see, this is the problem. I watched the first two videos (still have to watch the examples video), and IB and Lion are not behaving as advertised. According to the videos, if you're using constraints, the translates property should always be no (I may have misunderstood that). It should only be on for a NIB that isn't using autolayout, and in that case you can apply constraints in some places, and it'll apply them in others. But that's not what I'm seeing. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/cathey%40apple.com This email sent to cat...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Capturing 'self' strongly in this block is likely to lead to a retain cycle
On Jul 10, 2012, at 12:56 AM, Jonathan Taylor wrote: In practice, NSOperationQueue probably releases the block when it's done with it I'm curious about your use of the word probably here. Can you explain? This is probably not what the OP had in mind, but I might mention that I've seen situations where autoreleases associated with NSOperationQueues and GCD queues have still been outstanding five minutes later under conditions of extremely high load. (My suspicion is that a mouse click or other user event causes these to be carried out, but I didn't test that one systematically). GCD creates autorelease pools of last resort - they are basically only there to prevent what would otherwise be unavoidable leaks if they were not present. Because the threads that own these autorelease pools have an undefined lifetime, the lifetime of these autorelease pools can similarly be exceptionally long. Basic rule of thumb thus is to create your own autorelease pool for such blocks or operations to ensure that your autoreleases are carried out in a timely manner. This is not unlike how you create your own autorelease pools when creating a new NSThread. -- David Duncan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Bottom-edge constraint not enforced in IB but is in runtime?
On Tue, Jul 10, 2012, at 08:01 AM, Kevin Cathey wrote:
The default value of translatesAutoresizingMaskIntoConstraints for top
level views in IB is YES on both Lion and Mountain Lion. But this can be
disabled using the Attributes Inspector and uncheck Translates Mask Into
Constraints
Unfortunately this is not the complete truth. It is also YES for
document views of NSScrollViews, and cannot be disabled even in the
latest versions of Xcode that I have tried. I have a view that manages
its relationship to its enclosing clip view using constraints, and I
obviously need to disable translatesAutoresizingMaskIntoConstraints for
this to work properly.
And because of the way that nib unarchiving works,
-setTranslatesAutoresizingMaskIntoConstraints: is called *after*
-initWithFrame:/-initWithCoder:. So the solution I've been using is to
override -updateConstraints to call [self
setTranslatesAutoresizingMaskIntoConstraints:NO] before calling super.
I suppose I could instead override
-translatesAutoresizingMaskIntoConstraints like so:
- (BOOL)translatesAutoresizingMaskIntoConstraints {
if ([self superview] == [[self enclosingScrollView] contentView])
return NO;
else
return [super translatesAutoresizingMaskIntoConstraints];
}
...but it's not documented whether the constraint system calls
-translatesAutoresizingMaskIntoConstraints, or uses an internal flag to
represent that state.
Also, IB doesn't let you edit the autoresizing mask of a view in a nib
with autolayout turned on, even if that view is a top-level view and
should have translatesAutoresizingMaskIntoConstraints=YES because it's
going to be installed in a view hierarchy you don't control. This is
also incredibly unhelpful.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: cocoabuilder closed?
I just tried the website and it seems to work, I searched for my own name and even found some posts I was not even aware from many years ago ;-) You could try to contact Bertrand Mansion, the site owner, on cocoabuil...@mamasam.com for questions about the status. [[[Brainchild alloc] initWithName:@Richard Altenburg] saysBestRegards]; Op 10 jul. 2012, om 15:03 heeft Chris Paveglio het volgende geschreven: Does anyone know what's going on with Cocoabuilder.com? I haven't been able to get there for more than a month, on work or on home computers. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: cocoabuilder closed?
I can get to the site but it doesn't seem to have been updated since June 25. --Andy On Jul 10, 2012, at 2:35 PM, Richard Altenburg (Brainchild) wrote: I just tried the website and it seems to work, I searched for my own name and even found some posts I was not even aware from many years ago ;-) You could try to contact Bertrand Mansion, the site owner, on cocoabuil...@mamasam.com for questions about the status. [[[Brainchild alloc] initWithName:@Richard Altenburg] saysBestRegards]; Op 10 jul. 2012, om 15:03 heeft Chris Paveglio het volgende geschreven: Does anyone know what's going on with Cocoabuilder.com? I haven't been able to get there for more than a month, on work or on home computers. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com This email sent to ag...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Stupid block syntax!
On 9 Jul 2012, at 13:33, Vincent Habchi wrote: On 5 juil. 2012, at 02:45, Graham Cox graham@bigpond.com wrote: I read recently that the '^' was the only possible operator that could be used due to the inherent grammar of C meaning that anything else would have introduced ambiguity If I remember correctly, it has more to do with C++ overloading. ^ is not overloadable in C++, that was the unique such operator left. Vincent I just *knew* it *had* to be something to do with C++ Voodoo! I've never gotten on with it and now it's managed to infect me! Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: turning app into background app
On Jul 9, 2012, at 11:55 AM, Ken Thomases k...@codeweavers.com wrote: Note that in 10.7 and later, you can use TransformProcessType to convert your app back into a background-only or UIElement app, as well. Fascinating. Does this apply to -[NSApplication setActivationPolicy:] as well? setActivationPolicy:NSApplicationActivationPolicyProhibited is supported in 10.7 to convert to a background-only app. NSApplicationActivationPolicyAccessory isn't supported. -eric ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Avoiding cyclic header imports
I have two classes, and a model object - RSPlugin, RSExpression, and RSRule - which share the same data model. I have thought to have the classes provide a method which can be used to initialize the RSRule object so: RSRule * rule = [[RSRule alloc] init]; [rule loadFromPlugin: currentPlugin]; where -[RSRule loadFromPlugin:] copies the values to the rule. This requires however that RSRule #imports the RSPlugin header. I also would like to maintain symmetry by having RSPlugin import the values of RSRule, for purposes of round-tripping to the UI (plugin reps the UI for a rule instance). Obviously, this would require RSPlugin to #import RSRule's header. Xcode doesn't like this one bit. The same sort of reciprocal data-swapping interface would be wanted for the RSExpression side of the chain. I imagine this is such a commonplace sort of relationship that there must be a standard approach (or perhaps several approaches) to solving it. My first stab at it was to try and provide the interfaces as categories but I ran into a similar issue with circular imports. Anyone got a pointer to a Comp Sci 101 style description of how to avoid this? Thanks for your time. ~ Erik ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Avoiding cyclic header imports
On Jul 10, 2012, at 5:01 PM, Erik Stainsby erik.stain...@roaringsky.ca wrote: where -[RSRule loadFromPlugin:] copies the values to the rule. This requires however that RSRule #imports the RSPlugin header. I also would like to maintain symmetry by having RSPlugin import the values of RSRule, for purposes of round-tripping to the UI (plugin reps the UI for a rule instance). Obviously, this would require RSPlugin to #import RSRule's header. Xcode doesn't like this one bit. You need to #import the other class's header in the .m file, but not in the .h file. There you can just declare it like @class RSRule;. That should be enough to avoid circular #imports (and by the way, greatly reduce the number of #imports in your headers, which is good for reducing build times.) About the only times you need to #import another header are if it declares the superclass of an @interface, or a protocol you're implementing, or some typedef or enum that's used in the API. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
-layout not called after invoking -setNeedsLayout:YES
I'm overriding NSView's -layout method to arrange a grid of subviews. I call [gridView setNeedsLayout: YES] when a new subview is added, which usually results in -layout being called on gridView, but intermittently -layout is not called (resulting in incorrect subview positioning.) In contrast, I also call [gridView setNeedsUpdateConstraints: YES], which always results in -updateConstraints being called. I've verified that nothing is calling [gridView setNeedsLayout: NO] by overriding that method. What would prevent -layout from being called? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Instance not responding to selector
I have a set of plugins which I load via a custom framework. The plugins load and behave correctly in the UI. I have a set of corresponding rule objects, one for each class of plugin. A plugin may load data from a rule, and a rule may load data from a plugin: -[RSRule loadFromPlugin:(RSPlugin*)plugin] or -[RSPlugin loadFromRule:(RSRule*)rule]. I have moved away from using categories to do this and the classes implement these methods internally. The header files list the methods correctly. However, after a clean and build, attempting to invoke any of these -[loadFrom..:] methods causes a crash reporting unrecognized selector. A typical error message: 2012-07-10 20:42:39.791 Trixie[41453:303] -[RSReactionRule loadFromPlugin:]: unrecognized selector sent to instance 0x1018961b0 2012-07-10 20:42:39.792 Trixie[41453:303] -[RSReactionRule loadFromPlugin:]: unrecognized selector sent to instance 0x1018961b0 2012-07-10 20:42:39.794 Trixie[41453:303] ( 0 CoreFoundation 0x7fff898bf716 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x7fff858a5470 objc_exception_throw + 43 2 CoreFoundation 0x7fff89955d5a -[NSObject(NSObject) doesNotRecognizeSelector:] + 186 3 CoreFoundation 0x7fff898adc3e ___forwarding___ + 414 4 CoreFoundation 0x7fff898ada28 _CF_forwarding_prep_0 + 232 5 Trixie 0x0001adf3 -[RSRuleWindowController addRuleToStore:] + 131 6 AppKit 0x7fff8a4b2599 -[NSApplication sendAction:to:from:] + 342 7 AppKit 0x7fff8a4b23f7 -[NSControl sendAction:to:] + 85 8 AppKit 0x7fff8a4b232b -[NSCell _sendActionFrom:] + 138 9 AppKit 0x7fff8a4b0813 -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 1855 10 AppKit 0x7fff8a4b0061 -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 504 11 AppKit 0x7fff8a4af7dc -[NSControl mouseDown:] + 820 12 AppKit 0x7fff8a4a713e -[NSWindow sendEvent:] + 6853 13 AppKit 0x7fff8a4a3274 -[NSApplication sendEvent:] + 5761 14 AppKit 0x7fff8a3b8eaa -[NSApplication run] + 636 15 AppKit 0x7fff8a35d886 NSApplicationMain + 869 16 Trixie 0x000112a2 main + 34 17 libdyld.dylib 0x7fff8890b7e1 start + 0 ) Any advice on how I could narrow down what is causing this? I have tried using repondsToSelector: but this doesn't do anything but confirm what the error message states, that the selector is not recognized. ~ Erik ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: nstableview remove/insert rows question
Hi everyone, Can I bump this because I'm still stuck here. :-) And maybe I can ask in a new way here's what I'm trying to do: 1. Remove old rows from tableview (let's say 5) with sliding left animation 2. Update array being used as datasource (let's say now it contains 15 items) 3. Resize my window containing my table view to fit the amount of rows (setFrame:display:animate) 4. Insert my new rows (all 15 of them) with sliding right animation Problem is between steps 3 and 4 I think the the window resizing is not finished before the inserting rows step comes. So the last couple of rows do not insert with animation but they just appear as reloadData would normally do. This does not happen if the difference is rows is 0 or minimal. But in my example (from 5 to 15) it will happen. And sorry but I couldn't figure out how to use rowViewAtRow in this situation it always throws an exception. Any help would be much appreciated thanks! rc On Jun 29, 2012, at 4:26 AM, Corbin Dunn wrote: On Jun 28, 2012, at 4:30 AM, Rick C. rickcort...@gmail.com wrote: Hi, Got a view-based table view and instead of using reloadData I'm removing the existing rows and inserting the new rows so that I can have animation. I'm also resizing the window in-between these 2 steps because my window resizes to fit how many rows are in my table view. This works great when my window doesn't resize (due to same amount of rows) or resizes very little. However let's say I have only 2 rows then remove those 2 rows and resize the window (using setFrame:display:animate:) and finally insert a much larger amount of rows like 15 what happens is the top 5 or 6 rows animate as expected but the rows further down just appear as if I was calling reloadData. I have checked this and reloadData is not being called, but I can't figure out why all rows don't animate. Any ideas? Yes -- I have ideas; actually, even better, I know what is happening! The table is very efficient at bringing in only the views you need. What's happening here is your animation insert or delete is happening, and no other views are visible (or need to be). Then, the table is resized via the window animation, exposing more rows that didn't participate in the animation. You can trick them to participate in the animation by pulling them in before doing the animation; if you are going to have X rows be revealed, call rowViewAtRow:makeIfNecessary:YES for the X rows past the last visible one first. corbin Thanks, rc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/corbind%40apple.com This email sent to corb...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Instance not responding to selector
On Jul 10, 2012, at 9:03 PM, Erik Stainsby erik.stain...@roaringsky.ca wrote: 2012-07-10 20:42:39.792 Trixie[41453:303] -[RSReactionRule loadFromPlugin:]: unrecognized selector sent to instance 0x1018961b0 What does the implementation of the -loadFromPlugin: method in that class (or a superclass it inherits it from) look like? Not the body, just the outside part. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Instance not responding to selector
On 10 Jul 2012, at 11:03 PM, Erik Stainsby wrote: Any advice on how I could narrow down what is causing this? I have tried using repondsToSelector: but this doesn't do anything but confirm what the error message states, that the selector is not recognized. More than that, it states that the selector is not recognized _by RSReactionRule_. Are you sending that message to an RSReactionRule? If you don't think you are, set a breakpoint (presumably somewhere in -addRuleToStore:), and examine the recipient of that message; does the debugger think it's an RSReactionRule? There are two main reasons an object won't recognize a selector. - You blundered and wrote code that sent the selector to the wrong object. This is fairly obvious, and the compiler usually urges you not to do it anyway. - You sent the message via an object pointer that _used_ to point to a legitimate receiver for the selector, but that object had been deallocated, and the address recycled for another object (an RSReactionRule) that doesn't implement it. In other words, the object got (over)released out from under you. Audit your memory management (better, adopt ARC). The Allocations instrument, set to record reference counts and enabling zombie detection, should help you track this down. Or, maybe there's something esoteric going on with your plugin loading. But I'd look at these two possibilities first. — F -- Fritz Anderson -- Xcode 4 Unleashed: Hot on the heels of what Apple has been doing with provisioning! -- http://x4u.manoverboard.org/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
