Re: NSSplitView layout problem

[Andy Lee via Cocoa-dev]

[catching up on email]

On Thu, Sep 8, 2022, at 5:34 PM, James Walker via Cocoa-dev wrote:
> I could insert the edit 
> field in a custom NSView and insert that in the split view, but I'm 
> wondering if there is a better way to handle the issue?

This is how I would do it.  Seems like a fine solution to me.

--Andy
___

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: Launching in fullscreen gives "Funk" sound sometimes

[Andy Lee via Cocoa-dev]

On Jun 24, 2020, at 5:23 AM, Gabriel Zachmann via Cocoa-dev 
 wrote:
> I tried to add this in -viewDidLoad in MasterWindowController:
> 
>[[[self view] window] makeKeyAndOrderFront: NULL];

Some questions that may or may not help:

- Are you sure the above line of code is being called?  (I would check with a 
NSLog rather than a breakpoint.  Using a breakpoint can cause the active 
application to change, which you may not want.  You want to see what's 
happening when your app launches without *affecting* what's happening.)
- Did you mean -windowDidLoad rather than -viewDidLoad?
- What is the application *supposed* to do when you type keystrokes?
- I saw the thread earlier where you moved some logic into 
applicationWillFinishLaunching:.  What if you add back 
applicationDidFinishLaunching: and move just the full-screen toggling code 
there (and keep the rest in applicationWillFinishLaunching:)?
- Are you sure your application is the active application when you're typing 
those keystrokes?  You can check this by adding applicationDidBecomeActive: and 
applicationDidResignActive: methods to the application delegate, and having 
them call NSLog.  I'm not sure offhand if makeKeyAndOrderFront: makes the 
application active.
- Does your window have an initialFirstResponder?  Not sure this would make a 
difference in your case, but might in some circumstances. The 
initialFirstResponder can be set in Interface Builder.

--Andy

___

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: NSTabViewItem and NSViewController

[Andy Lee]

On Apr 4, 2019, at 9:43 AM, Casey McDermott  wrote:
> 
> We have a tab view with tabs added from code.  Each tab uses a NSTabViewItem 
> subclass,
> which contains a reference to a NSViewController subclass within it to manage 
> tab contents. 
> Users click to add and remove tabs.

I see that NSTabViewItem has a strong viewController property.  Are you using 
that, or does your NSTabViewItem subclass add its own separate reference to the 
view controller?

--Andy

___

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: Trouble assigning datasource and delegate to an instance of NSTableView

[Andy Lee]

The compiler may accept it, but it doesn't interpret it the way you think.  You 
can confirm by checking whether your class formally conforms to the protocols.  
Try this with your old code and your new code, and compare:

NSLog(@"conforms to protocol? %d", [ImportTool 
conformsToProtocol:@protocol(NSTableViewDataSource)]);

I think Quincey is right, what you really did is declare a generic type.  It's 
a subtle mistake.  Notice that this also compiles:

@interface  ImportTool  : NSObject
@end

--Andy

On Mar 28, 2019, at 7:44 PM, Peter Hudson  wrote:
> 
> Very strange - the compiler is quite happy with my waywardness. 
> Peter
> 
>> On 28 Mar 2019, at 23:39, Quincey Morris 
>>  wrote:
>> 
>>> On Mar 28, 2019, at 15:58 , Peter Hudson  wrote:
>>> 
>>> @interface  ImportTool >> NSEncoding> : NSObject
>> 
>> You’re Doing It Wrong™. You mean:
>> 
>>> @interface  ImportTool : NSObject >> NSTableViewDelegate, NSEncoding>
>> 
>> 
>> I don’t know what it means the way you wrote it. Something about lightweight 
>> generic syntax, perhaps?
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com
> 
> This email sent to ag...@mac.com

___

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

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

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

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

Re: NSAlert

[Andy Lee]

I don't know where or whether it's documented, but it's not new.
Using Space for "clicking" whichever control has focus has been around
for a while.  I don't remember offhand -- it may depend on the setting
in System Preferences that governs whether all controls can get
keyboard focus.
--Andy


On Sat, Sep 8, 2018, at 6:53 PM, Richard Charles wrote:
> I have a simple NSAlert presented as an attached sheet with a single
> default OK button.
>
> When the spacebar is pressed the alert is dismissed.
>
> It this a new thing?
>
> Is this documented anywhere?
>
> --Richard 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/aglee%40mac.com
>
> This email sent to ag...@mac.com

___

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

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

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

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

Re: Delayed perform never performing

[Andy Lee]

On Aug 24, 2018, at 2:21 PM, James Walker  wrote:
> What could cause a delayed perform (using -[NSObject performSelector: 
> withObject: afterDelay:]) to never happen?

I'm sure you've checked, but *just in case*, I'll ask: are you sure you're not 
sending it to nil?

> I wondered if I needed to do the delayed perform in a particular run loop 
> mode, and found that [[NSRunLoop currentRunLoop] currentMode] is nil, which 
> seems odd.  Why would the run loop not be running?

Where are you checking currentMode?  I did a quick test and noticed currentMode 
is nil in my app delegate's applicationDidFinishLaunching: method (I guess 
because the run loop hasn't started yet?), but it's non-nil a little later when 
my delayed perform is called.

My delayed perform "works for me", so I'm afraid I don't have much to suggest 
regarding that.

- (void)fire:(id)arg {
NSLog(@"FIRED -- current run loop mode: %@",
  [[NSRunLoop currentRunLoop] currentMode]);
NSLog(@"%@", @"You're fired!");
}

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSLog(@"Did launch -- current run loop mode: %@",
  [[NSRunLoop currentRunLoop] currentMode]);
[self performSelector:@selector(fire:)
   withObject:nil
   afterDelay:0.175];
}

Output:

2018-08-24 17:34:18.852033-0400 Scratchy[94529:13604294] Did launch -- current 
run loop mode: (null)
2018-08-24 17:34:19.035517-0400 Scratchy[94529:13604294] FIRED -- current run 
loop mode: kCFRunLoopDefaultMode
2018-08-24 17:34:19.038105-0400 Scratchy[94529:13604294] You're fired!

--Andy

___

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: strange behaviour of hasPrefix

[Andy Lee]

On May 3, 2017, at 11:25 AM, Gerriet M. Denkmann  wrote:
> Why has test2 no prefix?

Seems like a subtle difference between the implementations of 
__NSCFConstantString/__NSCFString and NSPathStore2/NSString.

I ran your code and got the same results.  I also added a bunch of sanity 
checks and they all returned 1 (YES) as expected.

NSLog(@"does test1 equal pintu? %d", [test1 isEqualToString:pintu]);
NSLog(@"does test1 equal test2? %d", [test1 isEqualToString:test2]);
NSLog(@"does test2 equal pintu? %d", [test2 isEqualToString:pintu]);
NSLog(@"does test2 have test1 as prefix? %d", [test2 hasPrefix:test1]);
NSLog(@"does test2 have pintu as prefix? %d", [test2 hasPrefix:pintu]);
NSLog(@"does test1 have test1 as prefix? %d", [test1 hasPrefix:test1]);
NSLog(@"does test2 have test1 all as prefix? %d", [test2 
hasPrefix:[test1 substringToIndex:[test1 length]]]);
NSLog(@"do test1 and test2 have the same first character? %d", ([test1 
characterAtIndex:0] == [test2 characterAtIndex:0]));
NSLog(@"do test1 and test2 have the same second character? %d", ([test1 
characterAtIndex:1] == [test2 characterAtIndex:1]));

It seems to me if two NSStrings are the same according to isEqualToString:, 
then we should expect them to return the same YES/NO answer for any given 
hasPrefix: test, regardless of which classes from the NSString class cluster 
they happen to be.  But maybe that's not true, for some subtle encoding reason 
I don't understand.

--Andy

___

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: My god, it is so pleasant with the animations disabled on Sierra.

[Andy Lee]

On Oct 27, 2016, at 4:56 PM, Rich Siegel  wrote:
> System Preferences => Accessibility => Display => "Reduce Motion"

On Oct 27, 2016, at 6:29 PM, Alex Zavatone  wrote:
> Sierra, System Preferneces > Accessibility (because not wanting excess 
> animation is a disability, not a general preference or appearance option).  
> Then click on Display and look at the check box in the top right that says 
> Reduce Motion.

Ah -- thanks, Rich and Alex.  Very nice indeed.

--Andy



___

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: Window Opened Notification?

[Andy Lee]

Dave, can you clarify whether you want is:

1. a notification when the frontmost window changes, or
2. a notification when some application opens a new window?

If #1, observing these NSWorkspace properties looks like the way  to go.  If 
#2, bear in mind that applications can open windows that don't become the 
active window.  For example, it is possible to open links in emails, tweets, 
etc., that cause the browser to open a new window in the background.  The link 
might not open a new window at all, but rather a new tab in an existing browser 
window.

I'm guessing you want #1, which is fortunately the easy (or easier) case. :)  
Just checking.

--Andy

On Sep 5, 2016, at 7:58 PM, dangerwillrobinsondan...@gmail.com wrote:
> 
> The two key properties in NSWorkspace
> ARE
> KVO observable. 
> Reading the docs was easy ;)
> frontmostApplication
> And
> menuBarOwningApplication
> 
> Sent from my iPhone
> 
>> On Sep 6, 2016, at 8:36 AM, Alex Zavatone  wrote:
>> 
>> There are examples online for making NSArray observable if these are array 
>> structures. 
>> 
>> If you try this path, try it with a simple case where you make an NSArray 
>> and then change it.
>> 
>> Sent from my iPhone
>> 
>>> On Sep 5, 2016, at 4:25 PM, dangerwillrobinsondan...@gmail.com wrote:
>>> 
>>> Not sure if it's KVO observable but NSWorkspace might be worth looking into 
>>> as well as NSRunningApplication
>>> 
>>> Sent from my iPhone
>>> 
>>> On Sep 6, 2016, at 3:55 AM, Dave  wrote:
>>> 
> Would it be possible to observe which window becomes the front window and 
> then send a notification?
 
 That’s what I am trying to find out……
 
 Cheers
 Dave
 
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/dangerwillrobinsondanger%40gmail.com
 
 This email sent to dangerwillrobinsondan...@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/zav%40mac.com
>>> 
>>> This email sent to z...@mac.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com
> 
> This email sent to ag...@mac.com


___

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

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

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

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

Re: Does setFormatter() retain?

[Andy Lee]

On Aug 24, 2016, at 4:25 PM, Jens Alfke  wrote:
> 
>> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn  
>> wrote:
>> 
>> Now, will "setFormatter" call retain on "formatter" or not? Looking
>> at "retainCount" seems to suggest so, although I know that this
>> isn't reliable and shouldn't be done at all...
> 
> These days, with ARC, we call those “strong references” vs. “weak” or 
> “unretained” references.

It used to be that when someone mentioned looking at retainCount there would a 
flurry of admonitions not to do that.  This thread doesn't feel complete 
without such an admonition, so I'll refer you to this.

:)


> Do not use this method.

> Strong (retained) references are the default for properties. There are a few 
> cases in system frameworks where a property is weak or unretained — usually 
> this is used for delegates or data sources, to avoid reference cycles that 
> can lead to memory leaks. In this case the docs should call out the style of 
> the reference. If there’s no mention of it, you can assume it’s strong.

Yup.  That said, there's at least four ways to find out how a property is 
declared -- bearing in mind what others have said about how you should focus on 
what *you* do with the formatter object, not so much what the NSTextField 
object does.

1. The docs show the Objective-C declarations of properties and methods.  What 
might happen is:

- You'd look at the docs for NSTextField.
- You wouldn't see the formatter property in those docs.
- You'd check the docs for its superclass, NSControl.
- You'd see this:

@property(strong) __kindof NSFormatter *formatter

2. Alternatively, you might be looking at this line of code...

   [textField setFormatter:formatter];

...and you might Option-click on the "setFormatter" and see popup help showing 
the same Objective-C declaration.

3. You might do a *plain* click on "setFormatter" and hit Option-Command-2 to 
show the Quick Help inspector, which again shows the same declaration.  I'm a 
big fan of Quick Help.

4. If you don't trust the docs and only trust code, you might Command-click on 
"setFormatter", which will open NSControl.h and select the declaration of the 
property.  On the machine I'm using now, I get the following, which I see has 
the additional "nullable" keyword:

@property (nullable, strong) __kindof NSFormatter *formatter;

--Andy (a few days behind on my email)


___

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: Core Data or not

[Andy Lee]

On Aug 6, 2016, at 12:13 PM, Trygve Inda  wrote:
> 
>> On Aug 6, 2016, at 1:46 AM, Trygve Inda  wrote:
>>> For example, I would need to add items with ID# 204, 765, 983, 124, and 458
>>> to the array. This seems like with Core Data it would be 5 different
>>> fetches. Or is there some efficient way to fetch these 5 items in one
>>> request?
>> 
>> You could add an entity to your data model that represents the custom
>> collection.  It would have an attribute that is a one-to-many relationship to
>> InterestingObject.  If you only have one of those manually-constructed 
>> tables,
>> your data store would only contain one instance of this entity.  That's
>> perfectly okay.
>> 
>> --Andy
>> 
>> 
> 
> I can't do that at run time though. I need the user to be able to build
> custom collections (like a custom iTunes playlist) that is a subset of the
> full collection but not by any simple predicate criteria.

You can certainly do it at runtime.  Core Data allows your program to 
manipulate object graphs and save the changes.  It would be very weak indeed if 
it could not model arbitrary collections of objects that the user can modify 
and save.

To clarify my suggestion:

Presumably your data model will have an InterestingObject entity, and you'll 
specify the InterestingObject class as the class for that entity.  ("Entity" 
and "class" are related but separate concepts in Core Data.)

You seem to be envisioning that your data model ONLY has that one entity.

I am suggesting you add another entity, something like CustomAlbum, with 
presumably a corresponding class also named CustomAlbum.  The CustomAlbum 
entity would have a one-to-many relationship to the InterestingObject entity, 
called something like interestingObjects.  You can put any InterestingObjects 
you want into an album's interestingObjects collection, whether 
programmatically or in response to user input, and of course you can save 
changes to the album.

I second the suggestions others have made to create a "play" project using Core 
Data, either from scratch or as an experimental, purely educational fork of 
your existing project.  You will learn much more efficiently what you can and 
cannot do, and you will get a better sense of whether you want to change how 
your app manages its data.

I would echo Graham Cox's question about what your motivation is.  If your 
goals do not include getting generally familiar with Core Data -- I mean, if 
you don't have an urgent reason to learn Core Data except for this project -- 
then maybe you don't have a strong reason to convert the app.  5000 objects 
doesn't sound like much (depends on the objects, of course), and it sounds like 
you are already comfortable loading them all into memory.  So maybe, as Graham 
says, "IIABDFI".

But maybe you anticipate your app's needs will scale far beyond 5000?  Or maybe 
you want some of Core Data's other features beyond straightforward object 
persistence?  Or maybe you anticipate your object model will grow more complex, 
and you want to use the Core Data model editor to help visualize that?  Or 
maybe you're thinking a Core Data approach will reduce the learning curve for 
new developers, who could use their existing knowledge of Core Data instead of 
having to learn your current persistence mechanism?  You haven't said, so we 
can only guess.

--Andy


___

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: Core Data or not

[Andy Lee]

(Apologies to those getting this twice -- I sent from the wrong account the 
first time.)

On Aug 6, 2016, at 1:46 AM, Trygve Inda  wrote:
> For example, I would need to add items with ID# 204, 765, 983, 124, and 458
> to the array. This seems like with Core Data it would be 5 different
> fetches. Or is there some efficient way to fetch these 5 items in one
> request?

You could add an entity to your data model that represents the custom 
collection.  It would have an attribute that is a one-to-many relationship to 
InterestingObject.  If you only have one of those manually-constructed tables, 
your data store would only contain one instance of this entity.  That's 
perfectly okay.

--Andy


___

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: NSTask argument list

[Andy Lee]

Don't glom the arguments together.  Pass each as a separate array
element: "-i", the URL string, "-c", "copy", the output string.
 
And you don't need to quote the arguments, just pass them as is.
 
I hope that makes sense -- I'd make it more code-like if I were at my
desk rather than on my phone.
 
--Andy
 
 
On Sat, Jun 25, 2016, at 11:37 PM, Graham Cox wrote:
> HI all,
>
> I am using NSTask to wrap ffmpeg, the video conversion utility.
>
> I am able to invoke ffmpeg alright, but it’s unclear how the argument
> list should be passed through NSTask. I tried making my various
> arguments into one big string, but ffmeg doesn’t parse it, instead
> writing an error.
>
> Here’s my code:
>
>   NSString* execPath = [[[self class] ffMPEGURL] path];
>
>   NSString* argString = [NSString stringWithFormat:@"-i \"%@\" -c
>   copy %@", [url absoluteString], [self.outputFileURL
>   absoluteString]];
>
>   self.ffMPEGTask = [NSTask launchedTaskWithLaunchPath:execPath
>   arguments:@[argString]];
>
>
> What the argument string should look like is:
>
> -i  -c copy 
>
>
> ffmpeg responds:
>
> Unrecognized option 'i "http://" -c copy
> file:///'.
> Error splitting the argument list: Option not found
>
>
> Obviously I need to pass the arguments differently, but it’s not clear
> what I need to do.
>
> —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/aglee%40mac.com
>
> This email sent to ag...@mac.com
 
___

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

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

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

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

Re: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Andy Lee]

Whoops, meant for this to go to the list:

