Prioritizing UIScrollView gestures over buttons

[Rick Mann]

I have a set of buttons that live above (not subviews of) a UIScrollView. I 
update their position based on feedback from the UIScrollView during pan and 
zoom.

The problem is, the buttons are easy to tap accidentally when you're trying to 
pan or zoom. Is there a magic setting to let taps in the buttons first serve 
gestures in the UIScrollView? I can re-implement them as views with a tap 
gesture recognizer if that would help.


-- 
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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: GNUstep Kickstarter Project

[Reaves, Timothy]

No,  not really.

On Thu, Aug 15, 2013 at 5:02 PM, Lars Sonchocky-Helldorf <
lars.sonchocky-helld...@hamburg.de> wrote:

> Hi list,
>
> I've got this from the lead developer of GNUstep, maybe some of you are
> interested in this.
>
> cheers,
>
> Lars
>
> Anfang der weitergeleiteten E-Mail:
>
> > Von: Gregory Casamento 
> > Datum: 12. August 2013 22:13:54 MESZ
> > An: Discuss-gnustep Discuss 
> > Betreff: GNUstep Kickstarter Project
> >
> > Hey guys, I've launched a kickstarter project in the hopes of getting
> some time to work exclusively on GNUstep in order to try to address some of
> the issues we have surrounding API completeness, documentation issues,
> etc..., here it is:
> >
> > http://www.kickstarter.com/projects/203272607/gnustep-project
> >
> > Thanks, GC
> > --
> > Gregory Casamento
> > Open Logic Corporation, Principal Consultant
> > yahoo/skype: greg_casamento, aol: gjcasa
> > (240)274-9630 (Cell)
> > http://www.gnustep.org
> > http://heronsperch.blogspot.com
> > ___
> > Discuss-gnustep mailing list
> > discuss-gnus...@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
>
> ___
>
> 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/treaves%40silverfieldstech.com
>
> This email sent to trea...@silverfieldstech.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: Uniquing data in Core Data

[Rick Mann]

Doesn't work for sorting in NSFetchedresultsController

On Aug 15, 2013, at 16:34 , Sandor Szatmari  
wrote:

> Can you make it a derived property?  If each Managed object has a reference 
> to the AppDelegate they can just return the comparison of their 
> NSManagedObjectID to the one stored as the user default.
> 
> Sandor Szatmari
> 
> On Aug 15, 2013, at 1:07, Rick Mann  wrote:
> 
>> 
>> On Aug 14, 2013, at 21:14 , Jerry Krinock  wrote:
>> 
>>> 
>>> On 2013 Aug 14, at 20:46, Keary Suska  wrote:
>>> 
 A cleaner approach, IMHO, is to have a holder entity whose sole attribute 
 is a to-one relationship to your other entity. Think of it as a singleton 
 that always exist and maintains the particular managed object.
>>> 
>>> Indeed Keary's idea is much better, and furthermore you may well already 
>>> such an existing "singleton" entity nearby in that data model, which would 
>>> be the logical place for this to-one relationship.  Just add this 
>>> relationship to that existing "singleton" entity.
>> 
>> On Aug 14, 2013, at 20:46 , Keary Suska  wrote:
>> 
>>> On Aug 14, 2013, at 6:28 PM, Rick Mann wrote:
>>> 
 I have a boolean property on an Entity for which only one should ever be 
 true. Is it really bad to implement a custom setter that loads every other 
 instance in the MOC that's true and sets them all to false? My code is 
 actually good about always clearing the current one before setting the new 
 one, but when I'm debugging, I will copy data over from another device, 
 and it can't clear the old one in this case.
