Re: Trouble w/ key-value binding validation

[Quincey Morris]

On Nov 6, 2015, at 15:23 , Luc Van Bogaert  wrote:
> 
> In a tableview with a content binding and a value binding on the table cell 
> view textfields to the model's objectValue keypaths, I'm having trouble 
> getting the key-value validation to work correctly. In the model class, I 
> have implemented the required validation methods (validateKey(_ :) throws), 
> for each of the properties, but the validation method only seems to get 
> called for scallar types and not for eg. String types. I've made sure I 
> checked "Validates immediately" in the binding attributes.

a. When you edit the text fields, does the model String property get updated?

b. Can you show us an example function signature line for a scalar validation 
method, and one for a string validation method?

c. Can you show us an example of a model key path you’re using when binding to 
objectValue?

It occurs to me that there might be a bridging issue here. Note that the 
generic validation method (which is what routes the validation to a specific 
validate method) looks like this in the Swift version of 
NSKeyValueCoding.h:

public func validateValue(ioValue: 
AutoreleasingUnsafeMutablePointer, forKey inKey: String) throws

It’s possible that the validate method declaration needs to be something 
like this. (According to this theory, the scalar validation works because the 
object<->scalar conversion happens within KVC, and so it’s staying within the 
Obj-C type world.)

Does the model object inherit from NSObject and/or conform to NSObject protocol?

___

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

Trouble w/ key-value binding validation

[Luc Van Bogaert]

Hi,

In a tableview with a content binding and a value binding on the table cell 
view textfields to the model's objectValue keypaths, I'm having trouble getting 
the key-value validation to work correctly. In the model class, I have 
implemented the required validation methods (validateKey(_ :) throws), for each 
of the properties, but the validation method only seems to get called for 
scallar types and not for eg. String types. I've made sure I checked "Validates 
immediately" in the binding attributes.
Any ideas about what I may be doing wrong?

-- 
Luc Van Bogaert



___

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

Sandbox and app (and its parts)

[Juanjo Conti]

Hi there!

I'm trying to sandbox an app. I've already set the capability and it's
working as expected but I have a problem.

In the same project that the main app is compiled, we also compile a
screensaver (produces a .saver file that the main app installs).

This is how it looks:

http://pasteboard.co/1WDKXMKW.png

I'm allowed to sandbox only the main app. If I click "Saver", there is not
Capabilities pane to click.

How is this usually done?

Thanks!

-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office 20-22 Wenlock Road, London, N1 7GU, United 
Kingdom. Any communication sent by or on behalf of Carousel App Ltd or any 
of its subsidiary, holding or affiliated companies or entities is 
confidential and may be privileged or otherwise protected. If you receive 
it in error please inform us and then delete it from your system. You 
should not copy it or disclose its contents to anyone. Messages sent to and 
from Watu may be monitored to ensure compliance with our internal policies 
and to protect our business. Emails are not secure and cannot be guaranteed 
to be error free. Anyone who communicates with us by email is taken to 
accept these risks.
___

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: Do playgrounds work at all in 7.1?

[Rick Mann]

Ah, syntax error, Xcode doesn't report errors.