On Jun 24, 2016, at 6:22 PM, Martin Wierschin  wrote:
> 
>>> It almost looks like the ability to pre-select a file was deliberately 
>>> removed from the NSOpenPanel API.
> 
> 
> Whatever the reason for removing this feature from NSOpenPanel, it’s a 
> nuisance for users. There are many good reasons for wanting to pre-select a 
> particular file when presenting an open dialog to the user. Without this 
> feature the user has to scroll though a potentially large file list looking 
> for the right entry, one whose name may not be familiar to the user.
> 
> If this change was made in the interest of security and sandboxing, how about 
> just exposing an API that allows an app to select a file for which the app 
> already has security-scoped bookmark data? That doesn’t cover all the use 
> cases, but it would at least improve the user experience when the user needs 
> to validate or change an existing preference.

Indeed, the reason I want to pre-select is to highlight an existing preference.

Earlier I was trying to remember the last time I saw an app pre-select a file.  
Your mention of the user preference use case jogged my memory.  I can think of 
a couple of apps that *don't* pre-select a file that was previously specified 
as a user preference.  I was surprised, because the apps are otherwise very 
well thought out.  Now I see the reason must be this limitation of NSOpenPanel.

> I filed a radar on this issue forever ago and naturally it was closed as a 
> duplicate. As everyone says, maybe file your own radar report to register a 
> vote with Apple. Though considering how long this functionality has gone 
> missing, I doubt we’ll see any changes– especially if Apple considers this 
> any kind of security risk.

I'm pessimistic too, but if I ever get around to filing a radar I'll let you 
know.

--Andy


___

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: How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Andy Lee]

Interesting.

I should mention I hadn't turned on sandboxing in this project.  When I turn it 
on, and I set the "User Selected File" entitlement to "Read Only", I get the 
same behavior as before: TextEdit.app is selected in the panel's column view, 
and it's treated like a regular (non-bundle) directory, with "Contents" exposed 
in the next column.  The same happens, by the way, with other package types 
like .playground and .rtfd, so it isn't specific to .app.  I will file a Radar 
for this, as the NSOpenPanel is clearly not respecting its own 
treatsFilePackagesAsDirectories property when it is initially displayed, though 
it does thereafter.

Given that Apple seemingly does not want NSOpenPanel to pre-select "files" 
(including packages that we pretend are not directories), I would say it's also 
a bug that my NSOpenPanel was able to pre-select TextEdit.app.  I mean "bug" in 
the sense of "not working as Apple intended", as opposed to what my druthers 
would be.

--Andy

On Jun 24, 2016, at 11:31 PM, Charles Srstka  wrote:
> 
>> On Jun 24, 2016, at 7:47 PM, Quincey Morris 
>>  wrote:
>> 
>> On Jun 24, 2016, at 16:24 , Charles Srstka  wrote:
>>> 
>>> How could this be a security threat, when a malicious program could just 
>>> set canChooseDirectories to true, open the panel to the app’s parent 
>>> directory, and spearphish the user into clicking OK on that?
>> 
>> (I wasn’t referring to opening apps, but to files generally.)
>> 
>> Clicking OK won’t do anything until the user selects something, and the app 
>> can’t preset or change the selection. Maybe my logic is incorrect, but this 
>> seems to me to prevent attempts to fool the user into choosing something 
>> unintended.
> 
> func readTheFile(url: NSURL) {
>do {
>let data = try NSData(contentsOfURL: url, options: [])
>guard let string = String(data: data, encoding: NSUTF8StringEncoding) 
> else {
>throw NSCocoaError.FileReadCorruptFileError
>}
> 
>print("Contents of file: \(string)")
>} catch {
>print("Error occurred: \(error)")
>}
> }
> 
> let url = NSURL(fileURLWithPath: "/path/to/MyGreatFile.txt")
> 
> print("First attempt:")
> readTheFile(url)
> 
> let dirURL: NSURL = {
>while true {
>let openPanel = NSOpenPanel()
> 
>openPanel.canChooseDirectories = true
>openPanel.directoryURL = url.URLByDeletingLastPathComponent
>openPanel.prompt = "OK"
>openPanel.message = "Please click OK"
> 
>let answer = openPanel.runModal()
> 
>if answer == NSFileHandlingPanelOKButton, let openPanelURL = 
> openPanel.URL where openPanelURL == url.URLByDeletingLastPathComponent {
>return openPanelURL
>} else {
>let alert = NSAlert()
> 
>alert.messageText = "Hey buddy, click the OK button when I tell 
> you to, okay?"
> 
>alert.runModal()
>}
>}
> }()
> 
> print("Second attempt:")
> 
> dirURL.startAccessingSecurityScopedResource()
> readTheFile(url)
> dirURL.stopAccessingSecurityScopedResource()
> 
> --
> 
> After clicking OK when asked, this outputs:
> 
> First attempt:
> Error occurred: Error Domain=NSCocoaErrorDomain Code=257 "The file 
> “MyGreatFile.txt” couldn’t be opened because you don’t have permission to 
> view it." UserInfo={NSFilePath=/path/to/MyGreatFile.txt, 
> NSUnderlyingError=0x60046750 {Error Domain=NSPOSIXErrorDomain Code=1 
> "Operation not permitted"}}
> Second attempt:
> Contents of file: This is my great file!
> 
> 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

How to pre-select a file in NSOpenPanel -- specifically, a .app bundle?

[Andy Lee]

How do I present an NSOpenPanel with a particular file pre-selected?

I can pre-select a *directory* by setting openPanel.directoryURL.  Since the 
file I want to select is actually a .app bundle, which is really a directory, 
you might think I'm in luck, but not quite.

Here's the code I tried:

NSOpenPanel *openPanel = [NSOpenPanel openPanel];
openPanel.treatsFilePackagesAsDirectories = NO;
openPanel.allowsMultipleSelection = NO;
openPanel.canChooseDirectories = NO;
openPanel.canChooseFiles = YES;
openPanel.resolvesAliases = YES;
openPanel.allowedFileTypes = @[@"app"];
openPanel.allowsOtherFileTypes = NO;

NSString *appBundlePath = @"/Applications/TextEdit.app";
openPanel.directoryURL = [NSURL fileURLWithPath:appBundlePath];
[openPanel beginSheetModalForWindow:self.window
  completionHandler:^(NSInteger result) {
  NSLog(@"Result is %zd", result);
  }];

When I run this, the good news is that TextEdit.app gets selected.  The bad 
news is that it is treated as a regular directory, and its "Contents" 
subdirectory is exposed in the file browser:



If I click away, then click back on TextEdit, I get what I wanted in the first 
place:



I've tried workarounds that Google turned up.  One was to use URLWithString: 
rather than fileURLWithPath:.  Another was to go ahead and call a deprecated 
method like beginSheetForDirectory.  These may have worked once upon a time, 
but they don't for me on 10.11.5.

It almost looks like the ability to pre-select a file was deliberately removed 
from the NSOpenPanel API.  Could that be the case?

--Andy


___

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: Set font on NSTextView that uses bindings?

[Andy Lee]

Suggestion 1: A few weeks ago I ran into the same problem.  I stumbled onto a 
kludge that seems to work, which was to put some text into the text view in IB. 
 It can be spaces, it can be anything, as long as it's non-empty and it uses 
the desired font.  It seems that the bindings mechanism is then able to replace 
that text while preserving the font.  I have the rich text option turned off, 
and I'm using the Value binding of the NSTextView.

Suggestion 2: I found a different kludge that I used 5 years ago where I send 
setFont: to the text view, in code..  Haven't retested to see if that still 
works, and I don't actually have the whole project handy, just an email where I 
describe the workaround.  I do it in windowControllerDidLoadNib:, which is an 
NSDocument method.  If you're not using NSDocument it might work to call 
setFont: in some other "DidLoad" method.

Idle speculation: It seems NSTextView doesn't quite do what one would guess, 
font-wise, when it's empty.  I'm too lazy right this moment to explore, but 
maybe it actually contains an attributed string of zero length that has the 
wrong font, not the one you thought you'd told it to use.

Possibly related: In the Stickies app I sometimes create a new note, paste some 
text, and realize I've pasted in rich text where I didn't actually want the 
font or formatting.  What I really want is for the whole text to use the 
default font I specified for new notes.  The reasonable thing would be hit Undo 
to return to an empty note, and do a Paste and Match Style.  But if I do that I 
won't get my default font.  Rather, the whole text will use a font from the 
original rich text.  So it seems Undo doesn't return me 100% to the state the 
text view was in previously.  My workaround is to discard that note, create a 
new note, and this time remember to do Paste and Match Style.

--Andy

On May 18, 2016, at 11:47 PM, Rick Mann  wrote:
> 
> I seem to be unable to set the font used in an NSTextView that uses bindings 
> to set the text content. The property it's bound to creates a plain NSString 
> (no attributes).
> 
> I've tried setting the font, setting the typing attributes, setting the font 
> on textStorage, all to no avail.
> 
> Any ideas? 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/aglee%40mac.com
> 
> This email sent to ag...@mac.com


___

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

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

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

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

Re: Disable Text Replacement

[Andy Lee]

On Feb 10, 2015, at 11:42 AM, Andreas Höschler  wrote:
> What puzzles me is that [self 
> respondsToSelector:@selector(setAutomaticQuoteSubstitutionEnabled:)] returns 
> NO!? How can this be?

It can't, assuming self is an NSTextView (or, as you seem to be using, a 
subclass of NSTextView).

How do you know the above returns NO?  Are you using NSLog to print it?  If so, 
also log what self is, something like this:

NSLog(@"%@ %d", [self className], [self 
respondsToSelector:@selector(setAutomaticQuoteSubstitutionEnabled:)]);

I subclassed NSTextView and the above NSLog printed this:

2015-02-10 21:27:21.747 MyApp[69306:303] MyTextView 1

--Andy


___

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: Disable Text Replacement

[Andy Lee]

On Feb 10, 2015, at 6:15 AM, Andreas Höschler  wrote:
> I also found
> 
>   NSLog(@"isAutomaticTextReplacementEnabled %d", [NSSpellChecker 
> isAutomaticTextReplacementEnabled]);
>   NSLog(@"isAutomaticSpellingCorrectionEnabled %d", [NSSpellChecker 
> isAutomaticSpellingCorrectionEnabled]);
> 
> but no corresponding set methods!?
> 


Note that you're messaging the NSSpellChecker class and not your NSTextView 
instance.  Those class methods on NSSpellChecker reflect system-wide settings.  
For example, +isAutomaticSpellingCorrectionEnabled reflects the state of the 
checkbox at System Preferences > Keyboard > Text > "Correct spelling 
automatically".  You can see this for yourself: go to System Preferences, 
change that checkbox, run your program again, and the NSLog will print a 
different value.

When a text view is created it uses your system-wide settings for spelling 
correction, etc.  Thereafter it is possible to change the settings for the text 
view independently of the system-wide settings.  To see this for yourself: 
right-click a text view and look at "Spelling and Grammar".  There's a "Correct 
Spelling Automatically" menu item that you can toggle that affects just that 
text view.

>   [NSSpellChecker setAutomaticTextReplacementEnabled:NO]; <— method does 
> not exist

Again, you're messaging the NSSpellChecker class rather than your NSTextView 
instance.  NSSpellChecker does not have a +setAutomaticTextReplacementEnabled: 
class method, but NSTextView *does* have a -setAutomaticTextReplacementEnabled: 
instance method.  So you can do this:

[_textView setAutomaticTextReplacementEnabled:NO];

--Andy


___

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: How do I temporary retain self, under ARC?

[Andy Lee]

And of course the second I hit Send I realized the do {} idea doesn't work.  
Imagine if it was some variable other than self that you might *deliberately* 
use to indicate when the loop should terminate.

--Andy

--Andy

> On Jul 18, 2014, at 10:07 AM, Andy Lee  wrote:
> 
> You could even eliminate the (admittedly negligible) cost of setting 
> keepAlive = nil by changing the if(keepAlive) to if(!keepAlive).
> 
> Along the lines of avoiding a message send, I wonder if this would work:
> 
> do {
>// ...
> } while (!self);
> 
> --Andy
> 
>> On Jul 18, 2014, at 9:41 AM, Gerd Knops  wrote:
>> 
>> That's similar to what I have used. Initially it started out simply as
>> 
>>   idkeepAlive=self;
>>   ...
>>   keepAlive=nil;
>> 
>> but a few Xcode versions ago the static analyzer started complaining that it 
>> wasn't really doing anything. So that last line became
>> 
>>   if(keepAlive) { keepAlive=nil; }
>> 
>> which shut up the analyzer. [keepAlive self]; like Andy suggests would 
>> probably work just as well, though probably a tad more expensive as a method 
>> call is involved.
>> 
>> Gerd
>> 
>>>> On Jul 17, 2014, at 11:23 PM, Andy Lee  wrote:
>>>> 
>>>> On Jul 17, 2014, at 11:01 PM, Jens Alfke  wrote:
>>>> Once I’ve identified such a bug, the fix is easy: put a [[self retain] 
>>>> autorelease] at the top of the method. Except now I’m using ARC, and I 
>>>> can’t find a simple way of doing it. I tried adding
>>>>   __unused id retainedSelf = self;
>>>> but the optimizer recognizes that retainedSelf isn’t used and strips it 
>>>> out, making this a no-op. The only thing I’ve found that works is
>>>>   CFRetain((__bridge CFTypeRef)self);
>>>> at the top of the method, and a corresponding CFRelease at the end, but 
>>>> this is pretty ugly and could cause leaks if the method returns early.
>>> 
>>> How about
>>> 
>>>   id retainedSelf = self;
>>> 
>>> at the beginning and
>>> 
>>>   [retainedSelf self];
>>> 
>>> at the end?
>>> 
>>> --Andy
>>> 
>>> 
>>> ___
>>> 
>>> 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/gerti-cocoadev%40bitart.com
>>> 
>>> This email sent to gerti-cocoa...@bitart.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: How do I temporary retain self, under ARC?

[Andy Lee]

You could even eliminate the (admittedly negligible) cost of setting keepAlive 
= nil by changing the if(keepAlive) to if(!keepAlive).

Along the lines of avoiding a message send, I wonder if this would work:

do {
// ...
} while (!self);

--Andy

> On Jul 18, 2014, at 9:41 AM, Gerd Knops  wrote:
> 
> That's similar to what I have used. Initially it started out simply as
> 
>idkeepAlive=self;
>...
>keepAlive=nil;
> 
> but a few Xcode versions ago the static analyzer started complaining that it 
> wasn't really doing anything. So that last line became
> 
>if(keepAlive) { keepAlive=nil; }
> 
> which shut up the analyzer. [keepAlive self]; like Andy suggests would 
> probably work just as well, though probably a tad more expensive as a method 
> call is involved.
> 
> Gerd
> 
>> On Jul 17, 2014, at 11:23 PM, Andy Lee  wrote:
>> 
>>> On Jul 17, 2014, at 11:01 PM, Jens Alfke  wrote:
>>> Once I’ve identified such a bug, the fix is easy: put a [[self retain] 
>>> autorelease] at the top of the method. Except now I’m using ARC, and I 
>>> can’t find a simple way of doing it. I tried adding
>>>__unused id retainedSelf = self;
>>> but the optimizer recognizes that retainedSelf isn’t used and strips it 
>>> out, making this a no-op. The only thing I’ve found that works is
>>>CFRetain((__bridge CFTypeRef)self);
>>> at the top of the method, and a corresponding CFRelease at the end, but 
>>> this is pretty ugly and could cause leaks if the method returns early.
>> 
>> How about
>> 
>>id retainedSelf = self;
>> 
>> at the beginning and
>> 
>>[retainedSelf self];
>> 
>> at the end?
>> 
>> --Andy
>> 
>> 
>> ___
>> 
>> 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/gerti-cocoadev%40bitart.com
>> 
>> This email sent to gerti-cocoa...@bitart.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: How do I temporary retain self, under ARC?

[Andy Lee]

On Jul 17, 2014, at 11:01 PM, Jens Alfke  wrote:
> Once I’ve identified such a bug, the fix is easy: put a [[self retain] 
> autorelease] at the top of the method. Except now I’m using ARC, and I can’t 
> find a simple way of doing it. I tried adding
>   __unused id retainedSelf = self;
> but the optimizer recognizes that retainedSelf isn’t used and strips it out, 
> making this a no-op. The only thing I’ve found that works is
>   CFRetain((__bridge CFTypeRef)self);
> at the top of the method, and a corresponding CFRelease at the end, but this 
> is pretty ugly and could cause leaks if the method returns early.

How about

id retainedSelf = self;

at the beginning and

[retainedSelf self];

at the end?

--Andy


___

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: Pop-up menus not working in NSOutlineView with image subview

[Andy Lee]

Maybe use a subclass of NSImageView that returns nil for hitTest:?  Just a 
thought.

--Andy

On Wed, Jul 2, 2014, at 10:40 PM, Tim Hewett wrote:
> I have an NSOutlineView with a NSImageView subview providing a background 
> image. Now a pop-up menu has been added to the outline view it seems the menu 
> only appears with a secondary click on a trackpad. Ctrl-click and the right 
> mouse button do not pop up the menu.
> 
> Removing the background image causes the menu to work as wanted.
> 
> It seems the image is blocking the events for the outline view menu (except 
> for the trackpad secondary clicks…!?), is there a way to get the mouse events 
> through to the outline view? The addSubview:positioned:relativeTo: method has 
> been tried using NSWindowBelow has been tried for the image view as an 
> attempt to add it “behind” the outline view but made no difference.

___

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: NSAlert - Default Cancel also respond to Escape?

[Andy Lee]

On May 19, 2014, at 4:30 PM, Seth Willits  wrote:
> Any ideas on how to get a Cancel button which is both the default button and 
> responds to escape? Both require setting the button's key equivalent and 
> there can only be one. 

This seems to work:

NSAlert *alert = [[NSAlert alloc] init];

[alert setMessageText:@"Message text"];
[alert setInformativeText:@"Informative text."];

NSButton *okButton = [alert addButtonWithTitle:@"OK"];
NSButton *cancelButton = [alert addButtonWithTitle:@"Cancel"];
[cancelButton setFrame:NSMakeRect(1, 1, 0, 0)];
[cancelButton setTarget:okButton];
[cancelButton setAction:@selector(performClick:)];

[alert runModal];

It uses the fact that

> any button with a title of “Cancel” has a key equivalent of Escape


You don't need to set the target and action, but they complete the illusion of 
Esc being a key equivalent for the OK button.

--Andy


___

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: JSONSerialization 'Garbage at end' error

[Andy Lee]

On Apr 30, 2014, at 3:21 PM, Jens Alfke  wrote:
> On Apr 30, 2014, at 8:20 AM, Diederik Meijer | Ten Horses 
>  wrote:
> 
>> Now here is the problem: although the JSON parses fine and populates a 
>> UITableView without any issues, I am still getting the following error:
> 
> If the JSON parsed fine, then the error must be coming from somewhere else. A 
> call to JSONObjectWithData: either returns a parsed object, or returns nil 
> and sets the error. It doesn’t do both :)

Which means...