>>> 
>>> I am not sure if it bad, but it sure smells funny ;-) Anyway, the issue may 
>>> be more of the data approach. It is likely that the boolean attribute 
>>> shouldn't belong to the entity at all--i.e. that the attribute is really 
>>> for needed by some other object or process and is not a function of the 
>>> entity. A cleaner approach, IMHO, is to have a holder entity whose sole 
>>> attribute is a to-one relationship to your other entity. Think of it as a 
>>> singleton that always exist and maintains the particular managed object. It 
>>> also requires no code at all to maintain uniqueness--simply assign the 
>>> relationship.
>> 
>> Well, I used to store the active instance as a property of my app 
>> (AppDelegate). I'd store the NSManagedObjectID as a user default.
>> 
>> Unfortunately, I need to be able to sort on the boolean property, and on an 
>> NSFetchedResultsController at that, which won't sort on transient properties.
>> 
>> Moreover, it seems extraordinarily clumsy to have another entity 
>> representing the app, and to only have a singleton of that.
>> 
>> -- 
>> 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/admin.szatmari.net%40gmail.com
>> 
>> This email sent to admin.szatmari@gmail.com


-- 
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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Uniquing data in Core Data

[Sandor Szatmari]

Can you make it a derived property?  If each Managed object has a reference to 
the AppDelegate they can just return the comparison of their NSManagedObjectID 
to the one stored as the user default.

Sandor Szatmari

On Aug 15, 2013, at 1:07, Rick Mann  wrote:

> 
> On Aug 14, 2013, at 21:14 , Jerry Krinock  wrote:
> 
>> 
>> On 2013 Aug 14, at 20:46, Keary Suska  wrote:
>> 
>>> A cleaner approach, IMHO, is to have a holder entity whose sole attribute 
>>> is a to-one relationship to your other entity. Think of it as a singleton 
>>> that always exist and maintains the particular managed object.
>> 
>> Indeed Keary's idea is much better, and furthermore you may well already 
>> such an existing "singleton" entity nearby in that data model, which would 
>> be the logical place for this to-one relationship.  Just add this 
>> relationship to that existing "singleton" entity.
> 
> On Aug 14, 2013, at 20:46 , Keary Suska  wrote:
> 
>> On Aug 14, 2013, at 6:28 PM, Rick Mann wrote:
>> 
>>> I have a boolean property on an Entity for which only one should ever be 
>>> true. Is it really bad to implement a custom setter that loads every other 
>>> instance in the MOC that's true and sets them all to false? My code is 
>>> actually good about always clearing the current one before setting the new 
>>> one, but when I'm debugging, I will copy data over from another device, and 
>>> it can't clear the old one in this case.
>> 
>> I am not sure if it bad, but it sure smells funny ;-) Anyway, the issue may 
>> be more of the data approach. It is likely that the boolean attribute 
>> shouldn't belong to the entity at all--i.e. that the attribute is really for 
>> needed by some other object or process and is not a function of the entity. 
>> A cleaner approach, IMHO, is to have a holder entity whose sole attribute is 
>> a to-one relationship to your other entity. Think of it as a singleton that 
>> always exist and maintains the particular managed object. It also requires 
>> no code at all to maintain uniqueness--simply assign the relationship.
> 
> Well, I used to store the active instance as a property of my app 
> (AppDelegate). I'd store the NSManagedObjectID as a user default.
> 
> Unfortunately, I need to be able to sort on the boolean property, and on an 
> NSFetchedResultsController at that, which won't sort on transient properties.
> 
> Moreover, it seems extraordinarily clumsy to have another entity representing 
> the app, and to only have a singleton of that.
> 
> -- 
> 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/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.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: Find bar in a text view

[Shane Stanley]

On 16/08/2013, at 2:27 AM, Kevin Perry  wrote:

> Sounds like a bug that you should report via Bug Reporter.

Thanks, I'd done that (#14745599). It also happens if a text view is on a tab 
view and you change tabs, except it then also moves rather dramatically (in my 
case partly outside the window area).
> 
> But as a workaround, you should be able to call -[NSTextView 
> setIncrementalSearchingEnabled:NO] when the subview gets collapsed (then 
> obviously set it back to YES when the text view is uncollapsed, though you 
> will lose search results in doing so).

That's a thought, thanks.

-- 
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

Re: Menu item key equiv mods not correct

