Enabling UISearchBar cancel button?

2017-01-11 Thread Rick Mann 
I'm creating and displaying a UISearchBar without using UISearchController (it 
gets in the way).

My UISearchBar is installed in the storyboard via IB. I animate it into 
position in my UI when the user taps a button. However, the Cancel button is 
disabled. I pre-load the search bar with the text of the last search, so the 
button should be enabled.

Before, when I was using UISearchController, it was enabled. Now it's not, 
until the user taps on it!

Any idea how to enable it? Thanks!

-- 
Rick Mann
rm...@latencyzero.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: Refreshing Cocoa Bindings

2017-01-11 Thread Ken Thomases 
On Jan 11, 2017, at 3:16 PM, Daryle Walker  wrote:
> 
> I'm going to store a reference to a model in a NSViewController's 
> representedObject field. The various contained views will reference that 
> field through KVO (Is that possible?) for their bound values.

Yes, that's possible.  The issue is how that binding is established and by what 
code/mechanism.  It will need a reference to the specific view controller.

> If I change the value of the represented object (what it points to, not any 
> attributes within), will the views automatically track to the new object?

So long as any change along the key path is made in a KVO-compliant manner, KVO 
will track it.  Changing a property by calling its setter method is 
KVO-compliant.  You have little choice but to use the setter method to change 
NSViewController's representedObject (unless you completely override that 
property), so changing it is KVO-compliant.

> Or do I have to use a explicit method to let them know (i.e. clear their 
> caches)?

No.

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: Refreshing Cocoa Bindings

2017-01-11 Thread Quincey Morris 
On Jan 11, 2017, at 13:16 , Daryle Walker  wrote:
> 
> I'm going to store a reference to a model in a NSViewController's 
> representedObject field. The various contained views will reference that 
> field through KVO (Is that possible?) for their bound values. If I change the 
> value of the represented object (what it points to, not any attributes 
> within), will the views automatically track to the new object? Or do I have 
> to use a explicit method to let them know (i.e. clear their caches)?

The “representedObject” property is explicitly documented as KVO compliant, so 
you can observe and and bind through it.

___

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

Refreshing Cocoa Bindings

2017-01-11 Thread Daryle Walker 
I'm going to store a reference to a model in a NSViewController's 
representedObject field. The various contained views will reference that field 
through KVO (Is that possible?) for their bound values. If I change the value 
of the represented object (what it points to, not any attributes within), will 
the views automatically track to the new object? Or do I have to use a explicit 
method to let them know (i.e. clear their caches)?

Sent from my iPhone
___

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: On NSIncrementalStore UUID Uniqueness

2017-01-11 Thread Keary Suska 

> On Jan 11, 2017, at 11:16 AM, Jens Alfke  wrote:
> 
> 
>> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
>> 
>> UUID means Universally unique identifier and it must be unique: 
>> https://en.wikipedia.org/wiki/UUID 
>> > >
>> To generate an UUID, use a standard system function (CFUUID, NSUUID, 
>> libuuid, …)
> 
> This is not what I believe Daryle was asking, and it’s sent everyone off on a 
> tangent about what UUIDs are.
> 
> My interpretation of the original question: Is an NSIncrementalStore’s UUID 
> scoped to the specific database, or is it scoped to that _implementation_ of 
> the store? That is, is the UUID generated at runtime or at compile time?
> 
> I don’t know the answer; just hoping to get the discussion back on track :)

The docs say:
"A unique identifier for the store at the given URL. It must be 
uniquely and reproducibly derivable, such that multiple instances of your store 
return the same UUID”

My reading is that the store UUID would be unique to a specific database since 
it is only unique to the URL location of the store. I thin the docs use 
“instance” in a strictly OOP sense.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: On NSIncrementalStore UUID Uniqueness

2017-01-11 Thread Jens Alfke 

> On Jan 10, 2017, at 2:00 PM, Jean-Daniel  wrote:
> 
> UUID means Universally unique identifier and it must be unique: 
> https://en.wikipedia.org/wiki/UUID 
>  >
> To generate an UUID, use a standard system function (CFUUID, NSUUID, libuuid, 
> …)

This is not what I believe Daryle was asking, and it’s sent everyone off on a 
tangent about what UUIDs are.

My interpretation of the original question: Is an NSIncrementalStore’s UUID 
scoped to the specific database, or is it scoped to that _implementation_ of 
the store? That is, is the UUID generated at runtime or at compile time?

I don’t know the answer; just hoping to get the discussion back on track :)

—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: On NSIncrementalStore UUID Uniqueness

2017-01-11 Thread Alastair Houghton 
On 11 Jan 2017, at 00:16, Saagar Jha  wrote:
> 
> Small quibble: UUIDs are not guaranteed to be unique. It's just extremely 
> likely they will be, and they be sufficient for almost all applications, 
> including this one.

If we’re going to be pedantic, properly issued version 1 and 2 UUIDs *are* 
guaranteed to be unique - but that means (a) you have a properly issued MAC 
address that hasn’t been spoofed, and (b) you aren’t generating more than the 
rate limit for the UUID version (this should be prevented by the generating 
code; sometimes the generator has a lower rate limit because of the low 
precision of the system clock).  The downside is that version 1 and 2 UUIDs 
have privacy implications - they leak the MAC address of your device.  For some 
applications, though, this is not a problem and you may want to use a version 1 
UUID in that case.

Versions 3 and 5 are subject to hash collisions (MD5 and SHA-1 respectively), 
and version 4 (the one you should probably use as a sensible default) is random 
and so subject to statistical collisions.  It isn’t recommended to use version 
4 unless you have a source of high quality randomness available, to avoid 
collisions caused by poor quality random number generation (this won’t be a 
problem if you’re using the system APIs to generate them on Mac OS X or iOS).

Version 5 UUIDs can be useful if the thing you want to identify has e.g. a URL 
or FQDN or similar, as you can directly construct them from that, which might 
let you avoid e.g. another database lookup in some cases.  I would avoid 
version 3 (besides MD5 being weak to begin with, it’s also vulnerable to a 
length-extension attack; SHA-1 normally would be too, but in a version 5 UUID 
it isn’t because too many bits of the SHA-1 hash are missing... you’d need to 
try 275 billion different alternatives).

Also worth noting that different versions cannot collide with one another - 
there are version bits in the UUID.

TL;DR: Version 1 and 2 UUIDs should be unique.  Versions 3 through 5 can in 
most cases be assumed to be unique.

Kind regards,

Alastair.

--
http://alastairs-place.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