>NSError *error;
>id jsonObject = [NSJSONSerialization JSONObjectWithData:self.container 
> options:NSJSONReadingAllowFragments error:&error];
>if (error) {
>NSLog(@"ERROR: %@", error);
>}
>else {

...you shouldn't be testing error, you should be checking whether jsonObject is 
nil, and only then look at the error.  Doing it the wrong way around could 
explain false errors.  For example, NSJSONSerialization could pessimistically 
stick an error object in there as the default error, but manage to parse 
successfully and return a non-nil object.  But then I'm not sure how you could 
*also* be having your table populated with the right objects.

--Andy


___

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: JSONSerialization 'Garbage at end' error

[Andy Lee]

On Apr 30, 2014, at 3:21 PM, Jens Alfke  wrote:
> You’ll need to do some detective work to find out what function call that 
> error is really coming from. At that point you can set a breakpoint and look 
> at the input data.

Maybe for debugging purposes you could drop in an open-source JSON parser and 
see if you still get an error.  If so, it'd be easier to figure out where to 
put the breakpoint.

--Andy


___

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: NSToolbarItem Action Not Passed to NSButton...

[Andy Lee]

On Apr 25, 2014, at 5:52 PM, "Peters, Brandon"  wrote:
> Thank you for the guidance! Clicking twice on the toolbar item in IB revealed 
> the NSButton Attribute Inspector. However, now the images will not show 
> despite being set in IB. I tried programmatically to set the images for the 
> outlet NSButton and got error messages pertaining to “not ready yet”.

I've been experimenting some more with creating toolbars in IB, and I've been 
having some frustrations but I *am* able to easily create an image button like 
you're trying to do.

Did you remember to set the "Position" in IB?  I mean the segmented control 
right under where you specify the "Image" and "Alternate" names.

If that's not the problem, all I can think of is a long shot: check the min/max 
values for the size of the toolbar item (not the view, but the NSToolbarItem).  
They probably make sense, but it couldn't hurt to check.

I assume you've read the "Toolbar Programming Topics", but just in case:



I've been reading it (okay, skimming it) and learning some things myself.  
Perhaps I should have mentioned that the last time I set up an NSToolbar there 
*was* no UI in IB...

Out of curiosity -- why are you using a view-based toolbar item, when all it's 
doing is displaying an image that you could simply put into an image-based 
toolbar item?  Bear in mind that if the user chooses the "Text Only" option for 
their toolbar, you'll now have a non-functioning toolbar item, whereas an 
image-based toolbar item will still work.  Of course it would be nice to get 
your button working, if only as an exercise.  I'm just wondering if it makes 
sense UI-wise.

Anyway, I'm definitely seeing the wisdom of this now:

On Apr 23, 2014, at 6:36 PM, Jerry Krinock  wrote:
> [...] NSToolbar/Item are kind of crazy cats and customizing them is often 
> found to be problematic.  If possible, use the default NSToolbarItem and 
> -setImage:.


--Andy

___

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: Good idea/bad idea?

[Andy Lee]

On Apr 25, 2014, at 10:22 AM, Sean McBride  wrote:
> The 'if form' is arguably better for testing too.  Many code coverage tools 
> are line-based, and with this form it's easier to see if your test cases 
> cover going in the branch and not.

Sure, and similarly for plain old stepping through the code.  Xcode steps over 
a whole ?: expression at once, and doesn't show you which branch it took.

--Andy


___

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: NSToolbarItem Action Not Passed to NSButton...

[Andy Lee]

Okay, I just brushed up a bit on toolbars (wow, it's been a *very* long time).

How did you create the instance of RBSStopButtonToolbarItem in the nib?  From 
the docs, I learned that you can drag a view (in your case a button) from the 
IB palette into the Allowed Toolbar Items area.  This should create exactly 
what you wanted: a view-based toolbar item containing an NSButton.  Then you 
could:

* Set the class of the toolbar item to your custom class.
* Set the button's image, alt image, and target in IB.

See 
.

Also, aren't you getting lots of NSLog messages from your validate method?  
Validation occurs with every mouse click and keypress, which means you're 
assigning a brand new NSButton to _button over and over and over.

The stuff you're doing in validate would typically be done in awakeFromNib.  
Check the documentation for awakeFromNib; it explains a lot about nib loading.  
BUT it seems to me you don't need any code to create the button.  You can do it 
in IB.

What *should* go in the validate method is logic to enable or disable the 
button as appropriate at any given time.  So you'll still want 
RBSStopButtonToolbarItem to have a button property, but you'll want to:

* Add IBOutlet to the property declaration.
* In IB, connect the toolbar item to the button.
* Implement -[RBSStopButtonToolbarItem validate] to enable the button if a 
"Stop" operation makes sense, otherwise disable it.

--Andy

On Apr 25, 2014, at 1:23 AM, "Peters, Brandon"  wrote:

> I tried and nothing. The IBOutlet is on the NSToolbarItem custom class. Here 
> is my custom class:
> 
> @interface RBSStopButtonToolbarItem : NSToolbarItem
> {
> NSButton *_button;
> }
> 
> @property (readwrite) NSButton *button;
> 
> @end
> 
> @implementation RBSStopButtonToolbarItem
> 
> @synthesize button = _button;
> 
> -(id)initWithItemIdentifier:(NSString *)itemIdentifier
> {
> self = [super initWithItemIdentifier:itemIdentifier];
> 
> if(self)
> {
> // set min and max size
> [self setMinSize:NSMakeSize(32.0, 32.0)];
> [self setMaxSize:NSMakeSize(32.0, 32.0)];
> 
> NSLog(@"Self: %@", self);
> 
> }
> return self;
> }
> 
> -(void)validate
> {
> NSLog(@"Validate called...");
> // set the original and alternate images...names are "opposite"
> 
> _button = [[NSButton alloc] initWithFrame:NSMakeRect(0, 0, 32, 32)];
> 
> //[_button setFrameSize:NSMakeSize(32.0, 32.0)];
> 
> NSImage *image = [NSImage imageNamed:@"StopButtonAlternateIcon"];
> [image setSize:NSMakeSize(32.0, 32.0)];
> [_button setImage:image];
> 
> image = [NSImage imageNamed:@"StopButtonIcon"];
> [image setSize:NSMakeSize(32.0, 32.0)];
> [_button setAlternateImage:image];
> 
> // image position
> [_button setImagePosition:NSImageOnly];
> 
> // set button type
> [_button setButtonType:NSToggleButton];
> 
> // button is transparent
> [_button setBordered:NO];
> 
> // set the toolbar item view to the button
> [self setView:_button];
> }
> 
> @end
> 
> The images will display, but the action does not seem to “connect”, even 
> though it is done in IB.


___

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: NSToolbarItem Action Not Passed to NSButton...

[Andy Lee]

On Apr 24, 2014, at 11:15 PM, "Peters, Brandon"  wrote:
> My button is inside the customer toolbar item, if I make the button an 
> outlet, how will I connect to it in IB?

You can do it in code when you set it up.  See setAction: and setTarget:.

I don't know for sure if that'll work -- it's the only guess I can come up with.

--Andy


___

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: NSToolbarItem Action Not Passed to NSButton...

[Andy Lee]

Try setting the target/action on the button rather than the toolbar item.

--Andy

On Apr 24, 2014, at 10:47 PM, "Peters, Brandon"  wrote:

> Andy,
> 
> I get the name of the custom NSToolbarItem, which I should get.
> 
> On Apr 24, 2014, at 10:41 PM, Andy Lee  wrote:
> 
>> On Apr 24, 2014, at 10:23 PM, "Peters, Brandon"  wrote:
>>> Yesterday, I got the view for the NSToolbarItem to show the desired image 
>>> by putting the set image code for the button in the toolbar item’s 
>>> validate() method, then setting the toolbar item’s view to the button in 
>>> that method. However, now when I click the toolbar item in the app, the 
>>> action does not get called even though I used IB to set the action. If I 
>>> put the code back in the init() method, the default button shows and not 
>>> what I want, but the action gets called.
>> 
>> In your init method, if you use NSLog to print self.toolbarItem, what do you 
>> get?
>> 
>> --Andy
>> 
> 


___

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: NSToolbarItem Action Not Passed to NSButton...

[Andy Lee]

On Apr 24, 2014, at 10:23 PM, "Peters, Brandon"  wrote:
> Yesterday, I got the view for the NSToolbarItem to show the desired image by 
> putting the set image code for the button in the toolbar item’s validate() 
> method, then setting the toolbar item’s view to the button in that method. 
> However, now when I click the toolbar item in the app, the action does not 
> get called even though I used IB to set the action. If I put the code back in 
> the init() method, the default button shows and not what I want, but the 
> action gets called.

In your init method, if you use NSLog to print self.toolbarItem, what do you 
get?

--Andy


___

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: Good idea/bad idea?

[Andy Lee]

On Apr 24, 2014, at 5:45 PM, Quincey Morris 
 wrote:
> On Apr 24, 2014, at 14:21 , Andy Lee  wrote:
> 
>> I still don't see how
>> 
>> foo = [@"Something" fallbackIfNil:foo];
>> 
>> has any advantage over
>> 
>> foo = foo ?: @"Something";
> 
> I don’t see how the latter has any advantage over your earlier suggestion 
> [more or less]:
> 
>   if (!foo)
>   foo = @“Something”;
> 
> Admittedly, it takes two lines instead of one.

Well, I'd use braces in the latter case, and I put opening braces on their own 
line, so for me it'd be four vs. one. :)  But I don't have an objection to the 
"long form".

Because "foo" appears twice, you could conceivably change one and forget to 
change the other, but that's true of the ?: version too, which is another 
argument for a ?:= operator.

Occasionally when there's a repeating pattern I think it's clearer when things 
fit on one line, because successive lines make the pattern easier to spot.  
What I mean is something like

foo = foo ?: [UserPrefs fooValue];
foo = foo ?: [GlobalSettings fooValue];
foo = foo ?: @"LastResort";

Not that I've done it, but this can even be written as

foo = foo ?: [UserPrefs fooValue]
  ?: [GlobalSettings fooValue]
  ?: @"LastResort;

> Is there *any* confusion over the “if” version?

That's an excellent point, and I'm always happy to type a little more to make 
things clearer.  At the same time, I think reasonable people can differ over 
which is preferable.  It might just be a matter of acclimation.  As a matter of 
program logic, binary ?: should be no more confusing than the fact that && and 
|| are short-circuiting operators.  On the other hand, sometimes splitting a 
boolean calculation into separate statements is clearer than using && and/or 
||, so your point applies as well.

Consider how unsettling people find it that Objective-C allows and even expects 
messages to nil.  That is, we routinely say

[obj doSomething];

instead of

if (obj)
{
[obj doSomething];
}

After a while, we get used to the Objective-C way and don't have to calculate 
in our heads every time, "Let's see, if obj is nil, this will return zero, and 
that's okay because..."  Maybe the same could happen with ?:.

--Andy

___

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: Good idea/bad idea?

[Andy Lee]

On Apr 24, 2014, at 6:03 PM, Lee Ann Rucker  wrote:
> That's the flip side of what I was thinking about, but also useful. I was 
> thinking about the code that receives the dictionary:
> 
> - (void)processDictionary:(NSDictionary *)d
> {
>  foo = [[d valueForKey:@"foo"] orIfNull:fooDefault];
> ...

Oh, I see.  So there really are two arguments: the thing that might or might 
not be an NSNull, and the default you want to use in case it is.

Offhand I might prefer adding a category method to NSDictionary:

foo = [d objectForKey:@"foo" default:fooDefault];

This way you could have it check for both nil (when the dictionary doesn't have 
a value for that key) and NSNull.

--Andy

___

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: Good idea/bad idea?

[Andy Lee]

On Apr 24, 2014, at 5:39 PM, Lee Ann Rucker  wrote:
> An orIfNull: for NSObject and NSNull might be nice for those times when you 
> put placeholders in dictionaries.

For that you really only need a method in one place.  I'd be inclined to put it 
in NSNull:

+ (id)nullIfNil:(id)obj
{
return obj ?: [self null];
}

And then in constructing your dictionary you'd have code like

NSDictionary *myLookup = @{ key1, [NSNull nullIfNil:value1],
key2, [NSNull nullIfNil:value2],
... };

For brevity I might not use a method at all; since this is a special case where 
there is only one variable, a function or macro is much less clunky:

NSDictionary *myLookup = @{ key1, ObjOrNull(value1),
key2, ObjOrNull(value2),
... };

--Andy

___

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: Good idea/bad idea?

[Andy Lee]

On Apr 24, 2014, at 5:00 PM, Scott Ribe  wrote:
> What's wrong with the simple straightforward C way???

One improvement might be if there was a ?:= conditional assignment operator. 
Just as

x += y;  is the same as  x = x + y;

and likewise for other binary operators, you could have

x ?:= y;  be the same as  x = x ?: y;

It could be read aloud as "if 0 equals" or "if nil equals", as in "x if nil 
equals y".

--Andy

___

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: Good idea/bad idea?

[Andy Lee]

On Apr 24, 2014, at 4:10 PM, Alex Zavatone  wrote:

> Could we throw a category on NSObject for that and then every class that 
> originates with NSObject gets that lovely method?

Not exactly, because unlike Smalltalk's nil, Objective-C's nil is *not* an 
object.  But you could switch it around:

@implementation NSObject (NilCheck)
- (id)fallbackIfNil:(id)obj { return obj ?: self; }
@end

I still don't see how

foo = [@"Something" fallbackIfNil:foo];

has any advantage over

foo = foo ?: @"Something";

which is less verbose, doesn't have the cost of a message send, and uses an 
operator the reader of the code should already know.

--Andy

> 
> Agree on the clunky bit, but so is using the @ compiler directive to 
> accomplish everything that couldn't be fit in in the first place.  Not as if 
> I know a better way to do it, but I agree, they do feel clunky.
> 
> On Apr 24, 2014, at 3:48 PM, Lee Ann Rucker wrote:
> 
>> In Smalltalk, where nil is an object like everything else, and we were 
>> working with calls out to C APIs that had a lot of required parameters, we 
>> added an "orIfNil:" that was very useful:
>> 
>> foo := bar orIfNil:10.
>> 
>> Nil
>> orIfNil:other
>> ^other
>> 
>> Object
>> orIfNil:other
>> ^self
>> 
>> It would be useful in ObjC if there were an elegant way to do it. Macros are 
>> just clunky.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com
> 
> This email sent to ag...@mac.com

___

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

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

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

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

Re: Good idea/bad idea?

[Andy Lee]

On Apr 24, 2014, at 11:14 AM, Alex Zavatone  wrote:

> 
> On Apr 24, 2014, at 11:12 AM, Luther Baker wrote:
> 
>> Not native and I've no idea when or if this is a good idea ... nor am I sure 
>> how much typing you want to do ... but you _could_ create a class 
>> convenience method for this
>> 
>>   x = [Thing defaultIfNil:x];
>> 
>> With shorter or longer names as you see fit ... down to possibly:
>> 
>>   x = [Thing :x]
>> 
>> I've really no idea if that syntax would work but it stands out and might be 
>> easy to use and identify in the code!
>> 
>> -Luther
> 
> Heey, that's awesome.
> 
> The efficiency monger (aka lazy programmer) who posed me the question in the 
> first place will like that.

It's even lazier :) *and* more efficient (in the CPU sense) to use the binary 
?:, aka the "otherwise" operator:



On a side note, although ":" is legal as a component of a method name -- you 
could have a method called ":" if you wanted -- I would strongly recommend 
against using it.  The purpose of Objective-C's distinctive method syntax is so 
that you can describe each argument with a bit of wording that is right next to 
the argument.

Apple has a few API methods with naked colons, e.g. 
functionWithControlPoints.  IMO that was a mistake.

--Andy

___

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: Good idea/bad idea?

[Andy Lee]

On Apr 24, 2014, at 10:33 AM, Alex Zavatone  wrote:
> I was just asked yesterday if there is any shorthand in Objective-C for "if 
> this thing = nil, then instantiate a new instance from the class"
> 
> Something like this:
> 
> NSString x;
> 
> if ([x isEqualtoString:nil]) {
>x = @"yo";
> } 

I know this is just for illustrative purposes, but this won't work because 
messages to nil return zero, and so the if-test will always return false.  You 
want:

NSString *x;  // Added missing "*" :).
if (x == nil) {
   x = @"yo";
}

> And we messed around a bit looking for any shorthand and though it looked 
> like a terrible idea since the comparison is done against integers using the 
> ternary operator, I'd like to know exactly why it's a terrible idea.
> 
> NSString x;
> 
> x = (x) ?: @"yo";

That's how I'd do it.  It's equivalent to

x = x ? x : @"yo";  // Note you don't need the parens.

which in turn is equivalent to the if statement above.  It's perfectly okay to 
test a pointer for nil in this way:



We do it all the time, as in

self = [super init];
if (self) {
...
}

--Andy

___

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: NSToolbarItem view set to NSButton view, but not showing...

[Andy Lee]

Oh well, it was worth a try, and at least you've confirmed some basic steps 
*are* working.

From your previous message it sounds like you also checked self.toolbarItem and 
it too was not nil (as it could have been if, for example, you'd forgotten to 
connect an outlet in IB -- or if you were trying to plug in the button during 
init, which is too early).

If I understand what Jerry was getting at, you might want to log the addresses 
of the toolbar item and the button, and at some later point in the program 
confirm everything's still where you think it is.  For example, you could put a 
breakpoint in the toolbar item's action method and look at sender.  (I *think* 
that makes sense, but it might not; I haven't made a toolbar in long time.)

As a really trivial sanity check, maybe instead of setting the image, you could 
set the title.  If you still have the problem, at least you know it's not 
related to setting the image.

--Andy

On Apr 23, 2014, at 8:47 PM, "Peters, Brandon"  wrote:

> Andy,
> 
> I inserted code to check for nil images and image position, here is what I 
> got:
> // set the original and alternate images...names are “opposite"
> NSImage *image = [NSImage imageNamed:@"StopButtonAlternateIcon”];
> if(image)
> {
> NSLog(@"Setting 1st image for stop button");
> [_button setImage:image];
> }
> else
> {
> NSLog(@"Image is null for StopButtonAlternateIcon");
> }
> 
> image = [NSImage imageNamed:@"StopButtonIcon"];
> if(image)
> {
> NSLog(@"Setting 2nd image for stop button");
> [_button setAlternateImage:image];
> }
> else
> {
> NSLog(@"Image is null for StopButtonIcon");
> }
> 
> // image position
> [_button setImagePosition:NSImageOnly];
> NSLog(@"Image position: %lu", [_button imagePosition]);
> 
> 
> From the console:
> 2014-04-23 20:41:18.394 3D Rolling Ball Simulator[6321:303] Setting 1st image 
> for stop button
> 2014-04-23 20:41:18.395 3D Rolling Ball Simulator[6321:303] Setting 2nd image 
> for stop button
> 2014-04-23 20:41:18.395 3D Rolling Ball Simulator[6321:303] Image position: 1
> 
> On Apr 23, 2014, at 7:59 PM, Andy Lee  wrote:
> 
>> 
>> On Apr 23, 2014, at 6:36 PM, Jerry Krinock  wrote:
>> 
>>> 
>>> On 2014 Apr 23, at 15:13, Peters, Brandon  wrote:
>>> 
>>>> call [toolbaritem setView:view] and pass in the NSButton.
>>> 
>>> Try some bonehead debugging with NSLog().  Verify that toolbaritem is your 
>>> target item at that point, in particular, that it is not nil.
>> 
>> Two more things you can easily check:
>> 
>> * [NSImage imageNamed:imageName] is not returning nil.
>> * What is your button's imagePosition?  If it's NSNoImage that might explain 
>> it.
>> 
>> --Andy
>> 
>> ___
>> 
>> 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/bap04e%40my.fsu.edu
>> 
>> This email sent to bap...@my.fsu.edu
> 

___

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: NSToolbarItem view set to NSButton view, but not showing...

[Andy Lee]

On Apr 23, 2014, at 6:36 PM, Jerry Krinock  wrote:

> 
> On 2014 Apr 23, at 15:13, Peters, Brandon  wrote:
> 
>> call [toolbaritem setView:view] and pass in the NSButton.
> 
> Try some bonehead debugging with NSLog().  Verify that toolbaritem is your 
> target item at that point, in particular, that it is not nil.

Two more things you can easily check:

* [NSImage imageNamed:imageName] is not returning nil.
* What is your button's imagePosition?  If it's NSNoImage that might explain it.

--Andy

___

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: ARC Retain Cycles

[Andy Lee]

On Apr 21, 2014, at 5:18 PM, Kevin Meaney  wrote:

> On 21 Apr 2014, at 21:09, Andy Lee  wrote:
>> 
>> The solution is to use a weak reference for one of the properties in the 
>> cycle.  In general, if one object conceptually "owns" the other, then the 
>> "owning" object uses a weak reference and the "owned" object uses a strong 
>> one.  For example, a parent has weak references to its children, and the 
>> children have strong references back to the parent.  Similarly, a delegating 
>> object has a weak reference to its delegate, which typically (though not 
>> necessarily) has a strong reference back to the delegator.
> 
> Unless I'm being confused here by your wording. Your recommendation in 
> relation to the parent child relationship is completely turned around from 
> what Apple suggests:
> 
> https://developer.apple.com/library/ios/releasenotes/objectivec/rn-transitioningtoarc/introduction/introduction.html
> See section: Use Lifetime Qualifiers to Avoid Strong Reference Cycles
> 
> If you are recommending an alternative to what Apple suggests I'd be quite 
> interested into hearing the reasons. Do you implement an array of weak 
> references to a list of children?

No, you got it right and I got it backwards.  The "owning" reference is the 
strong one -- so, for example, a regular array of children does the right 
thing.  My apologies.

--Andy

___

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: ARC Retain Cycles

[Andy Lee]

On Apr 21, 2014, at 10:53 AM, Alex Zavatone  wrote:
> 
> On Apr 21, 2014, at 10:34 AM, Andy Lee wrote:
> 
>> On Apr 21, 2014, at 8:27 AM, Dave  wrote:
>>> Also, when I did this, I left the property attributes as “retain” and 
>>> “assign”, I’m wondering if it would be better to change them to “strong” 
>>> and “weak” ? Although, AFAIK this shouldn’t make a difference?
>> 
>> For object properties, "strong" is a synonym for "retain", but "assign" is 
>> different from "weak".  Weak properties are automatically set to nil when 
>> the object they reference goes away.  If you use "assign" for an object 
>> property, it will not be automatically nil'ed and you may end up with a 
>> garbage pointer.
>> 
>> "weak" is not supported in 10.6 or 10.7, I forget which.  If you need to 
>> support an OS version that supports ARC but not "weak", you should use the 
>> qualifier "unsafe_unretained" rather than "assign".  It behaves the same, 
>> but it expresses intention better, plus you can later do a global replace to 
>> use "weak" when you decide to drop support for that old OS.  In this case 
>> it's up to you to nil out that object property at the appropriate time.
> 
> In that case, is it any significant overhead in simply using strong?

I haven't studied the particulars, but my understanding is that it's weak 
references that add overhead.  A strong property basically does for us what we 
used to do by hand when writing accessor methods.  I'd *guess* it's no slower 
than that, and possibly sometimes faster due to optimizations in ARC.  On the 
other hand, to manage a weak property, the runtime has to know where all the 
weak references are so it can nil them after all the strong references go away. 
 And I suspect their may be synchronization issues which cost additional 
overhead to manage.

Most of the time we want properties to be strong, because the reason for 
*having* the property is to hold on to a reference to the object.  But making 
*all* properties strong leads to the problem of retain cycles -- objects having 
strong references to each other, either directly or through a cycle of 
intermediate objects.  Retain cycles lead to memory leaks, because nobody in 
the cycle will ever have its retain count go to zero, even when all strong 
references from outside the cycle have gone away.

The solution is to use a weak reference for one of the properties in the cycle. 
 In general, if one object conceptually "owns" the other, then the "owning" 
object uses a weak reference and the "owned" object uses a strong one.  For 
example, a parent has weak references to its children, and the children have 
strong references back to the parent.  Similarly, a delegating object has a 
weak reference to its delegate, which typically (though not necessarily) has a 
strong reference back to the delegator.

These examples should be familiar from manual memory management.  When 
implementing the delegate pattern under retain/release, the recommended 
practice is to have objects not retain their delegate, for the same reason of 
avoiding retain cycles.

> In a case of rapidly allocating objects that are strongly linked and weakly 
> linked, are there any tests that have been published to show the overall 
> impact on performance, memory overhead, etc?
> 
> I've got time to perform some simple tests, but no time to do anything 
> terribly robust.
> 
> Are any of you aware of anything out there?

You might try Googling "Marcel Weiher ARC" -- I see this as one search result:

<http://mjtsai.com/blog/2013/09/10/arc-vs-mrc-performance/>

Also I'd suggest poking around on Mike Ash's blog in case he discusses ARC 
performance (not sure if he does).

--Andy


___

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: ARC Retain Cycles

[Andy Lee]

On Apr 21, 2014, at 8:27 AM, Dave  wrote:
> Also, when I did this, I left the property attributes as “retain” and 
> “assign”, I’m wondering if it would be better to change them to “strong” and 
> “weak” ? Although, AFAIK this shouldn’t make a difference?

For object properties, "strong" is a synonym for "retain", but "assign" is 
different from "weak".  Weak properties are automatically set to nil when the 
object they reference goes away.  If you use "assign" for an object property, 
it will not be automatically nil'ed and you may end up with a garbage pointer.

"weak" is not supported in 10.6 or 10.7, I forget which.  If you need to 
support an OS version that supports ARC but not "weak", you should use the 
qualifier "unsafe_unretained" rather than "assign".  It behaves the same, but 
it expresses intention better, plus you can later do a global replace to use 
"weak" when you decide to drop support for that old OS.  In this case it's up 
to you to nil out that object property at the appropriate time.

--Andy





___

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: ARC Retain Cycles

[Andy Lee]

On Apr 21, 2014, at 10:12 AM, Dave  wrote:
> There is a delegate handler which makes passing and calling simple delegates 
> a doddle. This was originally non ARC. 
> 
> There is a property defined:
> 
> @property (nonatomic,retain)  id  payloadObject;
> 
> This is after I ARCed it, before that it didn’t specify it, e.g. it was 
> (nonatomic). I must have made it retain when I was going through the 
> properties. I’m not sure what the default is? I assume it must have been 
> assign for this to work originally.

I'm not sure how your objects connect to each other, but it sounds like you had 
a retain cycle between an object and its delegate.

You should read up on ARC and how delegate relationships are handled to avoid 
retain cycles, since the delegator and the delegate typically point to each 
other.  Basically, objects should not have strong references to their 
delegates, for the same reason that with the old retain/release memory 
management, objects should not retain their delegates.

--Andy


___

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: Image scaling property of NSCell/NSButton - where is it?

[Andy Lee]

(Forgot to hit Reply All a minute ago.)

I notice both NSImageCell and NSImageView implement setImageScaling:.  Both 
NSSegmentedCell and NSSegmentedControl implement setImageScaling:forSegment:.

NSButtonCell implements setImageScaling:, and as it turns out so does NSButton 
-- but the docs don't show the NSButton method.  I don't know if that was an 
oversight in the docs or there was some reason to hide the NSButton method.  
It's very minor, but I'll submit feedback on the docs anyway.

--Andy

On Apr 7, 2014, at 12:38 AM, Graham Cox  wrote:

> Never mind - I found it, it's in NSButtonCell.
> 
> --Graham
> 
> 
> On 7 Apr 2014, at 2:31 pm, Graham Cox  wrote:
> 
>> What is actually set when you choose "proportionally down" or "none", etc in 
>> IB for image scaling in a button or cell? I can't see any property that 
>> takes the type NSImageScaling.
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com
> 
> This email sent to ag...@mac.com

___

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

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

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

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

Re: What do you guys use to convert an XSD to objective C data classes/structures?

[Andy Lee]

Maybe you could check with the developer of Objectify whether he has something 
similar in the works for XML?

http://tigerbears.com/objectify/

--Andy

> On Mar 25, 2014, at 3:15 PM, Alex Zavatone  wrote:
> 
> We have a lot of legacy systems at my latest gig that all use and output XML 
> data.
> 
> For the purpose of consuming server based XML files, we're looking for a 
> method to automate creation of objective c classes that represent the 
> internal XML data structure.
> 
> Is there any compelling reason not to deserialize into dictionaries instead?
> 
> Which approach do you guys use?  
> 
> 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/aglee%40mac.com
> 
> This email sent to ag...@mac.com
___

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

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

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

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

Re: Why does menu item with shift-delete not work?

[Andy Lee]

I think the key event is getting stolen by the first responder of whatever your 
key window is at the time.  I did a quick test and found the menu item did not 
get invoked when a text view was selected but *did* get invoked when I removed 
the text view.

I suspect a more precise technical answer lies in the docs on keyboard event 
handling.  See "Cocoa Event Handling Guide" => "The Path of Key Events", in 
particular the part about key equivalents:



A workaround would be to subclass NSApplication and override keyDown: to detect 
Shift-Delete.  Offhand, I'd think you could do something like

- (void)keyDown:(NSEvent *)theEvent
{
if ([self isShiftDeleteEvent:theEvent]
&& [[NSApp mainMenu performKeyEquivalent:theEvent])
{
return;
}

[super keyDown:theEvent];
}

But maybe someone has a better idea?

--Andy

On Jan 17, 2014, at 12:45 PM, Steve Mills  wrote:

> We have a menu item whose key equiv is shift-delete (backspace, not forward 
> delete). Typing that key does not even call the menu's performKeyEquivalent 
> method. How can we get this to work like it should?
> 
> BTW, I've already noticed that when you set the key equiv in IB, it sets it 
> to 8 (Unicode backspace), but when you type that key, the character in the 
> event is 127 (Unicode delete). Is that the problem? The OS just doesn't know 
> how to map it correctly? I had to remap 127 to 8 in our NSMenu subclass' 
> performKeyEquivalent method in order to get command-delete to work.
> 
> I've also tried programmatically changing the item's key equiv from 0x08 to 
> 0x7f after installing the menu and that didn't help.
> 
> --
> Steve Mills



___

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 with NSSplitView, NSScrollView

[Andy Lee]

On Jan 9, 2014, at 12:48 PM, Kyle Sluder  wrote:
> Nope. Please see the 10.8 AppKit Release Notes, which enumerate all the
> delegate methods which will kick you out of Auto Layout mode:
> 
>> splitView:constrainMinCoordinate:ofSubviewAt:
>> splitView:constrainMaxCoordinate:ofSubviewAt:
>> splitView:resizeSubviewsWithOldSize:
>> splitView:shouldAdjustSizeOfSubview:
>> These methods are incompatible with auto layout. You can typically achieve 
>> their effects and more with auto layout.
> 
> 

I'd like the docs for each of these methods to mention this.  Ideally, to 
remove all doubt for the reader, the docs for the other delegate methods would 
also confirm that it's okay to implement them in the sense that they won't 
disable Auto Layout.

I'll take a couple of minutes to submit docs feedback... later.  As usual I've 
now spent time on something immediately after saying I didn't have time to 
spend. :)

--Andy

___

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 with NSSplitView, NSScrollView

[Andy Lee]

On Jan 9, 2014, at 12:48 PM, Kyle Sluder  wrote:
> On Thu, Jan 9, 2014, at 07:51 AM, Andy Lee wrote:
>> As far as I know (see disclaimers), there's no reason you can't implement
>> split view delegate methods just because you're using Auto Layout, as
>> long as you aren't calling setFrame:.
> 
> Nope. Please see the 10.8 AppKit Release Notes, which enumerate all the
> delegate methods which will kick you out of Auto Layout mode:
> 
>> splitView:constrainMinCoordinate:ofSubviewAt:
>> splitView:constrainMaxCoordinate:ofSubviewAt:
>> splitView:resizeSubviewsWithOldSize:
>> splitView:shouldAdjustSizeOfSubview:
>> These methods are incompatible with auto layout. You can typically achieve 
>> their effects and more with auto layout.
> 
> <https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKitOlderNotes/>

Right -- that's also mentioned in the thread Michael linked to.

> 
>> I would guess it's perfectly all
>> right to implement splitView:constrainSplitPosition:ofSubviewAt:, examine
>> the proposedPosition argument, and allow the view's width to be either
>> zero or >= the minimum width but not in between.
> 
> This is very much not allowed, and wouldn't have been the correct
> approach even before auto layout.

You'd think splitView:constrainSplitPosition:ofSubviewAt: would be included in 
the above list, but it isn't.  I tried implementing it and it didn't disable 
Auto Layout, as, for example, splitView:constrainMinCoordinate:ofSubviewAt: 
does.  So, going by the omission from the docs and from empirical results it 
seems to me this delegate method is allowed.

Maybe it was left off the do-not-use list because there are uses for it that 
are not easily done with Auto Layout -- for example, the one described in the 
docs:

> For example, if a subview’s height must be a multiple of a certain number, 
> use this method to return the multiple nearest to proposedPosition.


In any case, to collapse the view I did indeed have to fiddle with constraints 
within the delegate method, which worked, but was ugly and totally unnecessary 
because:

> To achieve this effect, add a mandatory greater-than-or-equal-to width
> constraint to the subview you want to be collapsible, and implement
> -splitView:canCollapseSubview: to return YES for that subview.

Oh, of course -- it's that simple.  Thanks.  I was worried that the collapsing 
might cause a conflict with constraints on views inside the collapsed view.  
But I just tried it and it works, which is exactly what one would hope.

The key point is that it *is* okay to implement *certain* split view delegate 
methods.

--Andy

___

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 with NSSplitView, NSScrollView

[Andy Lee]

On Jan 9, 2014, at 12:55 PM, SevenBits  wrote:
> On Thu, Jan 9, 2014 at 12:27 PM, Andy Lee  wrote:
>> That's a great thread, thanks!
>> 
>> BTW Apple removed the splitview-without-NSSplitView sample code that's 
>> mentioned in the thread.  For anyone still interested, someone named Darcy 
>> Liu seems to have been archiving all of Apple's sample code:
>> 
>> <https://github.com/darcyliu/CocoaSampleCode>
>> 
>> The splitview example is here:
>> 
>> <https://github.com/darcyliu/CocoaSampleCode/tree/master/Cocoa_Autolayout_Demos/SplitView>
>> 
>> And Darcy has a similar archive of iOS code:
>> 
>> <https://github.com/darcyliu/SampleCode>
>> 
>> You can't just download an individual sample project AFAICT -- you have to 
>> clone or download the entire repo -- but that's not such a bad thing.
> 
> Unless you mind downloading over 300 MBs of code.

True.  I personally don't but I know others have slow connections and/or 
limited disk space.

> I guess if you're a
> fan of sample code then it doesn't matter. However, what I would be
> concerned about is how up to date some of the projects are. Some of
> them were last updated over 11 months ago, and who knows how often
> that person updates the repository?

I don't see anything to be concerned about.  The definitive source should 
always be Apple.  Furthermore, if Apple removes the sample code from their 
site, they presumably did so for a reason.  The code may have been poorly 
written, or it may use techniques that we should no longer use.  Still, there 
may be times when we'd like to see the removed examples anyway, and in those 
cases it's nice to have somewhere to look.

I ran the fake-SplitView example back when it was available, and it bugged me 
that I couldn't find it again.

--Andy


___

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 with NSSplitView, NSScrollView

[Andy Lee]

That's a great thread, thanks!

BTW Apple removed the splitview-without-NSSplitView sample code that's 
mentioned in the thread.  For anyone still interested, someone named Darcy Liu 
seems to have been archiving all of Apple's sample code:

<https://github.com/darcyliu/CocoaSampleCode>

The splitview example is here:

<https://github.com/darcyliu/CocoaSampleCode/tree/master/Cocoa_Autolayout_Demos/SplitView>

And Darcy has a similar archive of iOS code:

<https://github.com/darcyliu/SampleCode>

You can't just download an individual sample project AFAICT -- you have to 
clone or download the entire repo -- but that's not such a bad thing.

--Andy

On Jan 9, 2014, at 11:00 AM, Michael Starke 
 wrote:

> If I recall correctly, if you did implement ANY delegate method using
> 10.7 the split view did fall back to a "non-autolayout" aware mode. At
> least that was my experince. It did change with 10.8. But take this with
> a lot of caution. My memory tends to mess up those things :)
> 
> Ah. There was something:
> http://www.cocoabuilder.com/archive/cocoa/326128-nssplitview-not-resizing-subviews-if-delegate-is-used.html#326128
> 
> -Michael
> 
> On 09.01.2014 16:51, Andy Lee wrote:
>> On Jan 6, 2014, at 11:54 AM, Fritz Anderson  wrote:
>>> On 4 Jan 2014, at 1:38 PM, thatsanicehatyouh...@me.com wrote:
>>> 
>>> I like your user name.
>>> 
>>>> I have a couple of questions about using auto layout (AL) with NSSplitView 
>>>> and NSScrollView. I have watched the (excellent) WWDC videos from 2012, 
>>>> but am having problems.
>>>> I'm trying to implement an NSSplitView
>>> 
>>> [… that collapses one of the views if the user resizes it below a set 
>>> minimum.]
>>> The next thing I’d try (meaning I have no experience and no time to make 
>>> the experiment; others’ solutions would trump mine; and I seem to remember 
>>> this is a solved problem to be found in the archives of this list, Stack 
>>> Overflow, or [ugh] the Developer Forums) is to see whether listening to the 
>>> collapsing view’s NSFrameDidChangeNotification was of help. If the frame 
>>> goes below minimum width, replace the width constraint with a zero.
>> 
>> [same disclaimers as Fritz]
>> 
>> As far as I know (see disclaimers), there's no reason you can't implement 
>> split view delegate methods just because you're using Auto Layout, as long 
>> as you aren't calling setFrame:.  I would guess it's perfectly all right to 
>> implement splitView:constrainSplitPosition:ofSubviewAt:, examine the 
>> proposedPosition argument, and allow the view's width to be either zero or 
>> >= the minimum width but not in between.
>> You might have to fiddle with constraints for the reason Fritz gives:
>> 
>>> Constraints for contained views would tend to push the collapsed view’s 
>>> width out, but reducing the priorities of some of the constraints on the 
>>> views that would push back should take care of that.
>> 
>> You could also add a *higher*-priority constraint that says the collapsed 
>> view's width must be 0, and this would trump the constraints that tend to 
>> push back.  I think.
>> 
>> --Andy
>> 
> -- 
> ___m i c h a e l   s t a r k e
>   geschäftsführer
>   HicknHack Software GmbH
>   www.hicknhack-software.com
> 
> ___k o n t a k t
>   +49 (170) 3686136
>   cont...@hicknhack.com
> 
> ___H i c k n H a c k   S o f t w a r e   G m b H
>   geschäftsführer - maik lathan | andreas reischuck | michael starke
>   bayreuther straße 32
>   01187 dresden
>   amtsgericht dresden HRB 30351
>   sitz - dresden
___

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 with NSSplitView, NSScrollView

[Andy Lee]

On Jan 6, 2014, at 11:54 AM, Fritz Anderson  wrote:
> On 4 Jan 2014, at 1:38 PM, thatsanicehatyouh...@me.com wrote:
> 
> I like your user name.
> 
>> I have a couple of questions about using auto layout (AL) with NSSplitView 
>> and NSScrollView. I have watched the (excellent) WWDC videos from 2012, but 
>> am having problems.
>> 
>> I'm trying to implement an NSSplitView
> 
> [… that collapses one of the views if the user resizes it below a set 
> minimum.]
> 
> The next thing I’d try (meaning I have no experience and no time to make the 
> experiment; others’ solutions would trump mine; and I seem to remember this 
> is a solved problem to be found in the archives of this list, Stack Overflow, 
> or [ugh] the Developer Forums) is to see whether listening to the collapsing 
> view’s NSFrameDidChangeNotification was of help. If the frame goes below 
> minimum width, replace the width constraint with a zero.

[same disclaimers as Fritz]

As far as I know (see disclaimers), there's no reason you can't implement split 
view delegate methods just because you're using Auto Layout, as long as you 
aren't calling setFrame:.  I would guess it's perfectly all right to implement 
splitView:constrainSplitPosition:ofSubviewAt:, examine the proposedPosition 
argument, and allow the view's width to be either zero or >= the minimum width 
but not in between.

You might have to fiddle with constraints for the reason Fritz gives:

> Constraints for contained views would tend to push the collapsed view’s width 
> out, but reducing the priorities of some of the constraints on the views that 
> would push back should take care of that.

You could also add a *higher*-priority constraint that says the collapsed 
view's width must be 0, and this would trump the constraints that tend to push 
back.  I think.

--Andy


___

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 subclass does not seem to start

[Andy Lee]

On Dec 31, 2013, at 9:13 AM, Alex Hall  wrote:
> Sorry, I should have specified - I'm so used to seeing it I didn't even 
> think. The loop is based on an NSTimer and is used to process sound position 
> updates. Basically, I use it to pan sounds and draw updates. I'm not putting 
> key management in there. Here's the setup for it:
>>  [self setGameTimer:[NSTimer scheduledTimerWithTimeInterval:1.0/30 
>> target:self selector:@selector(gameLoop:) userInfo:nil repeats:YES]];
> The docs indicate that this automatically adds itself to the app's mainLoop, 
> so I should be okay here, unless I've misunderstood something (a distinct 
> possibility).

Ah, okay.  I wouldn't expect that to be the cause of the problem then.

> I have no idea how that got in there. :) In the code I'm working with, there 
> is no &. It must have been left over from when I had it in my head that 
> NSRect needed to be passed by reference and was using asterisks all over the 
> place. I'm not doing that anymore, don't worry.

Got it.

>> One more suggestion.  After the program has launched, you might want to see 
>> if everything is what you think it is.  Maybe you could add an action method 
>> in the app delegate that prints out (using NSLog) the current key window, 
>> and its first responder.  Then connect a menu item to that method.  Launch 
>> the program and try to invoke the menu item.  If your problem is the "loop" 
>> thing I wondered about earlier, you won't be able to invoke the menu item.  
>> If not, you should get either a sanity check that you have set up the window 
>> and view correctly, or a possible indication of where the bug is.
> 
> I'll have to re-visit Charles' sample code to be sure I can do this one right 
> as I've never done this before. Perhaps a button would work just as well? It 
> seems less prone to errors from me while setting up. It is a great idea 
> though, and will let me be sure my view is getting drawn in the first place. 
> Thanks for your response.

Oh sure, a button would work as well.  Yeah, in fact I do things like that with 
buttons all the time.  You could also break in the debugger and print the 
information with debugger commands, but often I find a button is handy for this 
kind of sanity checking.

--Andy

___

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 subclass does not seem to start

[Andy Lee]

On Dec 30, 2013, at 5:34 PM, Alex Hall  wrote:
> Anyway, the problem remains that I need to capture keystrokes (and eventually 
> mouse movements) in a subclass of NSView, but nothing seems to happen. Since 
> this is an audio game, there is no need for any UI controls to be drawn - I 
> need only the keyboard/mouse event handler. Therefore, my view has no UI 
> controls, it is merely a rectangle, or should be, with an origin of (0,0). 
> Below, and I apologize in advance for how long this will be, I have laid out 
> the path taken to get the view on the screen. Where I feel it is necessary, I 
> have given source code. Note that I still have the main XIB file Xcode 
> generated. Perhaps I should remove it, I don't know yet.

I would advise against removing it.  Even if you choose to create everything 
else in code, your app should have a main menu so that it can provide standard 
menu items like "About" and "Quit".  Also, MainMenu.xib connects your app 
delegate to the application object.  I can think of no good reason to remove 
it, even if you never use nibs elsewhere.

> 1. My app runs, and the AppDelegate's applicationDidFinishLaunching method is 
> called automatically. In here I create an AITGameController object,, which 
> does the lion's share of the work. I then call this object's initGame and 
> startLoop methods, the first to set up the game and the second to begin the 
> game loop that will drive the app.

I'm a little concerned about this game loop.  Cocoa already provides something 
called a run loop that is entered after your application launches and 
initializes.  You *generally* don't create a loop of your own to process 
events.  Rather, as you have done, you override methods like mouseDown:, 
keyDown:, and keyUp:.  Those messages will be sent to the appropriate object as 
they occur -- be it the first responder or something else.  So I wonder if, 
because you are entering your own loop, you are never entering the run loop, 
which would explain why events never get logged.

> 2. The AITGameController's init method sets up the AITViewController, whose 
> source is below. It then sets up the  AITAudioMenu (my NSView subclass, which 
> is supposed to be logging keystrokes). Now we get into the fun part, so 
> here's the code I am using:
> 
> //from AITGameController > init
> 
>   [self setViewManager:[[AITViewController alloc] init]];
>   NSRect windowSize=NSMakeRect(0.0, 0.0, 200.0, 150.0);
>   NSWindow* mainWindow=[viewManager makeWindowWithRect:&windowSize 
> style:NSTitledWindowMask|NSMiniaturizableWindowMask];

I notice makeWindowWithRect:style: takes an NSRect as its first argument, so 
you should be passing windowSize and not &windowSize.  Unless this is a typo in 
your email, I would have expected a compiler error.

> I hope all this makes some sense. I think what is tripping me up is trying to 
> manage windows like this while IB is still being used, but I really don't 
> know. Thanks for any help, and if anyone from Apple is on here: anytime you 
> guys can make IB fully accessible, I and other budding developers would very 
> much appreciate it. Yes, bug reports have been filed. :)

