Re: ARC and reinterpret_cast?
On 08.07.2012, at 06:13, Rick Mann wrote: > Hi. I'd like to write code like this: > > MyObject* foo = reinterpret_cast<__bridge MyObject*> (someVoidPointer); > > But the compiler doesn't like it. It's perfectly happy with: > > MyObject* foo = (__bridge MyObject) someVoidPointer; > > this is in a .mm file. You probably meant this (without typo): > MyObject* foo = (__bridge MyObject*) someVoidPointer; I think, the assumption that __bridge is a simple type qualifier (like const or volatile) is false. It's rather a type conversion operator returning an object akin to an instance of a non-POD type. What you are seeking for would be probably this: MyObject* foo = __bridge_cast(someVoidPointer); But this doesn't exist - unless you define it yourself ;) Andreas > > The error is: > > error: type name requires a specifier or qualifier >MyObject* me = reinterpret_cast<__bridge MyObject*> (inRefCon); >^ > error: expected '>' >MyObject* me = reinterpret_cast<__bridge MyObject*> (inRefCon); >^ >> > note: to match this '<' >MyObject* me = reinterpret_cast<__bridge MyObject*> (inRefCon); > ^ > Is it a bug in the compiler, or am I doing something wrong? > > TIA, > -- > Rick > > ___ > > 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/agrosam%40onlinehome.de > > This email sent to agro...@onlinehome.de ___ 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
One more try - NSCollectionView multi-selection problem..
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: [number of indexes: 2 (in 2 ranges), indexes: (2 4)] I would have expected something like this: [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. Thanks! bob. ___ 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 5 juil. 2012, at 02:45, Graham Cox 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 ___ 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: NSInteger vs int vs int32_t
On 5 juil. 2012, at 07:41, Nathan Day wrote: > It must if 64bits is read in that mean you have just read in two 32bit words. > So to put a 32bit word in a 64bit register some bit must be ditched, in some > way, and if the CPU is optimise to only work with 64bit word alignment (don't > know how intel does it), then to get 32 bit aligned words it must do some bit > shift. Modern CPU do not enforce strict alignment for integer access. You can perfectly access a Dword (64 bits) at any address, even or odd. It is just more efficient to align 64-bits words at 8-bytes boundary, 32-bits at 4-bytes, etc. This contrasts with the old times: for example, on a 68000 processor, trying to access a 16-bit word at an odd address (e.g. move.w d0, (a0)+ with a0 odd) would result in a exception n°3 (address error). You still get boundary enforcement for SIMD instructions though (SSE, AVX). This is somehow reflected in C code through the use of special macros to instruct the compiler to respect these alignments. Vincent ___ 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: Re: Bottom-edge constraint not enforced in IB but is in runtime?
> 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. IB is trying to give you good constraints but more importantly it is always going to create valid constraints. I don't remember what the default setting is for translatesAutoresizingMaskIntoConstraints (and I can't find it in IB) but I'm sure that if you are using constraints that translatesAutoresizingMaskIntoConstraints should be NO. Good luck Marc ___ 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: Arrgh IB constraints
> BTW, if the NSSplitView hasn't been updated to use constraints in its own > layout, then why does it and up changing the size at runtime? For that matter > it seems like IB is expressly forbidding adding constraints to the > NSSplitView's panes. There are known bugs with NSSplitView and auto layout on OS X 10.7 with both the runtime and with IB. Mainly, even if you say a particular pane should be >= 100 (for example), you can still drag the splitter right past the 100pt mark. See the WWDC videos from this year for more information… On Jul 8, 2012, at 9:01 PM, Rick Mann wrote: > Thanks for all your help, Charles. > > So, I'm getting the exact same behavior your video shows. I definitely don't > want the bottom pane to get any smaller, and I can enforce that the old way, > but it seems pretty lame that they didn't update it to work with autolayout. > > I figured out why it was adding extra constraints to the top pane; I've got > that down to four. There don't appear to be any problems there (other than an > inability to specify a minimum height). > > It's the bottom that has so many issues. > > I just sent you the NIB file. I'm going to keep poking at it. > > BTW, if the NSSplitView hasn't been updated to use constraints in its own > layout, then why does it and up changing the size at runtime? For that matter > it seems like IB is expressly forbidding adding constraints to the > NSSplitView's panes. > > -- > Rick > > > On Jul 8, 2012, at 20:46 , Charles Srstka wrote: > >> On Jul 8, 2012, at 10:23 PM, Rick Mann wrote: >> >>> On Jul 8, 2012, at 19:01 , Charles Srstka wrote: >>> Argh, now this stuff is frustrating. I really, really wish those autoresizing masks would stay out of it when autolayout is on. I’m assuming this is the lower text view; could you post a screenshot of all the constraints for that view? They should be listed nicely in the Size inspector in IB. >>> >>> Do I need to turn off the translatesAutoresizingMaskIntoConstraints on all >>> my views? It's annoying, because IB doesn't actually me specify >>> autoresizing masks, and I'm using autolayout in the nib file. >> >> I don’t think so, since I just decided to try to recreate your nib file at >> home and see if I could reproduce the problem. I think I *have* found the >> source of some of your “broken constraint” messages; I had forgotten >> something about split views; seems my initial instinct was wrong, and it >> doesn’t seem to use constraints to determine the position of the splitter. >> Moreover, it doesn’t let constraints keep the user from resizing the bottom >> pane smaller than your minimum size for that view, and when you do it, you >> get a crapton of broken constraint warnings (both these things are probably >> due to NSSplitView being created well before the advent of constraints and >> not being completely savvy regarding them). So you actually want to make the >> priority of the “Bottom Space” constraints 999 instead of 1000. This allows >> the layout system to actually move these views below the bounds of its >> superview if it has to. You also want to make a “Greater than or Equal” >> constraint from the button to the top edge of the superview, so that the >> constraint system pushes it off the bottom rather than the top. This video >> will sort of demonstrate: >> >> http://www.charlessoft.com/extraneous_stuff/constraints.m4v >> >> Next, I’m going to try to see if I can figure out a way to screw this xib >> file up and make it exhibit the behavior you’re describing. I’m a bit >> suspicious of all those constraints for the top pane, which should really be >> only four, one for each edge of the text view. Could you expand that pane a >> bit more so I can see the descriptions of all those constraints a little >> better? >> >> Charles > > > ___ > > 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
"Capturing 'self' strongly in this block is likely to lead to a retain cycle"
I get the mentioned warning in my code and I'm wondering if this a possibly
issue in my case:
ARC enabled.
The warning "Capturing 'self' strongly in this block is likely to lead to a
retain cycle" is issued in this method:
- (void) foo
{
[self.operationQueue addOperationWithBlock:^{
[self bar];
}];
}
property operationQueue is declared 'strong'.
I understand the message, that is:
'self' is strongly retaining _operationQueue which itself strongly retains a
block which itself strongly retains 'self'.
However, is this a problem in this case? I expect message bar to be queued in
the operation queue. Meanwhile all references to 'self' diminish, except the
one in the block. The block executes and eventually finishes and releases
'self' - possibly the last reference.
Additionally, in this case, it is required that 'self' must not be destroyed
prematurely - that is, before message bar finished.
Doesn't break the cycle automatically - and isn't this warning over-alert?
Thanks for clarification!
___
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 10:40 AM, Andreas Grosam wrote:
> The warning "Capturing 'self' strongly in this block is likely to lead to a
> retain cycle" is issued in this method:
>
> - (void) foo
> {
>[self.operationQueue addOperationWithBlock:^{
>[self bar];
>}];
> }
>
> property operationQueue is declared 'strong'.
>
> I understand the message, that is:
>
> 'self' is strongly retaining _operationQueue which itself strongly retains a
> block which itself strongly retains 'self'.
No. _operationQueue has nothing to do with it. The capture referred to has only
to do with the block. As the warning says, it's a capture of self.
> However, is this a problem in this case? I expect message bar to be queued in
> the operation queue. Meanwhile all references to 'self' diminish, except the
> one in the block. The block executes and eventually finishes and releases
> 'self' - possibly the last reference.
You correctly describe the cycle. In practice, NSOperationQueue probably
releases the block when it's done with it, and breaks the cycle, but clang
can't know that, so it has to warn of the "likely" cycle.
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;
}];
— 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: Arrgh IB constraints
Which videos? I've watched the first two on constraints, and don't recall any mention of nssplitview. Sent from my iPhone On Jul 9, 2012, at 8:33, Kevin Cathey wrote: >> BTW, if the NSSplitView hasn't been updated to use constraints in its own >> layout, then why does it and up changing the size at runtime? For that >> matter it seems like IB is expressly forbidding adding constraints to the >> NSSplitView's panes. > There are known bugs with NSSplitView and auto layout on OS X 10.7 with both > the runtime and with IB. Mainly, even if you say a particular pane should be > >= 100 (for example), you can still drag the splitter right past the 100pt > mark. > > See the WWDC videos from this year for more information… > > > On Jul 8, 2012, at 9:01 PM, Rick Mann wrote: > >> Thanks for all your help, Charles. >> >> So, I'm getting the exact same behavior your video shows. I definitely don't >> want the bottom pane to get any smaller, and I can enforce that the old way, >> but it seems pretty lame that they didn't update it to work with autolayout. >> >> I figured out why it was adding extra constraints to the top pane; I've got >> that down to four. There don't appear to be any problems there (other than >> an inability to specify a minimum height). >> >> It's the bottom that has so many issues. >> >> I just sent you the NIB file. I'm going to keep poking at it. >> >> BTW, if the NSSplitView hasn't been updated to use constraints in its own >> layout, then why does it and up changing the size at runtime? For that >> matter it seems like IB is expressly forbidding adding constraints to the >> NSSplitView's panes. >> >> -- >> Rick >> >> >> On Jul 8, 2012, at 20:46 , Charles Srstka wrote: >> >>> On Jul 8, 2012, at 10:23 PM, Rick Mann wrote: >>> On Jul 8, 2012, at 19:01 , Charles Srstka wrote: > Argh, now this stuff is frustrating. I really, really wish those > autoresizing masks would stay out of it when autolayout is on. I’m > assuming this is the lower text view; could you post a screenshot of all > the constraints for that view? They should be listed nicely in the Size > inspector in IB. Do I need to turn off the translatesAutoresizingMaskIntoConstraints on all my views? It's annoying, because IB doesn't actually me specify autoresizing masks, and I'm using autolayout in the nib file. >>> >>> I don’t think so, since I just decided to try to recreate your nib file at >>> home and see if I could reproduce the problem. I think I *have* found the >>> source of some of your “broken constraint” messages; I had forgotten >>> something about split views; seems my initial instinct was wrong, and it >>> doesn’t seem to use constraints to determine the position of the splitter. >>> Moreover, it doesn’t let constraints keep the user from resizing the bottom >>> pane smaller than your minimum size for that view, and when you do it, you >>> get a crapton of broken constraint warnings (both these things are probably >>> due to NSSplitView being created well before the advent of constraints and >>> not being completely savvy regarding them). So you actually want to make >>> the priority of the “Bottom Space” constraints 999 instead of 1000. This >>> allows the layout system to actually move these views below the bounds of >>> its superview if it has to. You also want to make a “Greater than or Equal” >>> constraint from the button to the top edge of the superview, so that the >>> constraint system pushes it off the bottom rather than the top. This video >>> will sort of demonstrate: >>> >>> http://www.charlessoft.com/extraneous_stuff/constraints.m4v >>> >>> Next, I’m going to try to see if I can figure out a way to screw this xib >>> file up and make it exhibit the behavior you’re describing. I’m a bit >>> suspicious of all those constraints for the top pane, which should really >>> be only four, one for each edge of the text view. Could you expand that >>> pane a bit more so I can see the descriptions of all those constraints a >>> little better? >>> >>> Charles >> >> >> ___ >> >> 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: turning app into background app
On Jul 8, 2012, at 5:52 AM, "Rick C." wrote: > I did read that I could set my app to have LSUIElement - YES by default and > then use TransformProcessType to unhide it since there is no way to do it in > reverse. 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. -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
Open Recent Menu
In some situations, it is worthwhile to subclass NSDocumentController in non-NSDocument-based applications to get some of its features. For example, the NSDocumentController management of the Open Recent menu is useful in applications that don’t use subclasses of NSDocument. I have subclassed NSDocumentController. I have the Menu structure for there Open Recent menu. I use -noteNewRecentDocumentURL: Yet, I get no entries in the Menu. Where should I look? -koko code === in -windowDidLoad m_documentController = [[NSDocumentController alloc] init]; [m_documentController retain]; in my open action NSURL *url = [NSURL fileURLWithPath:path]; [m_documentController noteNewRecentDocumentURL:url]; ___ 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: NSInteger vs int vs int32_t
On Jul 9, 2012, at 5:44 AM, Vincent Habchi wrote: > Modern CPU do not enforce strict alignment for integer access. You can > perfectly access a Dword (64 bits) at any address, even or odd. It is just > more efficient to align 64-bits words at 8-bytes boundary, 32-bits at > 4-bytes, etc. This contrasts with the old times: for example, on a 68000 > processor, trying to access a 16-bit word at an odd address (e.g. move.w d0, > (a0)+ with a0 odd) would result in a exception n°3 (address error). Some CPUs still enforce aligned integer access, such as the ARM CPUs in some iOS devices. If your iOS crash log says EXC_ARM_DA_ALIGN then you died from a misalignment fault. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: NSInteger vs int vs int32_t
On 9 juil. 2012, at 20:40, Greg Parker wrote: > On Jul 9, 2012, at 5:44 AM, Vincent Habchi wrote: >> Modern CPU do not enforce strict alignment for integer access. You can >> perfectly access a Dword (64 bits) at any address, even or odd. It is just >> more efficient to align 64-bits words at 8-bytes boundary, 32-bits at >> 4-bytes, etc. This contrasts with the old times: for example, on a 68000 >> processor, trying to access a 16-bit word at an odd address (e.g. move.w d0, >> (a0)+ with a0 odd) would result in a exception n°3 (address error). > > Some CPUs still enforce aligned integer access, such as the ARM CPUs in some > iOS devices. Oh, thanks for mentioning this. I was obviously thinking about Intel CPUs. I know very little about ARM. By the way, you can also access misaligned instructions on x86 processors I think, something that was not possible on 68000. If I remember correctly, the integer alignment enforcement was lifted on the 68030, which leaded to interesting hardware developments… Vincent ___ 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 1:33 PM, Eric Schlegel wrote: > On Jul 8, 2012, at 5:52 AM, "Rick C." wrote: > >> I did read that I could set my app to have LSUIElement - YES by default and >> then use TransformProcessType to unhide it since there is no way to do it in >> reverse. > > 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? Cheers, Ken ___ 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: Open Recent Menu
The URLs are returned by: -recentDocumentURLs They are just not in the menu. -koko On Jul 9, 2012, at 12:34 PM, koko wrote: > In some situations, it is worthwhile to subclass NSDocumentController in > non-NSDocument-based applications to get some of its features. For example, > the NSDocumentController management of the Open Recent menu is useful in > applications that don’t use subclasses of NSDocument. > > I have subclassed NSDocumentController. > > I have the Menu structure for there Open Recent menu. > > I use -noteNewRecentDocumentURL: > > Yet, I get no entries in the Menu. > > Where should I look? > > -koko > > > code > === > in -windowDidLoad > >m_documentController = [[NSDocumentController alloc] init]; >[m_documentController retain]; > > in my open action > >NSURL *url = [NSURL fileURLWithPath:path]; >[m_documentController noteNewRecentDocumentURL:url]; > > ___ > > 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/koko%40highrolls.net > > This email sent to k...@highrolls.net ___ 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 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSInteger vs int vs int32_t
At 10:05 AM -0600 7/5/12, Scott Ribe wrote: And theoretically, moving from 32-bit to 64-bit executable could slow you down because of fewer pointers fitting in cache--however the few people I've ever heard mention that were, in my opinion, seriously overblowing it. In my experience with data & algorithm heavy code, just switching from 32- to 64-bit produces about a 10% performance boost, because of the advantages of x86-64 (more registers and so on). Now you may be getting to the crux of the matter: For a processor family with reasonably clean 32- and 64-bit models (i.e. PowerPC) going to 64-bit is a speed hit in many circumstances due to the increase in size of everything. However, i386 has so much baggage and so few registers that the performance gain from x86-64's much less sucky architecture/runtime more than makes up for the loss due to memory bloat. ;-) -Steve ___ 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 Mon, 9 Jul 2012 11:03:50 -0500, Fritz Anderson said:
>You correctly describe the cycle. In practice, NSOperationQueue probably
>releases the block when it's done with it, and breaks the cycle, but
>clang can't know that, so it has to warn of the "likely" cycle.
>
>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;
> }];
A contortion I guess those of us switching from GC to ARC will have to sprinkle
around. :( Shame.
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
___
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: Arrgh IB constraints
On Jul 9, 2012, at 10:33 AM, Kevin Cathey wrote: >> BTW, if the NSSplitView hasn't been updated to use constraints in its own >> layout, then why does it and up changing the size at runtime? For that >> matter it seems like IB is expressly forbidding adding constraints to the >> NSSplitView's panes. > There are known bugs with NSSplitView and auto layout on OS X 10.7 with both > the runtime and with IB. Mainly, even if you say a particular pane should be > >= 100 (for example), you can still drag the splitter right past the 100pt > mark. > > See the WWDC videos from this year for more information… Conversing via private e-mail last night, we figured out that the problem was triggered by having a combination of an NSSplitView and an NSToolbar in the same window. Doing this even in a simple test-case app causes the split view to wig out. If you delete the toolbar, it works fine. Bug report filed: rdar://11828261 . Charles ___ 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 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? -- Shane Stanley 'AppleScriptObjC Explored' ___ 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
NSComboBox fails to notify delegate?
Hi All, My NSViewController is the delegate of five different combo boxes in its view but the delegate methods are not being called. They do get called sometimes, but usually they do not. I haven't found exactly what the situation is where the delegate methods get called. I implement comboBoxWillPopUp: and comboBoxWillDismiss: to disable the default button so that the user can tab to the combo, use the keyboard to make a selection, and hit Return to select an item without firing the default button's action. I have checked that my instance is the delegate and responds to the delegate methods. I even subclassed NSComboBox to override mouseDown: to see what the backtrace shows and what I see is that when it works, a notification is sent, when it fails, the notification is not sent. Does anyone have any idea about what I could be doing wrong? It's killing me for two reasons. One is that I do this in a few other places that use combo boxes and the other is that there is no other way to do it. I have to know when the combo pops up and dismisses and those methods are not public. If anyone can point me in the right direction, I'll really appreciate it. Thanks Marc ___ 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
Thank you very much I overlooked this! rc On Jul 10, 2012, at 2:33 AM, Eric Schlegel wrote: > > On Jul 8, 2012, at 5:52 AM, "Rick C." wrote: > >> I did read that I could set my app to have LSUIElement - YES by default and >> then use TransformProcessType to unhide it since there is no way to do it in >> reverse. > > 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. > > -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
Re: turning app into background app
On Jul 9, 2012, at 1:33 PM, Eric Schlegel wrote: > On Jul 8, 2012, at 5:52 AM, "Rick C." wrote: > >> I did read that I could set my app to have LSUIElement - YES by default and >> then use TransformProcessType to unhide it since there is no way to do it in >> reverse. > > 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. > > -eric I notice that in the headers, the new constants are marked "functional in Mac OS X Barolo and later.” Was Barolo an early code-name for Lion, or does this refer to one of the various 10.7.x updates? Charles ___ 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 1:33 PM, Eric Schlegel wrote: > On Jul 8, 2012, at 5:52 AM, "Rick C." wrote: > >> I did read that I could set my app to have LSUIElement - YES by default and >> then use TransformProcessType to unhide it since there is no way to do it in >> reverse. > > 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. > > -eric Also, I just tried this out, and it seems that it always converts the app into a background-only app, even if I specify to convert it to a UIElement app. If it has any windows open, they disappear and don’t come back until I convert it back to a foreground app, which doesn’t seem to be the correct behavior for LSUIElement. Charles ___ 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: Open Recent Menu
On 10/07/2012, at 4:34 AM, koko wrote: > In some situations, it is worthwhile to subclass NSDocumentController in > non-NSDocument-based applications to get some of its features. For example, > the NSDocumentController management of the Open Recent menu is useful in > applications that don’t use subclasses of NSDocument. > > I have subclassed NSDocumentController. > > I have the Menu structure for there Open Recent menu. > > I use -noteNewRecentDocumentURL: > > Yet, I get no entries in the Menu. > > Where should I look? Emphasis on: >> useful in applications that don’t use subclasses of NSDocument Why are you doing this? This situation doesn't apply in your case. Just leave things as they are and the recent items menu will work normally. In any case the way you are creating your NSDocumentController is completely wrong. It must be done extremely early on in the launch of an app since it's a singleton instance that has to be available for all document objects that get created from the very first. The default NSDocumentController will work properly if you let it. --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
Re: One more try - NSCollectionView multi-selection problem..
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: > > [number of indexes: 2 (in 2 ranges), indexes: (2 4)] > > I would have expected something like this: > [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: Open Recent Menu
The problem was the menu, Open Recent. This is not a NSDocument app and as such had no such menu. I created my own but not didi not get items. So, I added a new File menu from IB, dragged its OPen recent entry to my File menu, deleted the File menu just added. And now it all works. -koko On Jul 9, 2012, at 7:25 PM, Graham Cox wrote: > > On 10/07/2012, at 4:34 AM, koko wrote: > >> In some situations, it is worthwhile to subclass NSDocumentController in >> non-NSDocument-based applications to get some of its features. For example, >> the NSDocumentController management of the Open Recent menu is useful in >> applications that don’t use subclasses of NSDocument. >> >> I have subclassed NSDocumentController. >> >> I have the Menu structure for there Open Recent menu. >> >> I use -noteNewRecentDocumentURL: >> >> Yet, I get no entries in the Menu. >> >> Where should I look? > > > > > Emphasis on: > >>> useful in applications that don’t use subclasses of NSDocument > > > Why are you doing this? > > This situation doesn't apply in your case. Just leave things as they are and > the recent items menu will work normally. > > In any case the way you are creating your NSDocumentController is completely > wrong. It must be done extremely early on in the launch of an app since it's > a singleton instance that has to be available for all document objects that > get created from the very first. > > The default NSDocumentController will work properly if you let it. > > > --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
Re: Tab Bar Item naming convention?
On Thu, Jul 5, 2012 at 10:31 PM, Laurent Daudelin wrote: > But, do I follow the same naming convention as for the app icon by adding a > "@2x" to the file name? Absolutely. That's a general convention for naming hidpi resources. https://developer.apple.com/library/ios/documentation/2DDrawing/Conceptual/DrawingPrintingiOS/SupportingHiResScreens/SupportingHiResScreens.html#//apple_ref/doc/uid/TP40010156-CH15-SW8 ___ 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
Field Editor told to replace range {0, NSUIntegerMax} : Range Exception
I'm working on a custom control (a token field), and apparently I've messed
with the field editor somehow. When I (as user) click on my control, but not
in the focused NSTextView which is the field editor, and then type a character,
a message is sent to the field editor telling it to replace text in the range
{0, NSUIntegerMax} with the character that I typed. (I see this by debugging
into -[NSTextView(NSSharing) shouldChangeTextInRange:replacementString:].) An
range exception is raised because the field editor contains an empty string at
this time.
I suppose I could fix this by using a custom field editor and overriding that
method, but I want the root cause. Has anyone ever seen behavior like this?
As you can see from the edited call stack below, it all happens in Cocoa
methods. The NSTextView in lines 8-10 is indeed the field editor.
Thanks,
Jerry Krinock
An uncaught exception was raised
*** -[NSBigMutableString substringWithRange:]: Range or index out of bounds
0 CoreFoundation __raiseError + 231
1 libobjc.A.dylib objc_exception_throw + 155
2 CoreFoundation +[NSException raise:format:arguments:] + 137
3 CoreFoundation +[NSException raise:format:] + 57
4 Foundation -[NSString substringWithRange:] + 111
5 AppKit -[NSTextStorage(NSUndo)
_undoRedoAttributedSubstringFromRange:] + 171
6 AppKit -[NSUndoTyping
initWithAffectedRange:layoutManager:undoManager:replacementRange:] + 181
7 AppKit -[NSTextViewSharedData
coalesceInTextView:affectedRange:replacementRange:] + 440
8 AppKit -[NSTextView(NSSharing)
shouldChangeTextInRanges:replacementStrings:] + 1779
9 AppKit -[NSTextView(NSSharing)
shouldChangeTextInRange:replacementString:] + 123
10 AppKit -[NSTextView insertText:replacementRange:] + 498
11 AppKit -[NSTextInputContext insertText:replacementRange:] + 430
12 AppKit -[NSTextInputContext handleTSMEvent:] + 2654
13 AppKit _NSTSMEventHandler + 214
14 HIToolbox
_Z22_InvokeEventHandlerUPPP25OpaqueEventHandlerCallRefP14OpaqueEventRefPvPFlS0_S2_S3_E
+ 36
15 HIToolbox
_ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec
+ 1602
16 HIToolbox
_ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
+ 482
17 HIToolbox SendEventToEventTarget + 76
18 HIToolbox SendTSMEvent + 74
19 HIToolbox SendUnicodeTextAEToUnicodeDoc + 753
20 HIToolbox TSMKeyEvent + 1007
21 HIToolbox TSMProcessRawKeyEvent + 2795
22 AppKit -[NSTextInputContext handleEvent:] + 1257
23 AppKit -[NSView interpretKeyEvents:] + 220
24 AppKit -[NSTextView keyDown:] + 676
25 AppKit -[NSWindow sendEvent:] + 10891
26 AppKit -[NSApplication sendEvent:] + 4788
27 AppKit -[NSApplication run] + 1007
28 AppKit NSApplicationMain + 1054
29 TestApp main + 245
30 TestApp start + 53
___
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 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
___
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 5:58 PM, Charles Srstka wrote: > I notice that in the headers, the new constants are marked "functional in Mac > OS X Barolo and later.” Was Barolo an early code-name for Lion Yes. > Also, I just tried this out, and it seems that it always converts the app > into a background-only app, even if I specify to convert it to a UIElement > app. If it has any windows open, they disappear and don’t come back until I > convert it back to a foreground app, which doesn’t seem to be the correct > behavior for LSUIElement. That's unfortunate, but not too surprising. This feature was added and primarily used for the Lion capability of turning a foreground app into a background-only app when the app is deactivated with no windows open. The convert-to-UIElement path probably hasn't been tested as well (if at all). Feel free to file a bug about your results. -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
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: >> >> [number of indexes: 2 (in 2 ranges), indexes: (2 4)] >> >> I would have expected something like this: >> [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