[Steve Mills]

On Aug 15, 2013, at 14:39:56, Ken Thomases  wrote:

> Shifted key equivalents which use letter keys are usually represented with 
> capital letters, not NSShiftKeyMask.  You're using a case-insensitive match, 
> so you're catching those.  Use a case-sensitive match and you should be fine.

@#$#$%$&! I hate that. Thanks again for saving the day, Ken.

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157



___

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

Fwd: GNUstep Kickstarter Project

[Lars Sonchocky-Helldorf]

Hi list,

I've got this from the lead developer of GNUstep, maybe some of you are 
interested in this.

cheers,

Lars

Anfang der weitergeleiteten E-Mail:

> Von: Gregory Casamento 
> Datum: 12. August 2013 22:13:54 MESZ
> An: Discuss-gnustep Discuss 
> Betreff: GNUstep Kickstarter Project
> 
> Hey guys, I've launched a kickstarter project in the hopes of getting some 
> time to work exclusively on GNUstep in order to try to address some of the 
> issues we have surrounding API completeness, documentation issues, etc..., 
> here it is:
> 
> http://www.kickstarter.com/projects/203272607/gnustep-project
> 
> Thanks, GC
> -- 
> Gregory Casamento
> Open Logic Corporation, Principal Consultant
> yahoo/skype: greg_casamento, aol: gjcasa
> (240)274-9630 (Cell)
> http://www.gnustep.org
> http://heronsperch.blogspot.com
> ___
> Discuss-gnustep mailing list
> discuss-gnus...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


___

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: Menu item key equiv mods not correct

[Ken Thomases]

On Aug 15, 2013, at 2:31 PM, Steve Mills wrote:

> When adding some certain-mode-only menus, we scan the existing menus to 
> temporarily remove key equivs that are also in the new menu. They're put back 
> later. However, something isn't right when I ask for each menu item's 
> modifiers. Our Edit menu has Select All, which is command-a. Another menu to 
> the right of it has an item whose equiv is command-shift-a. Everything's 
> hunky dory with those. Then we go to add the new menu, which also uses 
> command-a. We first find the Select All menu which uses the same equiv, so we 
> remove it. But then it also find the other item which uses command-shift-a. 
> Here's the code that looks for matching equivs:
> 
> if([item.keyEquivalent length] && ([item.keyEquivalent compare:keyToMatch 
> options:NSCaseInsensitiveSearch] == NSOrderedSame) && 
> item.keyEquivalentModifierMask == modsToMatch)
> 
> Both values are very clearly 0x10, which is only NSCommandKeyMask. But 
> where's the shift key bit? The menu item's mods should be 0x12. Any ideas 
> about why it's wrong?

Shifted key equivalents which use letter keys are usually represented with 
capital letters, not NSShiftKeyMask.  You're using a case-insensitive match, so 
you're catching those.  Use a case-sensitive match and you should be fine.

Regards,
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

Menu item key equiv mods not correct

[Steve Mills]

When adding some certain-mode-only menus, we scan the existing menus to 
temporarily remove key equivs that are also in the new menu. They're put back 
later. However, something isn't right when I ask for each menu item's 
modifiers. Our Edit menu has Select All, which is command-a. Another menu to 
the right of it has an item whose equiv is command-shift-a. Everything's hunky 
dory with those. Then we go to add the new menu, which also uses command-a. We 
first find the Select All menu which uses the same equiv, so we remove it. But 
then it also find the other item which uses command-shift-a. Here's the code 
that looks for matching equivs:

if([item.keyEquivalent length] && ([item.keyEquivalent compare:keyToMatch 
options:NSCaseInsensitiveSearch] == NSOrderedSame) && 
item.keyEquivalentModifierMask == modsToMatch)

Both values are very clearly 0x10, which is only NSCommandKeyMask. But 
where's the shift key bit? The menu item's mods should be 0x12. Any ideas 
about why it's wrong?

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157



___

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

iOS UITableViewCell imageView

[Alex Zavatone]