I think it is not only okay to keep the main nib in the project, but as I said 
I would advise against removing it.  However, something else occurred to me 
that might be coming from MainMenu.xib.  The standard main nib provided by 
Xcode has a window in it, which is pointed to by a property of the app 
delegate.  I wonder if that window is made the key window *after* your window 
is, and is therefore stealing your keyboard events.  I wouldn't *think* so, but 
just to remove the possibility I would get rid of that window altogether.  In 
your case the simplest way to do that is to set the app delegate's window 
property to nil.  That is, in applicationDidFinishLaunching: you could add as 
the first line:

self.window = nil;

One more suggestion.  After the program has launched, you might want to see if 
everything is what you think it is.  Maybe you could add an action method in 
the app delegate that prints out (using NSLog) the current key window, and its 
first responder.  Then connect a menu item to that method.  Launch the program 
and try to invoke the menu item.  If your problem is the "loop" thing I 
wondered about earlier, you won't be able to invoke the menu item.  If not, you 
should get either a sanity check that you have set up the window and view 
correctly, or a possible indication of where the bug is.

--Andy


___

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: How to accept drag of a URL on the dock icon?

[Andy Lee]

Thanks, Ken.  I stumbled onto the solution by way of an old page about how to 
drag text snippets onto the dock icon in an PyObjC app.  Who knows how long I'd 
have been scratching my head if I hadn't guessed the same approach might work 
for URLs.

For a minute it looked like I could use the same code to handle files dragged 
to the dock icon from the Finder.  My service did get invoked, and it was 
passed an NSPasteboard that was superficially similar in that it contained 
URLs, in this case file URLs rather than web URLs.  But when I tried to iterate 
through the file URLs I got messages like this:

2013-12-22 14:43:32.732 DockHow[34606:303] Failed to get a sandbox extensions 
for itemIdentifier (1).  The data for the sandbox extension was NULL

I didn't feel like messing with sandbox stuff, so I implemented 
application:openFiles: in addition to the service.  And now I don't remember if 
that worked, because I decided I didn't really need to accept dragged URLs 
after all!  But still, good to know for future reference.

--Andy

On Dec 21, 2013, at 7:48 PM, Ken Thomases  wrote:

> For what it's worth, this is documented somewhat in Cocoa Scripting Guide: 
> How Cocoa Applications Handle Apple Events – Apple Events Sent by the Mac OS 
> – Open Contents.
> https://developer.apple.com/library/mac/documentation/cocoa/conceptual/ScriptableCocoaApplications/SApps_handle_AEs/SAppsHandleAEs.html#//apple_ref/doc/uid/20001239-1121328
> 
> Cheers,
> Ken
> 
> On Dec 21, 2013, at 5:22 PM, Andy Lee wrote:
> 
>> To answer my own question, it looks like it's done by implementing a 
>> Service.  I've gotten it working in a quick scratch application.
>> 
>> --Andy
>> 
>> On Dec 21, 2013, at 6:06 PM, Andy Lee  wrote:
>> 
>>> I know how to accept files that are dragged from Finder to the application 
>>> icon.  It's a matter of adding some settings to Info.plist and implementing 
>>> the application:openFiles: application delegate method.
>>> 
>>> This does not work for dragging URLs from a web browser -- for example, 
>>> dragging from Safari's URL field, or dragging an image being displayed in 
>>> Safari to the dock icon.  What happens is, my application:openFiles: method 
>>> is never called, and the URL is given back to Safari to reload.
>>> 
>>> Yet it is clearly possible for applications to accept dragging of URLs to 
>>> their Dock icons, because it works for other browsers.  What are those 
>>> other browsers doing?
>>> 
>>> I tried using a custom contentView for the dock tile, and having that view 
>>> be a drag destination (call registerForDraggedTypes: and implement 
>>> NSDraggingDestination methods).  But that didn't make any difference.
>>> 
>>> --Andy
>> 
>> 
>> 
>> ___
>> 
>> 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/ken%40codeweavers.com
>> 
>> This email sent to k...@codeweavers.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: How to accept drag of a URL on the dock icon?

[Andy Lee]

To answer my own question, it looks like it's done by implementing a Service.  
I've gotten it working in a quick scratch application.

--Andy

On Dec 21, 2013, at 6:06 PM, Andy Lee  wrote:

> I know how to accept files that are dragged from Finder to the application 
> icon.  It's a matter of adding some settings to Info.plist and implementing 
> the application:openFiles: application delegate method.
> 
> This does not work for dragging URLs from a web browser -- for example, 
> dragging from Safari's URL field, or dragging an image being displayed in 
> Safari to the dock icon.  What happens is, my application:openFiles: method 
> is never called, and the URL is given back to Safari to reload.
> 
> Yet it is clearly possible for applications to accept dragging of URLs to 
> their Dock icons, because it works for other browsers.  What are those other 
> browsers doing?
> 
> I tried using a custom contentView for the dock tile, and having that view be 
> a drag destination (call registerForDraggedTypes: and implement 
> NSDraggingDestination methods).  But that didn't make any difference.
> 
> --Andy



___

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

How to accept drag of a URL on the dock icon?

[Andy Lee]

I know how to accept files that are dragged from Finder to the application 
icon.  It's a matter of adding some settings to Info.plist and implementing the 
application:openFiles: application delegate method.

This does not work for dragging URLs from a web browser -- for example, 
dragging from Safari's URL field, or dragging an image being displayed in 
Safari to the dock icon.  What happens is, my application:openFiles: method is 
never called, and the URL is given back to Safari to reload.

Yet it is clearly possible for applications to accept dragging of URLs to their 
Dock icons, because it works for other browsers.  What are those other browsers 
doing?

I tried using a custom contentView for the dock tile, and having that view be a 
drag destination (call registerForDraggedTypes: and implement 
NSDraggingDestination methods).  But that didn't make any difference.

--Andy


___

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: Neatly fitting a dash to a rect

[Andy Lee]