> On Nov 6, 2015, at 22:08 , Rick Mann  wrote:
> 
> I'm trying to figure out how to modify a JSON file, and had to check some 
> stuff in a playground. My playground is dirt simple, but seems to do nothing:
> 
> var model = [ "images" : [ ["thumb" : "url1"], ["thumb" : "url2"] ]
> 
> print("\(model)")
> 
> I even tried putting some syntax errors in it; it doesn't even complain about 
> those. I tried automatic and manual execution. I tried quitting and 
> re-launching Xcode.
> 
> 
> -- 
> 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/rmann%40latencyzero.com
> 
> This email sent to rm...@latencyzero.com


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

Modify JSON in Swift

[Rick Mann]

I'm trying to do this, but I can't modify the JSON structure.


---
import Foundation

let s = "{ \"images\" : [ { \"thumb\" : \"url1\", \"width\" : 10 }, { \"thumb\" 
: \"url2\", \"width\" : 20 } ] }"
let data = (s as NSString).dataUsingEncoding(NSUTF8StringEncoding)!

do
{
if var json = try NSJSONSerialization.JSONObjectWithData(data, options: 
.MutableContainers) as? [String:AnyObject]
{
print("JSON: \(json)")
if var images = json["images"] as? [[String:AnyObject]]
{
for var image in images
{
if let thumbURL = image["thumb"]
{
image["thumb"] = "FOOBAR: \(thumbURL)"
print("new: \(image["thumb"])")
}
}

let newData = try 
NSJSONSerialization.dataWithJSONObject(json, options: 
NSJSONWritingOptions(rawValue: 0))
let s2 = NSString(data: newData, encoding: 
NSUTF8StringEncoding)
print(s2)
}
}
}

catch let e as NSError
{
print("Error parsing model.json: \(e)")
}
---
JSON: ["images": (
{
thumb = url1;
width = 10;
},
{
thumb = url2;
width = 20;
}
)]
new: Optional(FOOBAR: url1)
new: Optional(FOOBAR: url2)
Optional({"images":[{"thumb":"url1","width":10},{"thumb":"url2","width":20}]})
---

But it seems the way I drill down into the initial json dictionary gives me 
copies, or otherwise prevents me from modifying the dictionary like this.

Any suggestions on what I can do? I really don't want to have to walk and 
rebuild the JSON myself.

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

Do playgrounds work at all in 7.1?

[Rick Mann]

I'm trying to figure out how to modify a JSON file, and had to check some stuff 
in a playground. My playground is dirt simple, but seems to do nothing:

var model = [ "images" : [ ["thumb" : "url1"], ["thumb" : "url2"] ]

print("\(model)")

I even tried putting some syntax errors in it; it doesn't even complain about 
those. I tried automatic and manual execution. I tried quitting and 
re-launching Xcode.


-- 
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: debugging AutoLayout exception with no build errors

[2551]

> On 6 Nov 2015, at 01:31, Conrad Shultz  wrote:
> You can attach LLDB to a running application (or set it to attach-on-launch) 
> and set breakpoints therein without needing to actually build.


Thanks, that’s something I’ll have to learn how to do down the road… :-)
 
In the meantime, I decided to fire up Xcode in Mavericks and see if the project 
would build in Xcode 6.1. To my surprise it did, and it showed over 30 
AutoLayout errors (4 conflicting constraints, 2 content priority ambiguities 
and a couple of dozen misplaced views, not to mention an unknown system font, 
".HelveticaNeueDeskInterface-Regular”). In Xcode 7.1, no AutoLayout issues are 
shown.

The good news is I’m able to run 10.9 and 10.11 side by side, so I can fix and 
test both simultaneously. I guess I should ask this over on the Xcode list, but 
why on earth doesn’t Xcode 7.1 show any of these warnings? Presumably, the 
10.11 SDK is resolving all this behind the scenes and not even warning the 
developer there’s anything amiss. Fine if the app’s run on 10.11, but with a 
deployment target of 10.9, you’d think Xcode 7.1 would have something to say, 
surely?

Anyways, thanks for the input. At least I can now get to work on fixing the 
problem.


Best


Phil
___

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: Modify JSON in Swift

[Quincey Morris]

On Nov 6, 2015, at 22:54 , Rick Mann  wrote:
> 
> if var images = json["images"] as? [[String:AnyObject]]

No, that won’t work because Swift dictionaries have *value* semantics, so 
you’re *asking* for a copy here. The same thing in Obj-C works because the 
variable ‘images’ would be a reference.

One possible solution would be to change this:

>   if var json = try NSJSONSerialization.JSONObjectWithData(data, options: 
> .MutableContainers) as? [String:AnyObject]

to this:

>   if var json = try NSJSONSerialization.JSONObjectWithData(data, options: 
> .MutableContainers) as? NSMutableDictionary


and stick to the realm of NS collection classes, but it’s pretty ugly.

The other issue you have to be careful of is that casting a NSDictionary to 
(say) ‘[String: AnyObject]’ is probably going to copy the dictionary (to a real 
Dictionary) anyway, because this is a conversion (i.e. copy) cast, not a pure 
bridging cast. The only cast (AFAIK) from an object that’s a NSDictionary to 
Dictionary *without* a conversion is ‘[NSObject: AnyObject]’.

This particular case, of working with Obj-C-derived NSJSONSerialization JSON 
objects in Swift, is actually really really hard. If the structure of the JSON 
object is fixed, it’s probably easier to define a Swift struct for it (or 
rather, a hierarchy of nested structs, dictionaries and arrays), and populate 
it once at the start and reconstruct the serialization dictionary at the end.
___

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: Do playgrounds work at all in 7.1?

[Quincey Morris]

On Nov 6, 2015, at 22:14 , Rick Mann  wrote:
> 
> Ah, syntax error, Xcode doesn't report errors.

Incidentally, when I tried it, I got regular compile errors in the playground. 
However, I have noticed, that sometimes the errors appear in the debug area 
below the playground, and possibly sometimes no errors appear at all (though I 
tend to suspect that they do appear *eventually*, as if it sometimes takes a 
very long time to compile/execute the playground).
___

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

'barHideOnSwipeGestureRecognizer' works with two UIScrollViews but not with two others

[David Hoerl]

I know this is an esoteric question.

I enabled 'hidesBarsOnSwipe' in my MMSpreadSheet view controller. This 
UIView subclass has 4 UICollectionViews in it - two up top and two below.


The top left 'corner' controller does not scroll, and the top right does 
not scroll vertically. Out of the box up/down swipes work perfectly with 
the barHideOnSwipeGestureRecognizer to get the Navigation Bar to hide/show.


But try as I might, I cannot get the bottom two views to provide the 
same functionality, both of which scroll vertically. I tried adding a 
new UIPanGestureRecognizer to the collectionView that returns 'true' 
when sent the delegate message 
'shouldRecognizeSimultaneouslyWithGestureRecognizer'. Interesting that I 
actually get asked if this new recognizer should work with both the 
'barHideOnSwipeGestureRecognizer' and the CollectionView's 
panGestureRecognizer (I return 'true' for both).


I also configured this new recognizer to exactly match the configuration 
of the UICollectionViews panGestureRecognizer.


Just odd that the barHideOnSwipeGestureRecognizer has added itself to 
the collection view, but refuses to handle the swipe.


Any suggestions?

- David
___

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

runOnMainQueueWithoutDeadlocking and all its evils.

[Alex Zavatone]

Bearing in mind my experience dealing with code in the past that was chock full 
of runOnMainQueueWithoutDeadlocking calls, I can not fathom why someone who was 
not updating the UI would need to use this type of approach… everywhere.

Besides complete ineptitude, is there a rational reason that any one of you can 
think of why someone would be using this for GCD dispatches instead of just 
making and using their own GCD dispatch queue?

Before I start destroying the universe and changing this (in a fork), I'd like 
to hear the words of those much smarter than I on this subject.


But seriously, WHY?

Thank you.

- 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: Multiple simultaneous UIAlertControllers

[Alex Zavatone]

On Nov 5, 2015, at 6:58 PM, Carl Hoefs wrote:

> Thanks for the tip, I'll look into it.
> 
> (As a general thought, though, it would appear that UIAlertController
> should be a singleton app-wide, and it should manage its own serialized
> presentation. Any other solution seems like external plumbing to fix a
> design problem.)
> -Carl
> 
>> Pretty sure the WWDC 2015 video on NSOperations tackles a similar scenario
>> in a quite elegant way. That might be worth investigating.
>> 
>> Peter
>> 
>>> On Nov 5, 2015, at 6:42 PM, Carl Hoefs 
>>> wrote:
>>> 
>>> A queue of what? I would think that if only a single alert view can be
>>> presented at a time, then iOS would serialize them and present them when
>>> earlier ones complete. Is there no system-level solution to this?
>>> -Carl

Your own queue.  A queue of data you want to be displayed within alerts.  Cook 
up an alert manager that can handle more than one alert.  You could even make 
one that is paged to go from alert to alert and display the # of the alert is 
within the total # of alerts.  Change OK to OK and Next.

Honestly, I've got no idea if there is a system level one or not, but I'm on my 
second project in the same year where we needed something like this.

It seems to be a reoccurring need.


___

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: 'barHideOnSwipeGestureRecognizer' works with two UIScrollViews but not with two others

[David Duncan]

> On Nov 6, 2015, at 8:04 AM, David Hoerl  wrote:
> 
> I know this is an esoteric question.
> 
> I enabled 'hidesBarsOnSwipe' in my MMSpreadSheet view controller. This UIView 
> subclass has 4 UICollectionViews in it - two up top and two below.
> 
> The top left 'corner' controller does not scroll, and the top right does not 
> scroll vertically. Out of the box up/down swipes work perfectly with the 
> barHideOnSwipeGestureRecognizer to get the Navigation Bar to hide/show.
> 
> But try as I might, I cannot get the bottom two views to provide the same 
> functionality, both of which scroll vertically. I tried adding a new 
> UIPanGestureRecognizer to the collectionView that returns 'true' when sent 
> the delegate message 'shouldRecognizeSimultaneouslyWithGestureRecognizer'. 
> Interesting that I actually get asked if this new recognizer should work with 
> both the 'barHideOnSwipeGestureRecognizer' and the CollectionView's 
> panGestureRecognizer (I return 'true' for both).
> 
> I also configured this new recognizer to exactly match the configuration of 
> the UICollectionViews panGestureRecognizer.
> 
> Just odd that the barHideOnSwipeGestureRecognizer has added itself to the 
> collection view, but refuses to handle the swipe.

The scroll (collection) view needs to abut or underlap the navigation bar for 
the gesture to recognize, which is why your bottom collection views don’t work. 
There isn’t a way to override this behavior, so I don’t really have any good 
answers for how you might obtain it.

> 
> Any suggestions?
> 
> - David
> ___
> 
> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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

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

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

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

Re: runOnMainQueueWithoutDeadlocking and all its evils.

[David Duncan]

> On Nov 6, 2015, at 8:36 AM, Alex Zavatone  wrote:
> 
> Bearing in mind my experience dealing with code in the past that was chock 
> full of runOnMainQueueWithoutDeadlocking calls, I can not fathom why someone 
> who was not updating the UI would need to use this type of approach… 
> everywhere.
> 
> Besides complete ineptitude, is there a rational reason that any one of you 
> can think of why someone would be using this for GCD dispatches instead of 
> just making and using their own GCD dispatch queue?
> 
> Before I start destroying the universe and changing this (in a fork), I'd 
> like to hear the words of those much smarter than I on this subject.
> 
> 
> But seriously, WHY?

Roughly this approach reads like a lock that uses the main queue as its locking 
point. Without understanding what is being protected, it is hard to tell why 
this is being done.

The usage of dispatch_sync() says that whomever wrote this expected to have the 
results available immediately. If not, then simply switching to 
dispatch_async() may be sufficient in many cases. Beyond that you will probably 
need to evaluate what work is being done in these cases.

> 
> Thank you.
> 
> - 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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

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

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

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

Re: -clickedRow

[Raglan T. Tiger]

> On Nov 5, 2015, at 1:51 PM, Jens Alfke  wrote:
> 
> Convert the position to local coords, then call -rowAtPoint:.


I woke up last night and thought exactly that which I have used before ... must 
be dementia on the rise !

-rags
___

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: NSView - trouble setting next responder on 10.10 - works okay on 10.9

[Jonathan Mitchell]

This thread is a bit long in the tooth but I thought I would conclude it.
My final solution to this was not to try and split a separate NSResponder class 
off from my NSViewController.
I could have been gone down this route but the sheer amount of donkey work put 
me off.
The app was designed to work with NSViewController instances between the 
NSWindow and the NSWindowController in the chain - period.
The 10.10 API changes simply invalidated my design.
You could argue that the NSViewController should not have been inserted into 
the chain as I had done but there was nothing that I know of that would have 
mandated against this design.

Anyhow, my fix was to give my controllers an additional NSViewController proxy 
property.
The proxy does not load the controller’s nib, it merely references the parent 
controller’s view and participates in the auto responder chain building.
The parent controller can then be inserted higher up in the responder chain as 
before.

https://github.com/mugginsoft/XSViewController/commit/29b406a4e1882edea2203eaff3c44f1c6a2f4cbd


> On 4 Oct 2015, at 11:02, Jonathan Mitchell  wrote:
> 
> 
>> On 3 Oct 2015, at 18:43, Quincey Morris 
>>  wrote:
>> 
>> 
>> I suggest you consider breaking your view controllers apart into two 
>> objects. One, a “view responder” would be a NSResponder subclass that you 
>> insert into the responder chain just below the window controller. The other, 
>> an actual NSViewController subclass, would be inserted into the responder 
>> chain wherever the frameworks want, or possibly not at all pre-10.10.
> That’s a good idea!
> 
>> 
>> Ideally, all of the business logic would be moved from its current home in 
>> the view controller to the view responder, including the action messages. 
>> All that’d be left in the view controller would be the outlets (if any), and 
>> the viewDidLoad logic necessary to prepare the view itself (and also to 
>> create the view responder, and insert it in the responder chain). 
>> Alternatively, you could keep all the local-to-view logic in the view 
>> controller, and put only the trans-view logic in the view responder, but 
>> this may get a bit messy if both share the same custom data structures.
> 
> The business logic is all in a separate framework.
> The view controllers simply hookup the UI bindings by calling into the BL.
> So I might go along the lines of of an additional lightweight NSResponder 
> that acts an action receiver that routes actions back to proxies in the view 
> controller.
> 
> Or, it might be simpler to just accept the 10.10 design changes and refactor 
> accordingly.
> In the long term this might be best in terms of reducing overall complexity.
> 
> Thanks a bunch for you input. It helped a lot.
> 
> J


___

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: Multiple simultaneous UIAlertControllers

[Carl Hoefs]

On Nov 5, 2015, at 3:53 PM, Eric E Dolecki  wrote:
> 
> That's the way. You should never need more than one presented at a time. 
> 
> 
>> On Nov 5, 2015, at 5:44 PM, Tomasz Muszyński  wrote:
>> 
>> You should present next UIAlertController when first one has been dismissed 
>> (when UIAlertAction handler is called).

Now that I have an NSOperationQueue handling the serialized presentation of the 
UIAlertControllers, I'm getting this warning:

Warning: Attempt to present  on 
 whose view is not in the window hierarchy!

So far as I understand it, the view *is* in the window hierarchy, modally. What 
to do?
-Carl


___

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

[corbin dunn]

> On Nov 5, 2015, at 12:51 PM, Jens Alfke  wrote:
> 
> 
>> On Nov 5, 2015, at 12:35 PM, Raglan T. Tiger  wrote:
>> 
>> In -rightMouseDown I call [self clickedRow] which always returns -1 in a row 
>> or not in row
> 
> Yeah, you’re getting control before the base class has had a chance to set 
> the clickedRow property. (Have you tried calling the superclass method first? 
> That might help.)

Plus, NSTableView only sets it on mouseDown:. (well, it does it at a few other 
key points, but not rightMouseDown)

corbin

> 
>> What should I be doing to get the clicked row?
> 
> Convert the position to local coords, then call -rowAtPoint:.
> 
> —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/corbind%40apple.com
> 
> This email sent to corb...@apple.com


___

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

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

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

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

Re: -clickedRow

[Charles Srstka]

> On Nov 5, 2015, at 2:35 PM, Raglan T. Tiger  wrote:
> 
> I subclass NSTableView to catch -rightMouseDown 
> 
> In -rightMouseDown I call [self clickedRow] which always returns -1 in a row 
> or not in row
> 
> What should I be doing to get the clicked row?


If the reason you’re capturing right-click events is to put up a context menu, 
it’s much simpler just to connect the outline view’s -menu outlet in Interface 
Builder, which in addition to setting -clickedRow, will also automatically 
highlight the clicked row in the UI, making for a nicer user experience. If you 
need to customize the menu based on events at runtime, you can override 
menuForEvent: and return your custom menu based on the event. Unfortunately, 
when you do it this way you get neither -clickedRow nor the UI selection. It’s 
still probably more correct than overriding rightMouseDown:, though.

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: Multiple simultaneous UIAlertControllers

[Tomasz Muszyński]

> Wiadomość napisana przez Carl Hoefs  w dniu 
> 06.11.2015, o godz. 22:45:
> 
> 
>> On Nov 6, 2015, at 2:43 PM, Tomasz Muszyński  wrote:
>> 
>>> 
>>> Wiadomość napisana przez Carl Hoefs  w dniu 
>>> 06.11.2015, o godz. 22:39:
>>> 
 On Nov 6, 2015, at 2:38 PM, Tomasz Muszyński  wrote:
 
> 
> Wiadomość napisana przez Carl Hoefs  w 
> dniu 06.11.2015, o godz. 22:33:
> 
> On Nov 5, 2015, at 3:53 PM, Eric E Dolecki  wrote:
>> 
>> That's the way. You should never need more than one presented at a time. 
>> 
>> 
>>> On Nov 5, 2015, at 5:44 PM, Tomasz Muszyński  wrote:
>>> 
>>> You should present next UIAlertController when first one has been 
>>> dismissed (when UIAlertAction handler is called).
> 
> Now that I have an NSOperationQueue handling the serialized presentation 
> of the UIAlertControllers, I'm getting this warning:
> 
> Warning: Attempt to present  on 
>  whose view is not in the window 
> hierarchy!
> 
> So far as I understand it, the view *is* in the window hierarchy, 
> modally. What to do?
 
 You try to present your alert on RootViewController instead of other view 
 controller which is on top (currently visible). On your first post you 
 wrote about MyViewController.
 
 tm
>>> 
>>> I have background threads running that generate alerts. On which 
>>> ViewController do I execute the alerts?
>> 
>> I already wrote - on top view controller. But I think you have probably 
>> wrong app architecture. Background threads should not present alerts, but 
>> they should store somewhere their messages and present them (maybe as one 
>> big alert) when background thread is finished. I’m just guessing…
>> 
>> tm
> 
> The background threads don't execute the alerts, but they enqueue them onto 
> the NSOperationQueue, where they are executed on the top (root) view 
> controller. But I get this warning, and the alerta are never displayed.

You are queuing them on background thread and queue probably executes them 
immediately. I’m not sure what you are trying to achieve and why background 
thread creates many alerts. This will be annoying for the user. You should only 
store (error?) messages and present them when background thread is finished. If 
you have to present all that messages maybe UIAlertController is wrong solution 
for that and just use UITableView with list of messages. Also, your background 
thread probably doesn’t know which view controller is currently present on top, 
that’s why you should not create UIAlertController’s on background thread. If 
background thread generates messages, then it should notify somehow (eg 
notification center) currently visible view controller to present an alert.

tm
___

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: Multiple simultaneous UIAlertControllers

[Graham Cox]

> On 6 Nov 2015, at 10:58 AM, Carl Hoefs  wrote:
> 
> (As a general thought, though, it would appear that UIAlertController
> should be a singleton app-wide, and it should manage its own serialized
> presentation. Any other solution seems like external plumbing to fix a
> design problem.)



It is a design problem - yours :)

From a usability point of view, having a bunch of endless alerts one after 
another must surely be one of the quickest ways to make your users hate your 
app and you in turn. If you have a bunch of threads that can asynchronously 
produce errors, why not simply queue the errors, or info about them, silently, 
then when the work as a whole completes, present one alert (on the main thread) 
that says that some of the work could not be completed, and gives the user the 
option to go into more detail, where you would use the queued error information 
to populate a list of errors and what the user can do about them. If the user 
can’t do anything about them, then there’s probably no point going into even 
that much detail.

—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