Anyone know how to properly set the borderWidth on a UITableViewCell's 
image.imageView layer?

Setting the layer's borderWidth and borderColor work just fine on a 
UITableViewCell's layer, when setting them in tableView:cellForRowAtIndexPath, 
but the same code on the cell.imageView.layer has no effect at all.

I've searched through StackOverflow and have found answers that all look 
similar, but all with no visual effect on the resulting image.

In Xcode 4.3 on iOS 6.x

This works fine to put very obvious borders around the cell:

   UITableViewCell *cell = [tableView 
dequeueReusableCellWithIdentifier:CellIdentifier];

   cell.imageView.image = [UIImage imageNamed:@"myImage.png"];

   CALayer *layer;
   //layer = cell.layer; // -- I work just fine
   //layer = cell.imageView.layer; // -- I do nothing
   [layer setMasksToBounds:YES];
   [layer setCornerRadius:10.0f];
   [layer setBorderWidth:10.0f];

If you uncomment the first layer line and run the app, there is a large black 
border around the cell, but if you uncomment the second and run there is no 
effect on the image at all.

Any ideas what I'm missing here?  Thanks in advance.

- Alex Zavatone
___

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: Auto layout semantics?

[Fritz Anderson]

On 15 Aug 2013, at 11:33 AM, Izak van Langevelde  wrote:

> I wasted some time trying to use auto layout to maintain the layout of a 
> form, to make sure that fields are horizontally resized with the form, while 
> labels maintain their size. However, when two fields are sitting next to each 
> other, having the same priority, only one of them resizes with the form.  Is 
> there any documentation around that specifies how layout constraints are 
> resolved?

There is a lot that describes the process of resolving constraints, starting 
with 
.
 Assuming your have that information down, your problem may be that Xcode 4's 
Interface Builder is fighting you.

Most of what you need to do can be reasoned-through from two principles: 
Constraints on a view have to be sufficient to specify its size and placement 
so there is no more than one solution; and consistent, so they yield no less 
than one solution.

Interface Builder in Xcode 4 "helpfully" enforces sufficiency by automatically 
creating constraints according to the "making s*** up" algorithm*, and not 
letting you change or delete them. There's a menu at the lower-right that 
relieves the upstream and downstream effects so you can be free to adjust 
placements; and you can delete IB's constraints by first adding a sufficient 
constraint chain of your own.

* (The responsible engineers did a respectable job, but the result is opaque 
and frustrating. I know Dev Tools has made this a top priority.)

Do I understand correctly that you have a row in your form that looks like:

|--Label1-Field1--Label2-Field2 --|

? (Not intended to be a constraint-specification format.) And you want Label1 
and Label2 to be of fixed (identical?) size, and Field1 and Field2 to have 
variable (equal?) size according to the width of the superview?

If I'm not correct, the rest is TL;DR. Caveat that I'm working off the top of 
my head on my lunch hour, and drawing suggestions from the same place Xc4 gets 
automatic constraints. This is "what I'd try next."

I'll comment only on the horizontal axis. I'm not going to comment on getting 
spacing and alignment from other elements in the view (like the rows above and 
below).

All the horizontal-spacing constraints should be of constant size, and 1000 
priority.

The labels should have either numerically-constant widths, or you could turn up 
the priority on their horizontal compression resistance. The latter will mean 
that if a localization requires more or less room for the text, the label will 
expand accordingly but take up no more room than necessary. Consider an 
additional width constraint of ≥ some number.

Don't allow any placement constraints that aren't between immediate neighbors. 
It's easy to pick those up (and until the whole horizontal chain is solved, IB 
may insist on imposing them), but you aren't finished until duplicate or 
extraneous spacing constraints are gone. (Frequently one has to vary from this 
rule-of-thumb, but it's what I start from.)

That leaves the problem of the fields. If you are happy making them of equal 
size, your work is done; the whole chain is determined. If you know only 
minimum or maximum sizes, that isn't sufficient (and IB-Xc4 may force 
constraints of its own on you). If the min/max sizes are all you have, the 
chain is indeterminate, and when you resize the container, the change may be 
allocated to one, maybe to the other, there's no sure way to know in advance; 
whatever happens, the constraints you do have wouldn't be contradicted.