On Dec 12, 2013, at 10:52 AM, Graham Cox  wrote:
>> Does it have to be the same exact pattern all the way around?  If it's okay 
>> to differ a teeny bit (I bet imperceptibly), you could solve the problem 
>> separately for the horizontal edges and the vertical edges, and draw four 
>> lines instead of one rect.
> 
> It doesn’t *have* to be the same as long as it doesn’t differ too much 
> visually, but detecting that a path is a simple rect (including rotated 
> cases) and breaking it into h and v lengths might turn out to be the hard 
> part. I also wonder if there’s a way to perform the calculation based on the 
> highest common factor (HCF) of the horizontal and vertical edges? That might 
> allow the dash to be tweaked as a single entity and applied in the usual way.

Interesting.  You could straighten out the angles of the rect and think of 
(say) the top and right edges as a single line:

o---+---+---+---+---o---+---+---o

Each of o's is a corner, and each of the +'s marks off a multiple of the HCF.  
So what you want is for the dash to be tweaked in such a way that all three o's 
are in the middle of some segment.

Sounds fun -- good luck!

--Andy


___

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: Neatly fitting a dash to a rect

[Andy Lee]

On Dec 12, 2013, at 10:06 AM, Andy Lee  wrote:
> In other words, the line length will be an exact multiple of segment length.

Correction: exact multiple of (segmentLength + gapLength).

--Andy


___

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: Neatly fitting a dash to a rect

[Andy Lee]

On Dec 12, 2013, at 10:06 AM, Andy Lee  wrote:
> Does it have to be the same exact pattern all the way around?  If it's okay 
> to differ a teeny bit (I bet imperceptibly), you could solve the problem 
> separately for the horizontal edges and the vertical edges, and draw four 
> lines instead of one rect.

Not sure if this might come out looking wrong depending on lineCap/lineJoin 
styles.

If so, all I can think of is to figure out *two* sets of "fudge" amounts, for 
the horizontal and vertical edges, and maybe apply their average to the dash 
pattern.  I don't know if the math would work out.  This is already just about 
as much as my brain can handle at the moment. :)

--Andy



___

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: Neatly fitting a dash to a rect

[Andy Lee]

I assume you mean dash as in NSBezierPath's setLineDash:count:phase:.  Also, 
does the dash have just two elements (one segment and one gap), or is it more 
complex.

Does it have to be the same exact pattern all the way around?  If it's okay to 
differ a teeny bit (I bet imperceptibly), you could solve the problem 
separately for the horizontal edges and the vertical edges, and draw four lines 
instead of one rect.

Offhand, here's what comes to mind, just solving for one edge and assuming the 
pattern is simply { segmentLength, gapLength }.

In the final solution, how many iterations of the pattern will the line have?  
If both ends are in the middle of a segment, the answer is the same as if one 
end were at the beginning of a segment and the other at the end of a gap.  In 
other words, the line length will be an exact multiple of segment length.

How far off are we from that?  Let's figure out how many iterations fit now, 
and how much is left over.  (Excuse my sloppy floating point coding.)

CGFloat iterationLength = segmentLength + gapLength;
CGFloat numIterations = floor(lineLength / iterationLength);
CGFloat leftOver = lineLength - (numIterations * iterationLength);

We want to spread the leftover amount evenly across all iterations, so let's 
figure out how much to add to each iteration.  We could split that fudge factor 
equally between the segment and the gap, and I bet no one would notice, or to 
be fussy we could distribute it proportionally:

CGFloat iterationFudge = leftOver / numIterations;  // Assume numIterations > 0.
CGFloat segmentFudge = iterationFudge * (segmentLength / iterationLength);
CGFloat gapFudge = iterationFudge * (gapLength / iterationLength);

CGFloat myDashPattern[2] = { segmentLength + segmentFudge, gapLength + gapFudge 
};

// Assume myBezierPath contains the line.
[myBezierPath setLineDash:myDashPattern
count:2
phase:(myDashPattern[0] / 2.0)];

You could probably tweak some things to minimize rounding issues, but I don't 
know if that would make a noticeable difference.

--Andy

On Dec 12, 2013, at 7:54 AM, Graham Cox  wrote:

> Does anyone have code or at least an outline of how to adjust a dash so that 
> it fits exactly to the corners of a rectangle?
> 
> The dash itself is supplied, but may be minimally adjusted in both phase and 
> length of any of its elements to fit, such that the rect corners lie exactly 
> in the centre of a solid part of the dash. It only needs to work for rects.
> 
> 
> —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

-[NSString capitalizedString]

[Andy Lee]

A friend asked why anyone would want the behavior of capitalizedString.  The 
only thing I could think of was to convert all caps to title case, which seems 
an odd scenario to provide API support for.

Is there a more common need for this method that I haven't thought of?

--Andy

Begin forwarded message:
> Got bit by this: "and all remaining characters set to their corresponding 
> lowercase values" - why would anyone want that?
> 
> - (NSString *)capitalizedString
> 
> Description
> 
> Returns a capitalized representation of the receiver.
> 
> 
> 
> A “word” is any sequence of characters delimited by spaces, tabs, or line 
> terminators (listed under getLineStart:end:contentsEnd:forRange:). Some 
> common word delimiting punctuation isn’t considered, so this method may not 
> generally produce the desired results for multiword strings.
> 
> Case transformations aren’t guaranteed to be symmetrical or to produce 
> strings of the same lengths as the originals. See lowercaseString for an 
> example.
> 
> Note
> 
> This method performs the canonical (non-localized) mapping. It is suitable 
> for programming operations that require stable results not depending on the 
> user's locale preference. For localized case mapping for strings presented to 
> users, use the capitalizedStringWithLocale: method.
> 
> Returns
> 
> A string with the first character from each word in the receiver changed to 
> its corresponding uppercase value, and all remaining characters set to their 
> corresponding lowercase values.
___

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: Not documented: NSArray responds to -allObjects

[Andy Lee]

On Oct 24, 2013, at 10:19 AM, Jerry Krinock  wrote:
> Starting somewhere after OS X 10.6, NSArray instances respond to the NSSet 
> method -allObjects.  I can’t find any documentation of this.  Also, it is not 
> declared in the header NSArray.h

I see it's also documented for NSEnumerator, NSHashTable, and NSPointerArray.

Might be worth filing a Radar requesting that method be made official published 
API like it is for the other collection classes.  There might be times when you 
want to be able to send allObjects to a collection without knowing what kind of 
collection it is, and it seems silly to have to special-case NSArray.

If Apple treats it the same as firstObject, you should only have to wait, what, 
ten years to get the API publicly exposed? :)

--Andy


___

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: Setting key equivalent for menus depending on window

[Andy Lee]

> On Oct 20, 2013, at 7:21 AM, Martin Hewitson  
> wrote:
> 
> 
>> On 20 Oct 2013, at 01:15 am, Kyle Sluder  wrote:
>> 
>> Rather than rely on intercepting responder chain-based validation, wouldn't 
>> it be much easier and more reliable to make some object the delegate of all 
>> of your NSMenus and implement -menuNeedsUpdate:?
> 
> But wouldn’t this object then need to know details about the different 
> windows which are presented in the app in order to decide which shortcut key 
> to set?

That's why in my later proposal (using notifications rather than delegation or 
responder-chain stuff) I added category methods to NSWindow, with default 
behavior that you can override in the window that contains tabs.  The app 
delegate does know about the category methods, but it just sends messages to 
windows, it doesn't have any knowledge of what shortcuts are appropriate for 
which window.  Rather, each window knows its own shortcuts.

> I have the feeling that the tabbed window (or its delegate) is the place to 
> make changes to the default menu configuration. I think I will try updating 
> the menu in the windowDidBecomeKey/windowDidResignKey calls of the window’s 
> delegate.

I see by your follow-up that it seems to work, so I'm just tossing out my 
additional two cents here.

> The thing I don’t like about this is that the delegate (my document subclass) 
> now needs to have a link to the menu items which are created in the main menu 
> nib.

That is another reason I like my later proposal.  The app delegate is in 
MainMenu.nib, so you can create outlets from it directly to the menu items.

--Andy
___

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: Setting key equivalent for menus depending on window

[Andy Lee]

Uli and I both remembered the app delegate is checked *after* the 
window-related objects in the responder chain, which is what you discovered.

I *thought* you could work around this by changing the actions of the Close 
menu items to methods that only the app delegate implements.  But you really 
don't want to do that, because it'll break any parts of the built-in menu 
validation that assume performClose: is the action for closing windows.

So I propose yet another solution, which may well be, again, flawed.  It does 
not go through validateMenuItem:.  The following may seem like a lot of 
explaining, but it is only a few one- or two-line methods.

* Have the app delegate listen for NSWindowDidBecomeMainNotification.
* Handle the notification by setting the menu item shortcuts appropriately for 
the main window.

There are different approaches you could take to set the shortcuts 
appropriately for the window.  One way would be to add two category methods on 
NSWindow, something like

+ (void)updateShortcutForCloseMenuItem:(NSMenuItem *)menuItem
{
[menuItem setKeyEquivalent:@"w"];
}

+ (void)updateShortcutForCloseTabMenuItem:(NSMenuItem *)menuItem
{
[menuItem setKeyEquivalent:@""];
}

For your window that has tabs, use an NSWindow subclass that overrides these 
methods:

+ (void)updateShortcutForCloseMenuItem:(NSMenuItem *)menuItem
{
[menuItem setKeyEquivalent:@"W"];
}

+ (void)updateShortcutForCloseTabMenuItem:(NSMenuItem *)menuItem
{
[menuItem setKeyEquivalent:@"w"];
}

Your app delegate could have outlets to the two menu items in question.  Then 
your notification-handling method can be:

- (void)handleWindowDidBecomeMainNotification:(NSNotification *)notif
{
[[[NSApp mainWindow] class] 
updateShortcutForCloseMenuItem:_closeMenuItem];
[[[NSApp mainWindow] class] 
updateShortcutForCloseTabMenuItem:_closeTabMenuItem];
}

I think the only case this does not handle is when the very last window is 
closed.  You may or may not care what the shortcuts are, since the menu items 
will be dimmed.  If you do care, you can:

* Have the app delegate listen for NSWindowDidResignMainNotification.
* Handle the notification by first checking whether [NSApp mainWindow] is nil.  
If so (and *only* if so, for the reason Uli pointed out), set the shortcuts to 
whatever you want them to be in that case.  For example, you could do this 
(which is why I made those "update" methods class methods):

- (void)handleWindowDidResignMainNotification:(NSNotification *)notif
{
if ([NSApp mainWindow] == nil)
{
[NSWindow updateShortcutForCloseMenuItem:_closeMenuItem];
[NSWindow updateShortcutForCloseTabMenuItem:_closeTabMenuItem];
}
}

--Andy


On Oct 19, 2013, at 2:32 PM, Martin Hewitson  wrote:

> I guess I didn’t understand correctly since my app delegate does not get 
> asked to validate the Close menu item. So far the only thing that get’s asked 
> to validate this is the tabbed window object. Even the window’s delegate is 
> not asked.
> 
> The documentation states:
> 
> For document-based applications, the default responder chain for the main 
> window consists of the following responders and delegates:
>   • The main window’s first responder and the successive responder 
> objects up the view hierarchy
>   • The main window itself
>   • The window's NSWindowController object (which inherits from 
> NSResponder)
>   • The main window’s delegate.
>   • The NSDocument object (if different from the main window’s delegate)
>   • The application object, NSApp
>   • The application object's delegate
>   • The application's document controller (an NSDocumentController 
> object, which does not inherit from NSResponder)
> 
> My NSPersistentDocument subclass is the main window’s delegate.
> 
> Clearly my thinking is flawed, but where? If I want the Close menu item to 
> vary depending on the window that is key, and I have to do this with 
> validateMenuItem:, then the responder chain above seems to suggest that I 
> need to have a validateMenuItem: in each and every window in the app. I hope 
> that’s not the case….
> 
> Martin
> 
> 
> On 19 Oct 2013, at 07:28 pm, Martin Hewitson  
> wrote:
> 
>> OK, so the idea is,
>> 
>> + validateMenuItem in app delegate gets a first shot at setting the keyboard 
>> shortcuts
>> + I override validateMenuItem in my tabbed window and reset the keyboard 
>> shortcuts
>> + Other windows stick with the settings arranged by the app delegate
>> 
>> Did I understand correctly?
>> 
>> Thanks to all who replied.
>> 
>> Cheers,
>> 
>> Martin
>> 
>> 
>> On 19, Oct, 2013, at 02:46 pm, Uli Kustere

Re: Setting key equivalent for menus depending on window

[Andy Lee]

On Oct 19, 2013, at 9:04 AM, Andy Lee  wrote:
> My first thought was that the app delegate might not get a validateMenuItem: 
> message if something earlier in the responder chain handles those menu items. 
>  But you could change the actions of the menu items to something unique to 
> make sure nothing else in the responder chain handles them.

You could also change the *target* of the menu items to the app delegate 
instead of First Responder, and then it wouldn't matter what the action 
selectors are.

--Andy


___

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: Setting key equivalent for menus depending on window

[Andy Lee]

On Oct 19, 2013, at 8:46 AM, Uli Kusterer  wrote:

> 
> On 19 Oct 2013, at 14:27, Andy Lee  wrote:
>> On Oct 19, 2013, at 6:58 AM, Martin Hewitson  
>> wrote:
>>> Main Window with tabs:
>>> close (cmd-shift-w)
>>> close tab (cmd-w)
>>> 
>>> All other windows:
>>> close (cmd-w)
>>> close tab (inactive, no keyboard shortcut)
>>> 
>>> This is pretty much the way things work in Xcode. 
>>> 
>>> So, my question is, is there a smart way to do this, or do I need to 
>>> implement -validateMenuItem: on every window in the app and set the 
>>> keyboard shortcuts there?
>> 
>> Untested idea: implement windowDidBecomeKey: and windowDidResignKey: in the 
>> delegate of the window that has tabs and do the switching of shortcuts there.
> 
> Would rather recommend against this. I don’t think there’s any guarantee 
> given what gets called first, validateMenuItem: or windowDidResignKey:. You 
> might be obliterating something already set by the incoming window.

True.

> I’d recommend adding a validateMenuItem: handler in the application delegate, 
> as long as you’re aware that this won’t be called for modal panels or windows 
> that have sheets on them, but since those generally don’t enable the “Close” 
> menu item, you should be fine. At least then you’re modifying the items.

My first thought was that the app delegate might not get a validateMenuItem: 
message if something earlier in the responder chain handles those menu items.  
But you could change the actions of the menu items to something unique to make 
sure nothing else in the responder chain handles them.

--Andy


___

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: Setting key equivalent for menus depending on window

[Andy Lee]

On Oct 19, 2013, at 6:58 AM, Martin Hewitson  wrote:
> Main Window with tabs:
>   close (cmd-shift-w)
>   close tab (cmd-w)
> 
> All other windows:
>   close (cmd-w)
>   close tab (inactive, no keyboard shortcut)
> 
> This is pretty much the way things work in Xcode. 
> 
> So, my question is, is there a smart way to do this, or do I need to 
> implement -validateMenuItem: on every window in the app and set the keyboard 
> shortcuts there?

Untested idea: implement windowDidBecomeKey: and windowDidResignKey: in the 
delegate of the window that has tabs and do the switching of shortcuts there.

If you want to be extra careful you could have two ivars that remember what the 
shortcuts were before you changed them to cmd-shift-w and cmd-w.  Then in 
windowDidResignKey: plug those shortcuts in rather than hard-code cmd-w and @"".

--Andy


___

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: Cocoa class extension best practice

[Andy Lee]

On Oct 16, 2013, at 2:09 PM, Steve Mills  wrote:

> On Oct 16, 2013, at 12:45:49, Andy Lee  wrote:
> 
>> I still don't see what mutability has to do with it, but that's a side issue.
> 
> The mutability doesn't matter. I'm just emphasizing that the internal array 
> is mutable and this is returning a COPY of that array (which happens to be 
> immutable).

I see.

> 
>> I would too.
>> 
>> I suspect you can safely use the instance variable, but if you're concerned 
>> about the fact that it's undocumented, or that Apple could in theory move it 
>> to the @implementation so that it's no longer visible to your code, you can 
>> accomplish the same using numberOfItems and itemAtIndex:, as I mentioned 
>> earlier.  Then you're using totally public API *and* this particular method 
>> no longer instantiates any objects.  Either way, I'd add a clarifying 
>> comment.
> 
> That's a good point. I'm guessing the author of this code used itemArray 
> simply because it was an easy way to use the new "in" for loop mechanism.

Well, that is the most natural and concise way to do it other than directly 
accessing the ivar, which by now it should be clear, is a bad idea.  You 
probably wouldn't have given itemArray a second thought except for the memory 
issues you observed.

If I'm understanding what's been figured out so far, it seems itemArray itself 
doesn't leak.  What I'm not clear on is whether your NSMenu methods (or more 
precisely, the places where those methods are called) have anything to do with 
your memory issues, or if they are a red herring.  If you change the methods so 
they don't instantiate any objects -- heck, if they always return nil -- does 
your memory footprint still keep increasing?

Is the growing memory footprint definitely an indication of a problem, or could 
there be a cache somewhere whose *purpose* is to grow?  If memory usage is 
growing out of hand, again I'd suggest using heapshots to see what objects are 
being added to cause the footprint to increase when you weren't expecting it to.

Speaking of which, I've had a memory issue reported and should really be taking 
a look at that... For some reason my bugs are boring while other people's are 
interesting. :)

--Andy



___

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: Cocoa class extension best practice

[Andy Lee]