I don't know of a graphical way to set non-equal distributions of width 
changes. (Meaning, I think there is none, but I'm too weaselly to commit to 
it.) I think — I've never done this, and I don't have time to try — you can do 
it in code. Create an NSLayoutConstraint from one field to the next, on 
NSLayoutAttributeWidth, relation equal, but the multiplier and constant set up 
so that the first width is related to the second by:

width1 = multiplier * width2 + constant

Once you work out the proportions, the whole chain will be determined, and it 
should do what you want. Definitely set a minimum width on the smaller field, 
or it could be compressed to or below zero.

(An NSMutableLayoutConstraint would be _extremely_ helpful here. Radar in 
process.)

— 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: Auto layout semantics?

[Kyle Sluder]

On Thu, Aug 15, 2013, at 09:33 AM, Izak van Langevelde wrote:
> I wasted some time trying to use auto layout to maintain the layout of a
> form, to make sure that fields are horizontally resized with the form,
> while labels maintain their size. However, when two fields are sitting
> next to each other, having the same priority, only one of them resizes
> with the form.  Is there any documentation around that specifies how
> layout constraints are resolved?

That's the canonical example of an ambiguous layout. You use priorities
to tell the auto layout system which views to resize.

Have you read the Cocoa Auto Layout Guide?
http://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/Articles/Introduction.html

--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

Auto layout semantics?

[Izak van Langevelde]

I wasted some time trying to use auto layout to maintain the layout of a form, 
to make sure that fields are horizontally resized with the form, while labels 
maintain their size. However, when two fields are sitting next to each other, 
having the same priority, only one of them resizes with the form.  Is there any 
documentation around that specifies how layout constraints are resolved?

Thanks,
Izak
---
Grinnikend door het leven...


___

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: Find bar in a text view

[Kevin Perry]

Sounds like a bug that you should report via Bug Reporter.

But as a workaround, you should be able to call -[NSTextView 
setIncrementalSearchingEnabled:NO] when the subview gets collapsed (then 
obviously set it back to YES when the text view is uncollapsed, though you will 
lose search results in doing so).

-KP

On Aug 15, 2013, at 4:59 AM, Shane Stanley  wrote:

> I have text views in a split view, and I use find bars with them. I'd like to 
> implement incremental searching. When I turn it on in IB  it works, except 
> that if I collapse a subview showing the grey overlay, the overlay remains on 
> screen. As a workaround, the documentation says I can turn the overlay off I 
> should set the incrementalSearchingShouldDimContentView property to NO.
> 
> The problem is that the find bar is all pre-implemented by NSTextView, and I 
> can't see how to address the NSTextFinder instance. Any suggestions, or do I 
> need to implement my own NSTextFinder instance?
> 
> -- 
> 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/kperry%40apple.com
> 
> This email sent to kpe...@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: Block gets NULL-ified when animation completes

[Ken Thomases]

On Aug 15, 2013, at 9:49 AM, Jens Alfke wrote:

> On Aug 15, 2013, at 5:41 AM, Vlad Alekseev  wrote:
> 
>> dispatch_block_t block = ^{
>>   printf("finished");
>> };
>> 
>> UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout 
>> *)self.collectionView.collectionViewLayout;
>> [self.collectionView performBatchUpdates:^{
>>   layout.minimumInteritemSpacing = 20;
>> } completion:^(BOOL finished) {
>>   block();
>> }];
> 
> As I said before, this is a bug in your code. ‘block’ needs to be copied 
> since it is going to be called after the calling function returns.
> 
> Yes, the collection view copies the completion block you pass it. But that 
> block is not ‘block’, it’s the inline block literal that calls ‘block’. That 
> gets copied, but when that is called it still tries to call the uncopied 
> ‘block’, which fails.

When a block gets copied, it copies any blocks it has captured.  So, the fact 
that the completion block is copied by the framework code is sufficient.
https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/Blocks/Articles/bxVariables.html#//apple_ref/doc/uid/TP40007502-CH6-SW7

Regards,
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: Block gets NULL-ified when animation completes

[Vlad Alekseev]

> As I said before, this is a bug in your code. ‘block’ needs to be copied 
> since it is going to be called after the calling function returns.


I work under ARC. It goes to heap automatically.

Also, there are some circumstances that proves your wrong guess:

1. If I copy it manually, it still gets NULLified. 
2. If there are some items in the collection view, it works as expected, no 
explicit copy needed.

So it seems for me like a bug in the ARC/runtime or in the collection view 
(unlikely).

Vlad.

15 авг. 2013 г., в 18:49, Jens Alfke  написал(а):

> 
> On Aug 15, 2013, at 5:41 AM, Vlad Alekseev  wrote:
> 
>> dispatch_block_t block = ^{
>>printf("finished");
>> };
>> 
>> UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout 
>> *)self.collectionView.collectionViewLayout;
>> [self.collectionView performBatchUpdates:^{
>>layout.minimumInteritemSpacing = 20;
>> } completion:^(BOOL finished) {
>>block();
>> }];
> 
> 
> Yes, the collection view copies the completion block you pass it. But that 
> block is not ‘block’, it’s the inline block literal that calls ‘block’. That 
> gets copied, but when that is called it still tries to call the uncopied 
> ‘block’, which fails.
> 
> —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: Block gets NULL-ified when animation completes

[Jens Alfke]

On Aug 15, 2013, at 5:41 AM, Vlad Alekseev  wrote:

> dispatch_block_t block = ^{
>printf("finished");
> };
> 
> UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout 
> *)self.collectionView.collectionViewLayout;
> [self.collectionView performBatchUpdates:^{
>layout.minimumInteritemSpacing = 20;
> } completion:^(BOOL finished) {
>block();
> }];

As I said before, this is a bug in your code. ‘block’ needs to be copied since 
it is going to be called after the calling function returns.

Yes, the collection view copies the completion block you pass it. But that 
block is not ‘block’, it’s the inline block literal that calls ‘block’. That 
gets copied, but when that is called it still tries to call the uncopied 
‘block’, which fails.

—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: Dismissing Open dlog before doc actually opens

[Steve Mills]

On Aug 15, 2013, at 06:41:49, Kyle Sluder  wrote:

> This is only true for sandboxed apps, but it is a very good point. If Steve's 
> app is sandboxed, it needs to forward the- orderOut: message to Powerbox over 
> XPC. That would require running the runloop.

It is not sandboxed.

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157



___

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: Dismissing Open dlog before doc actually opens

[Steve Mills]

On Aug 14, 2013, at 04:14:58, Uli Kusterer  wrote:

> I vaguely remember having the same issue where an open panel stayed open too 
> long. I think it might be related to autorelease pools holding on to the 
> actual window-owning object (some private thing, I think). You might want to 
> try creating an inner pool and releasing that right when you want the panel 
> to close.

Yup, I tried that at one point, hoping it would fix it, but it did not. The 
solution I have (see runUntilDate: in this thread) is working.

--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157



___

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: Block gets NULL-ified when animation completes

[Vlad Alekseev]

Turns out, this is a bug in UICollectionView or even ARC. And it is easily 
reproducible. You can download Apple's sample code:

http://developer.apple.com/library/ios/samplecode/CollectionView-Simple/Introduction/Intro.html

and modify it to return 0 items to the collection view. Then try to perform the 
following code:

dispatch_block_t block = ^{
printf("finished");
};

UICollectionViewFlowLayout *layout = (UICollectionViewFlowLayout 
*)self.collectionView.collectionViewLayout;
[self.collectionView performBatchUpdates:^{
layout.minimumInteritemSpacing = 20;
} completion:^(BOOL finished) {
block();
}];