On Oct 16, 2013, at 1:38 PM, Charles Srstka  wrote:
> On Oct 16, 2013, at 11:57 AM, Steve Mills  wrote:
> 
>> So at this point, let's finish this thread by going back to my original 
>> question. Is it OK to use the private instance variable _itemArray in NSMenu 
>> since the methods we've added are *extensions* of NSMenu and not a subclass?
> 
> I wouldn't. If, in some OS update, Apple changes the NSMenu class such that 
> the _itemArray ivar is no longer being used, your app would blow up horribly. 
> Also, if Apple starts doing something like lazily populating that array or 
> otherwise updating it at the time you ask for it, that won't get done if you 
> access the ivar directly.

Great points.  I withdraw my "probably safe" comment.  Why take a chance?

As for the creeping memory footprint, maybe try Heapshot Analysis to see what 
objects are being created during particular intervals?

--Andy


___

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: Cocoa class extension best practice

[Andy Lee]

On Oct 16, 2013, at 12:57 PM, Steve Mills  wrote:

> So at this point, let's finish this thread by going back to my original 
> question. Is it OK to use the private instance variable _itemArray in NSMenu 
> since the methods we've added are *extensions* of NSMenu and not a subclass? 
> They simply iterate over the array and ask each item for its tag and call the 
> same method on submenus. Below is the way it is now, with [self itemArray] 
> being called, which seems inefficient because it creates an immutable copy of 
> the array.

I still don't see what mutability has to do with it, but that's a side issue.

> If NSMenu were my own class, I'd definitely use the instance variable for 
> this sort of routine.

I would too.

I suspect you can safely use the instance variable, but if you're concerned 
about the fact that it's undocumented, or that Apple could in theory move it to 
the @implementation so that it's no longer visible to your code, you can 
accomplish the same using numberOfItems and itemAtIndex:, as I mentioned 
earlier.  Then you're using totally public API *and* this particular method no 
longer instantiates any objects.  Either way, I'd add a clarifying comment.

--Andy

> 
> - (NSMenuItem*)itemWithTag:(NSInteger)tag searchSubmenus:(BOOL)searchSubmenus 
> depthFirst:(BOOL)depthFirst
> {
>if(!depthFirst) {
>id item = [self itemWithTag:tag];
> 
>if(item)
>return item;
>}
> 
>if(searchSubmenus) {
>for(NSMenuItem* item in [self itemArray]) {
>if([item hasSubmenu]) {
>NSMenuItem*subitem = [[item submenu] 
> itemWithTag:tag searchSubmenus:searchSubmenus depthFirst:depthFirst];
> 
>if(subitem)
>return subitem;
>}
>}
>}
> 
>return [self itemWithTag:tag];
> }




___

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: Cocoa class extension best practice

[Andy Lee]

On Oct 15, 2013, at 6:22 PM, Graham Cox  wrote:

> 
> On 15/10/2013, at 11:10 PM, "Mills, Steve"  wrote:
> 
>> No, it's the itemArray. Ignore the code you can't see in the loop. It's 
>> simply asking each item for its tag.
> 
> 
> OK, so if that's the case, I'm interested in knowing whether each call to 
> -itemArray returns the same object or a different one each time.

In my tests I NSLog them and they're different every time.  BTW I repeated my 
test on 10.8.5.  The project does not use ARC and Leaks does not show leaks 
after I call itemArray thousands of times in response to button presses.  
Allocations go up and come back down as they should.

> If it's different, then it's either a copy of some internal array or 
> something built on the fly. It should therefore be autoreleased. If your 
> (incorrect, but understandable) attempt to call -release causes a crash, then 
> it definitely is being (over)released at some point, so it can't be leaking 
> as long as there really is an autorelease pool in place. So that might lead 
> you to look at how and where these methods are being called, e.g. sure 
> they're on the main thread, within a runloop event handler of some sort?

As a sort of test probe you could create some other object that should 
definitely *not* leak, and see if it does.  Next to the call to itemArray, 
something like

NSArray*items = [self itemArray];

for(NSMenuItem* item in items)
blah;

for (NSInteger i = 0; i < 1; i++)
[[[NSObject alloc] init] autorelease];

If you leak thousands of NSObject instances, you know it's not a problem 
specific to itemArray.  More likely it has to do with the questions Graham 
posed about when your method is getting called.

--Andy


___

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: Cocoa class extension best practice

[Andy Lee]

On Oct 15, 2013, at 4:30 PM, Steve Mills  wrote:
> On Oct 15, 2013, at 14:50:51, Steve Mills  wrote:
> 
>>  NSArray*items = [self itemArray];
>>  
>>  for(NSMenuItem* item in items)
>>  blah;
>>  
>>  [items release];
> 
> 
> Ah, this one won't work (I didn't try it before when I wrote my original 
> message) because itemArray actually does return a new *immutable* array,

itemArray is declared to return an NSArray, so you should treat it as immutable 
whether or not it happens to return a mutable array.  In any case, its 
mutability has nothing to do with whether itemArray is leaking.

> but it's not release-able. Doing so produces a crash.

This would be expected if itemArray isn't really leaking.  FWIW, I did a quick 
test, calling itemArray hundreds of times, and Leaks didn't report any leaks.  
Is it possible the arrays you are leaking are elsewhere?  I'm running 10.9, so 
if you're running an earlier OS it's also possible there was a leak and Apple 
fixed it.

--Andy


___

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: Cocoa class extension best practice

[Andy Lee]

On Oct 15, 2013, at 5:05 PM, Andy Lee  wrote:
> Then instead of [self itemArray] you could use [self nonLeakingItemArray].

If you are indeed subclassing, even better would be to override itemArray to 
return [self nonLeakingItemArray].  Then you can use [self itemArray] 
everywhere else and the code looks "normal".

--Andy



___

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: Cocoa class extension best practice

[Andy Lee]

On Oct 15, 2013, at 3:50 PM, Steve Mills  wrote:
> We have extended NSMenu so we could add some other methods. Many of the 
> methods iterate over the itemArray like so:
> 
>   for(NSMenuItem* item in [self itemArray])
> 
> Instruments shows that we're leaking NSArrays created when itemArray returns.

I would submit a bug report to Apple that itemArray leaks its return value.  
Should be easy to demonstrate with a tiny example app.  I'm curious to verify 
the leak myself, but laziness is currently winning over curiosity. :)  Not that 
I don't trust you, I just like to see for myself.

> I assume whoever wrote these methods was assuming that itemArray would simply 
> return the internal NSArray and not make a copy. I guess I would make the 
> same assumption since it's not a copy* method.

No assumption should be made about the implementation of itemArray, including 
whether it returns an internal value or makes a copy.  When you're using manual 
retain/release, the memory management rules only say that you do not own the 
returned value and should not release it.  At most you can say that itemArray 
is violating the rules by under-releasing the returned object.

> So my question is, what's the best way to write extension methods on an 
> existing Cocoa class like this?

This question isn't really about class extensions.  The issues apply to any 
code that calls itemArray, given that as far as you can tell, it leaks.

Out of curiosity, when you say you have "extended" NSMenu, do you mean you've 
subclassed it?  That is what I would infer from your mention of class 
extensions.  Is there some reason you don't add a category instead?  I wonder 
because you only mentioned adding methods, not overriding them or adding ivars.

> One way would be to assign the itemArray result to a local variable and 
> release it when done (ARC is not turned on in this project yet):
> 
>   NSArray*items = [self itemArray];
>   
>   for(NSMenuItem* item in items)
>   blah;
>   
>   [items release];

Even if this worked (you mention that it didn't), it's not good to fix a memory 
management problem by breaking the rules.  Besides trying to make two wrongs 
into a right, what happens when Apple fixes itemArray?  Then you'd be 
over-releasing.

> Thoughts?

Assuming itemArray is definitely leaking, you're stuck choosing a workaround.  
One possibility is to go through different methods that (hopefully) don't leak:

NSInteger numItems = [self numberOfItems];
for (NSInteger itemIndex = 0; itemIndex < numItems; itemIndex++)
{
NSMenuItem *item = [self itemAtIndex:itemIndex];
// blah
}

You could also use the above logic to implement a non-leaking version of 
itemArray in a category or class extension:

- (NSArray *)nonLeakingItemArray
{
NSMutableArray *itemArray = [NSMutableArray array];
NSInteger numItems = [self numberOfItems];

for (NSInteger itemIndex = 0; itemIndex < numItems; itemIndex++)
{
[itemArray addObject:[self itemAtIndex:itemIndex]];
}

return itemArray;
}

Then instead of [self itemArray] you could use [self nonLeakingItemArray].  I 
would guess the cost of constructing the array yourself is totally negligible, 
but only you can know for sure by trying it.

--Andy


___

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: ARC vs Manual Reference Counting

[Andy Lee]

On Sep 11, 2013, at 6:37 AM, Jean-Daniel Dupas  wrote:
>>> and that while in most code those would be lost in the noise, in some cases 
>>> people would need to help ARC out with things like __unsafe_unretained.
>> 
>> Hmm…I always thought that __unsafe_unretained was for instance variables, 
>> but given what you just wrote, I guess it could be used for normal automatic 
>> variables to opt them out of ARC? 
>> 
> 
> Yes. it works to disable ARC for arguments and other local variables.

And you can put __unsafe_unretained objects in struct declarations, if you feel 
you must, and ARC won't complain.

--Andy


___

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: "Provide Feedback" on documentation pages is broken

[Andy Lee]

I was in the Mac OS section.  I tested on another page (NSObject) and that 
failed too.  I wonder if the whole Provide Feedback mechanism is still broken, 
or perhaps not yet re-enabled, after the recent dev portal shutdown.

If it isn't fixed soon I'll just submit a documentation Radar.

--Andy

On Aug 14, 2013, at 10:27 PM, Alex Zavatone  wrote:

> Same thing happened to me yesterday trying to add a note to update the iOS 
> Reachability example to ARC.
> 
> Were you in the iOS section, the Mac OS section or another section of the doc 
> pages? 
> 
> Do you think that all the Provide Feedback links might be broken like this?
> 
> On Aug 14, 2013, at 10:20 AM, Andy Lee wrote:
> 
>> I tried using the "Provide Feedback" link on one of the dev doc pages and 
>> got this:
>> 
>> <http://twitpic.com/d89x06>
>> 
>> I filed a Radar about it: #14735067, in case anyone wants to dupe it, 
>> assuming it's not just me.
>> 
>> --Andy

___

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

"Provide Feedback" on documentation pages is broken

[Andy Lee]

I tried using the "Provide Feedback" link on one of the dev doc pages and got 
this:



I filed a Radar about it: #14735067, in case anyone wants to dupe it, assuming 
it's not just me.

--Andy


___

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: Mixing Obj-C and C "methods"

[Andy Lee]

On Aug 7, 2013, at 12:04 PM, Jean-Daniel Dupas  wrote:
> If you intend to use it from multiple threads, so use a tls.
> 
> __thread id myCallbackHandler;

I did not know about __thread, thanks for this.  By using tls you're 
effectively having each thread store the info that would have been stored by 
the implementation of the callback's context pointer, if it had one.

If [x foo] and [y foo] are called in the same thread, then that thread's 
myCallbackHandler can still get clobbered if the callback is asynchronous.  So 
I guess you'd have to be careful to always call -foo in a separate thread, or 
implement it to always spawn a thread.

> I was talking about the case where you have to deal with a poorly design API 
> with no context pointer argument.
> The case with a context argument should off course be handle the way you 
> describe.

I see, thanks.

--Andy


___

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: Mixing Obj-C and C "methods"

[Andy Lee]

On Aug 7, 2013, at 3:47 AM, Jean-Daniel Dupas  wrote:
> Instead of trying to use complex approach to hide the fact you need a global, 
> just use one, and don't try to reuse the existing one for things there are 
> not designed to do.
> 
> 
> static id myCallbackHandler;
> 
> void someCallBack() {
>   [myCallbackHandler handleCallBack];
> }
> 
> - (void)foo {
>   myCallbackHandler = self;
>   callCFunctionWithCallBack(someCallBack);
>   myCallbackHandler = nil;
> }

What if instance x does [x foo], and before someCallBack() gets called, some 
other instance y does [y foo]?  There will be two future calls to 
someCallBack(), and [y handleCallBack] will be called both times, which is not 
the desired outcome.  This is a problem with any approach where the callback 
looks in some global place, whether it's a static variable, a key path from the 
app delegate, or whatever.

Even if you are sure you won't run into the problem of the global variable 
being overwritten, I think routing self through a global like myCallbackHandler 
is more complex than:

void someCallBack(void *contextPtr) {
[[(MyClass *)contextPtr autorelease] handleCallBack];
}

- (void)foo {
callCFunctionWithCallBack(someCallBack, (void *)[self retain]);
}

or with ARC:

void someCallBack(void *contextPtr) {
[(__bridge_retained MyClass *)contextPtr handleCallBack];
}

- (void)foo {
callCFunctionWithCallBack(someCallBack, (__bridge_transfer void *)self);
}

This assumes that the API includes a context pointer, but realistically, how 
often won't that be the case?  (I don't actually know.)

--Andy

> 
> 
> Le 30 juil. 2013 à 15:44, Maxthon Chan  a écrit :
> 
>> My common way of handling this would be NSNotificationCenter. It is a 
>> singleton so I am always sure that it is there, and I can wrap all 
>> parameters into the userInfo dictionary.
>> 
>> Sent from my iPhone
>> 
>>> On 2013年7月30日, at 21:19, KappA  wrote:
>>> 
>>> I sometimes just access my objc-objects from a C thread-proc via the
>>> AppDelegate (providing there's a trail to the object I need, which there
>>> usually is)... If the callback void pointer parameter isn't being used for
>>> something else, you can simply cast the object in there... or if you need
>>> multiple parameters you can create a struct that stores what you need and
>>> pass that. Not sure if this helps but figured I'd mention it.
>>> 
>>> AppDelegate *d = [[UIApplication sharedApplication] delegate];
>>> 
>>> 
>>> 
 On Tue, Jul 30, 2013 at 8:53 AM, lowell  wrote:
 
 The first two parameters to the function have to be an id and a SEL ...
 
  typedef id (*IMP)(id, SEL, ...);
 
 ... (this is where we get self and _cmd, by the way) followed by the rest
 of the method params, if any.
 
 
 lowell
 
 
> On Jul 30, 2013, at 12:59 AM, Vincent Habchi  wrote:
> 
> Hi everybody,
> 
> I have a very simple question: if I embed a C-function (more precisely,
 a callback from an external C-library) in an Obj-C object, can I expect
 this function to behave like a regular method? I.e. can it freely access
 ‘self’ and other attributes?
> 
> Thanks a lot!
> 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: Mixing Obj-C and C "methods"

[Andy Lee]

On Jul 30, 2013, at 5:29 PM, Michael Crawford  wrote:
> That class object occupies a
> non-zero quantity of memory, at its lowest level being somewhat like
> the combination of a single copy of a C struct, as well as some C
> functions, that from the Objective-C point of view, appear to be
> "class methods" that know all about their "class object",

Both class methods and instance methods are indeed C functions (IMPs).  But to 
clarify, it isn't that class methods "know" about their owning class in the 
sense one might imagine, with some sort of back-pointer.  It's that at the time 
a class method is invoked, a class pointer is passed to the function as an 
implicit argument named "self", and *that's* how the function knows the class 
on whose behalf it is executing.  It's a subtle distinction, but an important 
one.

One reason it's important is that you could have a subclass and it could invoke 
the same class method:

[MyClass myClassMethod];
[MySubclass myClassMethod];  // Assume MySubclass does not override the method.

The value of "self" will be different in the two cases at the time that method 
executes.  In each case, "self" is the receiver of the message.

Similarly, at the time an instance method is invoked, an instance pointer is 
passed to the function that constitutes the implementation of the method, again 
as an implicit argument named "self".

> but that are
> not capable of (directly) operating on instances.

All functions, whether pure C functions or Objective-C methods, are capable of 
directly operating on instances.  They can instantiate objects, message them, 
and depending on scope, they can directly access their ivars.

The distinction you may be getting at is that only Objective-C instance methods 
can directly access ivars without having to qualify them with "self->", because 
the "self" is implicit.

--Andy


___

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: Mixing Obj-C and C "methods"

[Andy Lee]

On Jul 30, 2013, at 11:25 AM, Scott Ribe  wrote:
> On Jul 30, 2013, at 9:08 AM, Andy Lee  wrote:
> 
>> I think it's subject to the same criticisms as *any* direct access to ivars, 
>> although I agree it feels sketchier when done in plain C for some reason.
> 
> Yes. Because what is the point of plain C functions in Objective-C files? 
> Local helpers that are not OOP, and do not go through method dispatch 
> overhead. To turn around and inject direct access to ivars in those is really 
> mixing metaphors.

One reason people might directly access ivars applies to methods as well as 
functions: the class may not have a getter method for that ivar.  Now, there is 
a school of thought that says ivars should *always* be accessed via a getter 
method, except in init and dealloc, and if necessary a "private" getter should 
be added.  If one does not subscribe to that school of thought, and accesses 
ivars directly in methods, I personally don't think it's a *huge* deal to do so 
in functions, especially since the function has to be inside the 
@implementation section and it won't be a commonplace thing.  But as always, 
I'm happy to code to the accepted norms of whatever team I'm on.

>> Which reminds me... instance methods can also directly access the ivars of 
>> *other* instances of the same class.
> 
> Now, *that* I knew. I'm sorry senator, I cannot recall if I ever did such a 
> thing. But I knew it was possible ;-)

So noted, and we thank you for your testimony today. :)

--Andy


___

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: Mixing Obj-C and C "methods"

[Andy Lee]

On Jul 30, 2013, at 4:26 AM, Michael Crawford  wrote:
> However, I expect there is a way you could call an Objective-C method
> from vanilla C.  Possibly you will need some assembly-language glue.