It will crash since `finish` will be `nil`. But if you make data source to 
return non-zero item count to the collection view then everything will work 
good.

Created a bug report with ID 14744561. Affects iOS 6.0 and above. 

You may refer to the Apple Dev Forums discussion thread: 
https://devforums.apple.com/thread/198531?tstart=0

Thanks!

Vlad.

15 авг. 2013 г., в 9:25, Vlad Alekseev  написал(а):

> Hey,
> 
> ARC should drive this for me. If it wouldn’t, then it wouldn’t work in case 
> if there are items in the collection view.
> Tried to copy manually - no results. BTW, not only «finish», but also 
> «completion» gets NULLified at the last step.
> 
> Vlad.
> 
> 15 авг. 2013 г., в 9:22, Jens Alfke  написал(а):
> 
>> Sounds like you forgot to copy the block — if it’s being invoked after the 
>> calling function returns (as a completion handler would) it needs to be 
>> copied so it can survive the loss of its original stack frame.
>> 
>> —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

Find bar in a text view

[Shane Stanley]

I have text views in a split view, and I use find bars with them. I'd like to 
implement incremental searching. When I turn it on in IB  it works, except that 
if I collapse a subview showing the grey overlay, the overlay remains on 
screen. As a workaround, the documentation says I can turn the overlay off I 
should set the incrementalSearchingShouldDimContentView property to NO.

The problem is that the find bar is all pre-implemented by NSTextView, and I 
can't see how to address the NSTextFinder instance. Any suggestions, or do I 
need to implement my own NSTextFinder instance?

-- 
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

Re: Dismissing Open dlog before doc actually opens

[Kyle Sluder]

On Aug 14, 2013, at 2:14 AM, Uli Kusterer  wrote:

> 
> Also keep in mind that in current MacOS X releases, open and save panels are 
> out-of-process windows managed by PowerBox (think sandbox), and NSOpenPanel 
> and NSSavePanel are only proxy objects in your process. Many actions you had 
> on NSWindow are probably stubbed out, and the remaining ones send messages to 
> PowerBox to manipulate the actual window there, or to manage the little 
> transparent, borderless window that holds your accessory view. orderOut: may 
> be one of those.

This is only true for sandboxed apps, but it is a very good point. If Steve's 
app is sandboxed, it needs to forward the- orderOut: message to Powerbox over 
XPC. That would require running the runloop.

--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: Dismissing Open dlog before doc actually opens

[Uli Kusterer]

On Aug 14, 2013, at 7:51, Graham Cox  wrote:
> On 14/08/2013, at 1:38 AM, Steve Mills  wrote:
>>> unning an open panel modally is a user-hostile experience that prevents
>>> the user from interacting with other documents. OS X applications should
>>> not behave this way.
>> 
>> Apple didn't feel that way in the past, so I don't believe it's user-hostile.
> 
> They did, which is why first modeless dialogs (from System 1? 2?) and then 
> sheets (OSX 1.0) were developed. Even as far back as the original Inside 
> Macintosh the use of modal dialogs was strongly discouraged when it was 
> possible to use something else. The original system design used a modal Open 
> dialog but this became a modeless dialog in System 7 (1991), if I recall 
> correctly.

 A modeless dialog* would be a plain old window. :-p I presume you’re thinking 
of semi-modal dialogs, which only block the current application, can be dragged 
around, and were introduced with System 7.0 (so over 20 years ago). Well, the 
window border style for them was introduced then, and ModalDialog() was 
extended to handle them … there were some developers who just used a regular 
window and added an inset line in the body to fake them a little before that. 
OSX only has semi-modal dialogs, real modal dialogs that can’t be dragged and 
block all applications don’t seem to exist anymore in this real multi-tasking 
OS.

> Anyway, history aside, the fact that orderOut: doesn't do anything suggests a 
> problem somewhere - I've seen this happen before when an unhandled exception 
> during the modal loop puts it into a state where the modal session can't be 
> closed and the dialog won't go away.