The nice thing is, you don't need glue.  You can send Objective-C messages from 
within C, as long as the code is compiled as Objective-C or Objective-C++.  All 
you need is...

> You will need some way for your C callback to be told what "self" is.

...bearing in mind that within the C function it doesn't have to be called 
"self".  It *can* be, if that makes things clearer, but as Jean-Daniel 
mentioned, "self" has no special meaning within a C function.  Depending on the 
situation, "self" might be a *more* confusing name; personally, I would use 
something else in most if not all cases but that may be a matter of taste.

Whether you use the name "self" or not, you can't refer to ivars in a C 
function without a qualifier:

@implementation MyClass

- (void)myMethod
{
NSLog(@"%@", _myIvar);  // okay because of implicit "self"
}

void myFunction(MyClass *self)
{
NSLog(@"%@", _myIvar);  // compile error
NSLog(@"%@", self->_myIvar);  // compiles okay
NSLog(@"%@", self.myIvar);  // compiles okay if there is a myIvar property
[self myMethod];  // compiles okay
}

@end

--Andy


___

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: Mixing Obj-C and C "methods"

[Andy Lee]

On Jul 30, 2013, at 10:42 AM, Scott Ribe  wrote:
> On Jul 30, 2013, at 8:35 AM, Andy Lee  wrote:
> 
>> The only effect, as others have explained, is on scope; if you put the 
>> function inside the @implementation and the function has a reference to an 
>> instance of MyClass, then it can use myObj->myIvar for direct access to 
>> instance variables.
> 
> Interesting, did not know that. Not sure I'll ever need it… Plain C is one 
> thing, plain C but with direct access to instance vars?

I think it's subject to the same criticisms as *any* direct access to ivars, 
although I agree it feels sketchier when done in plain C for some reason.

Which reminds me... instance methods can also directly access the ivars of 
*other* instances of the same class.

- (void)myMethod
{
MyClass *otherInstance = [[MyClass alloc] init];

NSLog(@"%@", otherInstance->myIvar);
}

--Andy


___

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: Mixing Obj-C and C "methods"

[Andy Lee]

On Jul 30, 2013, at 4:27 AM, Vincent Habchi  wrote:
> Yes, right; it’s a SQLite callback, the first parameter is a void *. I wanted 
> to pass a pointer to a structure containing both a unique query id (out of 
> uuid) and a pointer to self, but got told off by ARC because it apparently 
> forbids to embed pointers to Obj-C objects in C-structs. So I just 
> bridge-cast it to void *.

A couple of alternatives, just for your consideration in case they hadn't 
occurred to you.

One alternative would be to use __unsafe_unretained.  ARC allows structs like 
this:

typedef struct _MyStruct {
__unsafe_unretained id myObj;
} MyStruct;

So you'd be able to access the myObj member of the struct without having to 
cast.  But you'd have to make sure myObj doesn't get dealloc'ed before the 
struct is used (i.e., before the callback is invoked), so maybe you wouldn't be 
doing any less work code-wise.

Apple's recommended alternative to having a struct contain an object is to use 
a class instead of a struct.  You could create a MyCallbackInfo class with two 
properties: the query id and the pointer to self.  You'd still have to 
bridge-cast *that* object when passing it to the callback.

--Andy


___

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: Mixing Obj-C and C "methods"

[Andy Lee]

On Jul 30, 2013, at 4:19 AM, Rick Mann  wrote:
> On Jul 30, 2013, at 00:59 , Vincent Habchi  wrote:
> 
>> I have a very simple question: if I embed a C-function (more precisely, a 
>> callback from an external C-library) in an Obj-C object, can I expect this 
>> function to behave like a regular method? I.e. can it freely access ‘self’ 
>> and other attributes?
> 
> No; it'll be a stand-alone method with no implicit knowledge of the 
> Objective-C class.

This may be pedantic, but just to clarify: if you put a C function in MyClass's 
implementation file you aren't really "embedding" it in the sense that some 
people might think you mean.  There is no formal association between MyClass 
and the function, MyClass doesn't know about the function, and you can't call 
the function as if it were a method.  The function is not a method, stand-alone 
or otherwise.

The only effect, as others have explained, is on scope; if you put the function 
inside the @implementation and the function has a reference to an instance of 
MyClass, then it can use myObj->myIvar for direct access to instance variables.

The same is true for class methods, by the way.  If a class method has a 
reference to an instance of the class, it can directly access the instance's 
ivars the same way.

--Andy


___

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: Observing Time

[Andy Lee]

On Jul 27, 2013, at 11:05 PM, Scott Ribe  wrote:

> On Jul 27, 2013, at 7:57 PM, Andy Lee  wrote:
> 
>> I'm trying again, this time creating a new NSTimer each time as suggested by 
>> Scott Ribe.  Will let it run a while and see if I notice any drift.
> 
> FYI, I think that's fine. You could also take the approach of using a single 
> timer, and using setFireTime every time. (You'd set the repeat interval to 
> something unrealistically large, say a minute or hour, then always use 
> setFireTime to set when the next instance will be.)

Yup.

--Andy


___

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: Observing Time

[Andy Lee]

On Jul 27, 2013, at 9:57 PM, Andy Lee  wrote:
> I'm trying again, this time creating a new NSTimer each time as suggested by 
> Scott Ribe.  Will let it run a while and see if I notice any drift.

Looks pretty solid after several minutes -- as I would expect.  To repeat 
Scott's suggestion:

> Personally, I'd probably just do a non-repeating timer, set to fire at the 
> next second roll-over. Alloc'ing, scheduling and releasing 1 timer per second 
> is not a lot of overhead.

I didn't take my own suggestion to add .001 and it worked fine, though for all 
I know it might have a problem once every 10,000 times the app is run.

I stole Rick Mann's code and replaced trunc() with round().

--Andy

==

@implementation AppDelegate

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
[self _resetTimer];
}

- (void)_resetTimer
{
CFAbsoluteTime fireDateAbs = round(CFAbsoluteTimeGetCurrent() + 0.5);  // 
Round to the next second
NSDate *fireDate = [NSDate 
dateWithTimeIntervalSinceReferenceDate:fireDateAbs];

[[self timer] invalidate];
[self setTimer:[[NSTimer alloc] initWithFireDate:fireDate
interval:1.0
  target:self
selector:@selector(_timerDidFire:)
userInfo:nil
 repeats:NO]];
[[NSRunLoop currentRunLoop] addTimer:[self timer] 
forMode:NSRunLoopCommonModes];
}

- (void)_timerDidFire:(NSTimer *)theTimer
{
[self _updateTimeDisplay];
[self _resetTimer];
}

- (void)_updateTimeDisplay
{
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];

[dateFormatter setTimeStyle:NSDateFormatterMediumStyle];
[dateFormatter setDateStyle:NSDateFormatterNoStyle];

NSString *timeString = [dateFormatter stringFromDate:[NSDate date]];

[[self textField] setStringValue:timeString];
}

@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: Observing Time

[Andy Lee]

On Jul 27, 2013, at 9:43 PM, dangerwillrobinsondan...@gmail.com wrote:
> But with that I still see a faint lag that seems to update just a hair slower 
> than the dispatch timer. Noticeable to me at least, I'll post a link to the 
> sample projects in a bit. 

FWIW I created a quick test app using NSTimer and didn't notice any lag at 
first but there was noticeable drift after a while -- not huge, but noticeable. 
 This makes me suspicious of the docs that Steve Sisak quoted earlier, which I 
was counting on:

> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSTimer_Class/Reference/NSTimer.html
> 
>> A repeating timer always schedules itself based on the scheduled firing 
>> time, as opposed to the actual firing time.

I'm trying again, this time creating a new NSTimer each time as suggested by 
Scott Ribe.  Will let it run a while and see if I notice any drift.

--Andy


___

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: Observing Time

[Andy Lee]

On Jul 27, 2013, at 7:53 PM, dangerwillrobinsondan...@gmail.com wrote:
> I just tried both approaches and guess which one stays right there with the 
> menu bar clock and which one lags?
> dispatch timer is the winner. 
> And it's not doing a lot. 
> 
> I built a test app for each approach to verify.

Is it possible there's a difference in how you're doing the math in the two 
cases, such that the NSTimer case might be firing *early* rather than late?  
Say the first NSTimer fires a little before the time you intended -- for 
example, it fires at 00:36. instead of 00:37.  Your UI will not get around 
to displaying the 37 until possibly a whole second later, depending on how you 
set up the firing of the next timer.

If I were using an NSTimer approach I might set it to fire at .001 past the 
second just to be sure I don't get caught by rounding error in my 
floating-point math.

--Andy


___

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: view based NSTable View - button not firing

[Andy Lee]

This sounds familiar.  I remember something wasn't working in a view-based 
table and I was baffled until I read somewhere that I needed to set its 
delegate.  Usually I make a note to myself about stuff like this, but I can't 
find the exact link that led me to this discovery.  Perhaps one of these:





It may be worth filing a documentation bug if not an actual API bug.

--Andy

On Jul 24, 2013, at 1:16 AM, Abdul Sowayan  wrote:

> Hi Kyle,
> 
> I actually did use NSTableCellView. My button didn't work until I hooked up 
> the delegate outlet. 
> 
> Abdul
> 
> Sent from my iPhone
> 
>> On Jul 24, 2013, at 1:14 AM, "Kyle Sluder"  wrote:
>> 
>>> On Tue, Jul 23, 2013, at 12:42 PM, Keary Suska wrote:
>>> 
>>> I didn't look at the attachment but is the button the "root" view for the
>>> cell, or is it a subview? I ask as I have encountered that even when you
>>> set up a table view as view-based that it will still behave in strange
>>> ways as if it were cell-based whenever a cell's root view has an NSCell
>>> that is acceptable in a cell-based table view, such as text fields and
>>> buttons. If this is the case, the solution is to embed your button in an
>>> NSView.
>> 
>> Wouldn't it be better to use an NSTableCellView instead of a plain
>> NSView?
>> 
>> --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/aglee%40mac.com
> 
> This email sent to ag...@mac.com


___

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

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

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

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

[MEET] CocoaHeadsNYC this Thursday

[Andy Lee]

When: Thursday, July 11, 2013, 6:30-7:45PM, followed by dinner at Spice, at 8th 
and 22nd (*not* the other Spice nearby).
What: Our guest Michele Titolo has kindly volunteered to give a talk entitled 
"Mastering the Project File":

Do you frequently hear yourself say "Don't touch the project file!", "Who 
overrode my changes?" or "Where did my file go?" If so, this talk is for you. 
We constantly put the project file on a pedestal of 
things-you-do-not-mess-with, but is this much caution really warranted? We'll 
cover tips, tricks, and solutions to promote harmony between you and your 
project file.

Where: Google, 76 9th Ave, New York, NY 10011

For details and directions, see .

--Andy

___

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: The cost of using objects rather than plain C variables

[Andy Lee]

On Jul 8, 2013, at 12:30 PM, Vincent Habchi  wrote:

> On 8 juil. 2013, at 18:04, Jens Alfke  wrote:
>> On Jul 7, 2013, at 1:37 PM, Frederick Bartram  wrote:
>> 
>>> Have you tried using NSData to store C-arrays?
> 
> No, since my initial problem was to be able to extend the buffer as the 
> number of primitive read grew. NSData would not do that.

NSData wouldn't let you, but NSMutableData would, with methods like 
appendBytes:length:, appendData:, increaseLengthBy:, etc.  The underlying 
buffer might have to move around if it cannot be extended in place, just as it 
would if you use C realloc() calls.

--Andy


___

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: The cost of using objects rather than plain C variables

[Andy Lee]

On Jul 8, 2013, at 1:08 PM, Boyd Collier  wrote:
> Your suggestion sounded worth learning about, but it appears that there's no 
> such creature as NSPointerValue.   

I'm guessing Jens meant +[NSValue valueWithPointer:].

> Did you perhaps mean NSPointerArray?

I'm guessing not, since NSPointerArray is for containing an array of objects 
(like NSArray does), not scalars.

--Andy


___

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: redo: action not in First Responder

[Andy Lee]

On Jul 2, 2013, at 1:53 PM, Steve Mills  wrote:

> On Jul 2, 2013, at 12:10:22, Quincey Morris 
>  wrote:
> 
>> There is a button, but it's obvious only after you know where it is.
>> 
>> Select the First Responder item in the list of XIB components on the left of 
>> the editing pane. Display the Attributes inspector in the pane at the right 
>> of the window, and you'll see a list of custom actions to which you can add 
>> actions.
> 
> Ah, thanks. One usually finds that sort of thing in the same pane that the 
> actual list resides. *grumble*

I clearly need to read up on undo management, but purely based on experience 
with the rest of IB, I find it odd that the default Undo and Redo menu items 
have actions that are not publicly declared -- at least undo: and redo: are not 
in NSResponder.h, NSObject.h, or in the documentation.  Those actions are not 
listed in the Attributes inspector of the default MainMenu.xib, so it seems 
like *some* sort of special-casing is going on behind the scenes.

I notice there is a little yellow triangle next to the redo: action, but not 
the undo:, which again strikes me as odd.

I would have guessed you could copy and paste the Undo menu item from some 
other project, but that didn't work for me.  The pasted menu item had no target 
or action.

In any case, you have it working now.

--Andy



___

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: Attributed strings in NSTableViews

[Andy Lee]

On Jun 30, 2013, at 2:44 PM, Kyle Sluder  wrote:

> On Jun 30, 2013, at 6:04 AM, Peter Hudson  wrote:
> 
>> 
>> I then append a second attributed string to the first - with very similar 
>> attributes as the first.
>> After this, when the row is selected, the system no longer reverses out the 
>> text color as it did previously.
> 
> Text drawing will only reverse the colors of text if the entire string is 
> drawn in NSControlTextColor. (I've filed a Radar on this opaque, 
> undocumented, uncustomizable behavior.)

I ran into similar stubbornness when trying to use a custom color for the title 
of an NSButton when it is disabled.  My workaround, based on an answer I found 
on StackOverflow, was to override the cell's drawTitle:withFrame:inView: method.

.m: 


.h: 


Maybe the same technique would work for you.  You'd have to figure out how to 
reverse the color yourself, but at least you'd have complete control over the 
string's appearance.

--Andy


___

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: NSSplitView similar to Xcode's editor/debug area split view

[Andy Lee]

Hi Chuck,

On Jun 26, 2013, at 8:30 PM, Chuck Soper  wrote:
> 2. How should I animate the showing or hiding of the 'debug area' view?

I do by sending setFrame: to the two subviews' animator proxies instead of to 
the view itself.

// Assumes the split view has two subviews, one above the other.
- (void)_setTopSubviewHeight:(CGFloat)newHeight
 forTwoPaneSplitView:(NSSplitView *)splitView
 animate:(BOOL)shouldAnimate
{
NSView *viewOne = [[splitView subviews] objectAtIndex:0];
NSRect frameOne = [viewOne frame];
NSView *viewTwo = [[splitView subviews] objectAtIndex:1];
NSRect frameTwo = [viewTwo frame];

frameOne.size.height = newHeight;
frameTwo.size.height = ([splitView bounds].size.height
- [splitView dividerThickness]
- newHeight);
if (shouldAnimate)
{
[NSAnimationContext beginGrouping];
[[NSAnimationContext currentContext] setDuration:0.1];
{{
[[viewOne animator] setFrame:frameOne];
[[viewTwo animator] setFrame:frameTwo];
}}
[NSAnimationContext endGrouping];
}
else
{
[viewOne setFrame:frameOne];
[viewTwo setFrame:frameTwo];
}
}

There may be a better way, but this seems to work.

--Andy


___

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: Changing Subview Order Prevents Dragging

[Andy Lee]

On May 14, 2013, at 1:16 AM, Andy Lee  wrote:
> I fiddled a bit with it, adding calls that don't take arguments like [self 
> description] and [self self]. There was no dealloc until just before the 
> method exited, after those calls. It *seems* that merely referring to self, 
> whether as receiver or argument, keeps it alive. However, I might just have 
> been lucky.

Or, as was suggested, something else might well have been retaining self.

--Andy



___

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: Changing Subview Order Prevents Dragging

[Andy Lee]

On May 14, 2013, at 12:53 AM, Roland King  wrote:
[...]
>> - (void) mouseDown: (NSEvent*) event
>> {
>>NSView* superView = [self superview];
>>[self removeFromSuperview];
>> //[superView addSubview: self];
>> }
>> 
>> ...then dealloc does in fact get called. But if I uncomment that one line, 
>> which references self, dealloc does not get called. This is good news -- I 
>> would want ARC to work regardless of whether it calls non-ARC code, and vice 
>> versa.
>> 
> 
> well you have several lines in there which reference self, [ self superview ] 
> and [ self removeFromSuperview ].

I was thinking that if calling [self removeFromSuperview] removed the last 
reference to self, dealloc would have been called in both cases. Naturally I 
wouldn't expect self to have been dealloc'ed before that statement.

> The only difference in the last one is that self is used as a parameter to a 
> call to another object and that may possibly be the difference.

I fiddled a bit with it, adding calls that don't take arguments like [self 
description] and [self self]. There was no dealloc until just before the method 
exited, after those calls. It *seems* that merely referring to self, whether as 
receiver or argument, keeps it alive. However, I might just have been lucky.

> And the LLVM documents talk about this, they say that self is not retained 
> during a method call. 
> 
> http://clang.llvm.org/docs/AutomaticReferenceCounting.html#self
> 
> and discuss exactly this risk.

Thanks. Just goes to show it's dangerous to guess too much -- in my case, that 
self is a strong reference -- from too little evidence.

--Andy


___

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