I vaguely remember having the same issue where an open panel stayed open too 
long. I think it might be related to autorelease pools holding on to the actual 
window-owning object (some private thing, I think). You might want to try 
creating an inner pool and releasing that right when you want the panel to 
close.

Also keep in mind that in current MacOS X releases, open and save panels are 
out-of-process windows managed by PowerBox (think sandbox), and NSOpenPanel and 
NSSavePanel are only proxy objects in your process. Many actions you had on 
NSWindow are probably stubbed out, and the remaining ones send messages to 
PowerBox to manipulate the actual window there, or to manage the little 
transparent, borderless window that holds your accessory view. orderOut: may be 
one of those.

Cheers,
-- Uli Kusterer
“The Witnesses of TeachText are everywhere..."

*) Strictly speaking, in Classic there could have been a modeless dialog: A 
window created from a DLOG resource, then used as a regular window, run using 
DialogSelect(). But they weren’t really a ‘thing’ as a UI element. Usually they 
were just a shorthand for loading controls into a window, or were implemented 
as semi-modal.


___

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: Block gets NULL-ified when animation completes

[Andreas Grosam]

The collection view will very likely have corresponding ivars for the animation 
block and its completion handler. If that's the case, it should (shall) create 
a copy of the anonymous animation (updates) and completion block when receiving 
them in `performBatchUpdate:completion:`. 

Now, `finish` is an "imported field" of the anonymous completion handler. The 
copy operation of the anonymous completion handler will cause the block 
`finish` to be copied as well. Since the outer block lives on the heap, the 
imported fields of `finish` will live there, too. Effectively, imported fields 
will be "copied" into the storage area of the outermost block.

It seems to me, that block `finish` should have a ref count of +1 within the 
anonymous completion handler.


Vlad, could you please verify your observations and possibly create a simple 
test class mimicking the behavior of the collection view (no animation, just a 
dummy async method), e.g.


  dispatch_block_t completion = ^{
  NSLog(@"invoking completion");
  };
  dispatch_block_t updates = ^{
  NSLog(@"invoking updates");
  };

  dispatch_block_t finish = ^{
  NSLog(@"invoking finish");
  if (completion) {
 completion();
  }
  };

if (animated) {
   self.testClass performDummyMethod:^{
  updates();
  } completion:^(BOOL finished) {
  finish();
  }];


When TestClass actually makes copies of the block when setting its ivars 
`_updates` and `_completion`, it should work (IMO).


See also:  "Block Implementation Specification" 
  (especially, "Imported const 
copy of Block reference).


Andreas



On 09.08.2013, at 16:57, Vlad Alekseev  wrote:

> Hey!
> 
> I have a method where I update my collection view's layout parameter and want 
> to have a completion block invoked when animation completes:
> 
> - (void)transitionAnimated:(BOOL)animated 
> completion:(dispatch_block_t)completion
> {
>   dispatch_block_t updates = ^{
>   self.layout.maximumScale = self.maximumScale;
>   };
> 
>   dispatch_block_t finish = ^{
>   if (completion) {
>   completion();
>   }
>   };
> 
>   if (animated) {
>   self.collectionView.userInteractionEnabled = NO;
>   [self.collectionView performBatchUpdates:^{
>   updates();
>   } completion:^(BOOL finished) {
>   self.collectionView.userInteractionEnabled = YES;
>   finish();
>   }];
>   }
>   else {
>   updates();
>   [self.layout invalidateLayout];
>   finish();
>   }
> }
> 
> It works as expected if collection view contains some items. But it crashes 
> if collection view is empty. And it crashes here:
> 
>   } completion:^(BOOL finished) {
>   self.collectionView.userInteractionEnabled = YES;
>   finish();   //  CRASH because finish == NULL
>   }];
> 
> Debugger says that finish is nil:
> 
> (lldb) p finish
> (dispatch_block_t) $1 = 
> 
> What is going on with that block? Any ideas why it gets NULL-ified?
> ___
> 
> 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