I have this code:
NSMethodSignature *ms = [ self methodSignatureForSelector:
@selector(someMethod:) ];
NSInvocation *inv = [NSInvocation invocationWithMethodSignature: ms ];
[ inv retainArguments ];
[ inv setSelector: @selector(someMethod:) ];
[ inv setTarget: self ];
[ inv setArgument: &a atInd
Hi all,
I've searched the web, but can't seem to find any concrete information on
how fast enumeration loops manage temporarily created objects.
Would anybody be able to shine some light on whether fast enumeration
itself takes care of the objects it creates?
So, for example in:
for (id anObject
Another one on the underlying nature of the compiler and Objective-C for
you here!
I'm interested in how clever the compiler is at deciding where to create
variables etc. in the code, and whether it's more efficient (OK, it'll be
negligible) to declare variables only when they're needed for example
There are no temporary objects created during fast enumeration, you just get a
reference to one of the objects in the thing you are enumerating.
[ array objectAtIndex:i ] doesn't create temporaries either.
On Apr 16, 2012, at 5:42 PM, Patrick Robertson wrote:
> Hi all,
>
> I've searched the
> [ array objectAtIndex:i ] doesn't create temporaries either.
OK, then that blew my logic right out of the water!
Thanks for clearing things up Roland :)
On 16 April 2012 10:53, Roland King wrote:
> There are no temporary objects created during fast enumeration, you just
> get a reference to
On 16 Apr 2012, at 10:07, Gerriet M. Denkmann wrote:
> I have this code:
>
> NSMethodSignature *ms = [ self methodSignatureForSelector:
> @selector(someMethod:) ];
> NSInvocation *inv = [NSInvocation invocationWithMethodSignature: ms ];
> [ inv retainArguments ];
> [ inv setSelector: @selector(
On Apr 16, 2012, at 11:48 AM, Patrick Robertson wrote:
> Another one on the underlying nature of the compiler and Objective-C for
> you here!
> I'm interested in how clever the compiler is at deciding where to create
> variables etc. in the code, and whether it's more efficient (OK, it'll be
> ne
When I have a menu item which needs to be disabled based on current conditions,
I implement -menuNeedsUpdate: in its menu's delegate, grab the item by its tag,
and then -setEnabled:(YES or NO). I've been doing this for years.
Today I have a problem. If I set a particular item in the Applicatio
Is there a good reason why you're not using automatic menu enabling?
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MenuList/Articles/EnablingMenuItems.html
On 16 Apr 2012, at 13:27, Jerry Krinock wrote:
> When I have a menu item which needs to be disabled based on curre
On 2012 Apr 16, at 07:02, Mike Abdullah wrote:
> Is there a good reason why you're not using automatic menu enabling?
Thank you Mike, that explains it. I *am* using Automatic Menu Enabling.
Therefore, -[NSMenuItem setEnabled:] has no effect.
(More precisely, as I have found by debugging, it
Thanks for your thoughts and advice. I really thought that you might be onto
something with stack overflow page - I tried all the suggestions, cleaned my
project and tried again. Boom! Crash.
I then tried a completely new project and… No luck. Boom and crash again.
Is no one else having th
On Apr 16, 2012, at 12:33 PM, Pascal Harris wrote:
> Thanks for your thoughts and advice. I really thought that you might be onto
> something with stack overflow page - I tried all the suggestions, cleaned my
> project and tried again. Boom! Crash.
>
> I then tried a completely new project
Pascal, want me to try a build off of Xcode 4.2? If you want to post the code
somewhere, I could spare a few minutes.
On Apr 16, 2012, at 3:33 PM, Pascal Harris wrote:
> Thanks for your thoughts and advice. I really thought that you might be onto
> something with stack overflow page - I tried
On Apr 16, 2012, at 4:03 PM, Kyle Sluder wrote:
>
> On Apr 16, 2012, at 12:33 PM, Pascal Harris wrote:
>
>> Thanks for your thoughts and advice. I really thought that you might be
>> onto something with stack overflow page - I tried all the suggestions,
>> cleaned my project and tried again.
On Apr 16, 2012, at 1:24 PM, Alex Zavatone wrote:
> Out of curiosity Kyle, what might those be?
>
The gdb manual will tell you:
http://sourceware.org/gdb/current/onlinedocs/gdb/Breakpoints.html#Breakpoints
--Kyle Sluder
___
Cocoa-dev mailing list (C
The import is done in the ".m"-file of HomeTableViewController. But I just
found a fault in my sample code anyways: the ".h"-file of
HomeTableViewController should have an "@protocol NewFooController"
declaration.
Corrected sample code for HomeTableViewController.h:
#import
@protocol
On 16.04.2012, at 23:03, Florian Pilz wrote:
> The import is done in the ".m"-file of HomeTableViewController. But I just
> found a fault in my sample code anyways: the ".h"-file of
> HomeTableViewController should have an "@protocol NewFooController"
> declaration.
>
> Corrected sample code f
Hi. I'm implementing a messaging UI similar to the one found in Messages. In
that app, when you focus on the input field, the keyboard pops up, and the
input field scoots up as the keyboard comes up.
The conversation history area resizes to make room, but if you're scrolled to
the bottom, the b
Still a bit confused here. My tableview from which I want to delete
items is controlled by an NSViewController, and populated by an
NSArrayController that is again hooked up to my CoreData model. The
layout is the typical iTunes type layout, an outlineview on the left,
a tableview in the middle an
On Apr 16, 2012, at 4:09 PM, Rick Mann wrote:
Hi. I'm implementing a messaging UI similar to the one found in Messages. In
that app, when you focus on the input field, the keyboard pops up, and the
input field scoots up as the keyboard comes up.
The conversation history area resizes to make ro
On Apr 16, 2012, at 16:18 , Koen van der Drift wrote:
> Still a bit confused here. My tableview from which I want to delete
> items is controlled by an NSViewController, and populated by an
> NSArrayController that is again hooked up to my CoreData model.
Yes, that's an awkward case. Although a N
While you have had the question answered, the fact you asked it shows a
misunderstanding about memory management.
How fast enumeration is implemented should not make any difference to you, as
its user. If it did create temporary objects then it would be responsible for
clearing them up. (But th
On Apr 16, 2012, at 16:32 , Luke Hiesterman wrote:
> You can do this by wrapping the operation in your own animation block. This
> simple code demonstrates doing it on 44 point high rows:
>
> [UIView animateWithDuration:0.3 animations:^(void) {
> [tableView beginUpdates];
>
Er, for reference, the view hierarchy is this:
http://latencyzero.com/stuff/ViewHierarchy.png
On Apr 16, 2012, at 18:16 , Rick Mann wrote:
>
> On Apr 16, 2012, at 16:32 , Luke Hiesterman wrote:
>
>> You can do this by wrapping the operation in your own animation block. This
>> simple
On Apr 16, 2012, at 8:10 PM, Graham Cox wrote:
> Memory management is really quite straightforward, and consists of a few
> rules that everything follows (the framework invariably does; your code
> should do).
If that were true, then ARC would not have been necessary.
> On 16/04/2012, at 7:4
Hi,
So I'm working on a view-based nstableview and for the first time I will be
using group rows. Any tips on how to manage the data? What I mean is normally
I can just return [dataArray count] and [dataArray objectAtIndex:row] for the
required methods and that will get the job done. But si
Hi,
I'm porting an old MOD tracker to be build able with the current xCode and
current OS X (10.7.3).
And there is a lot of calls both for updating the screen and making the sounds
in carbine.
My guess is that I have to port the code from Carbone to Cocoa. But if there
were a Carbone2CocoaGlue
Probably what you want to do is what you suggest - make an object. Other
options include an array of arrays, of dictionaries, or of nsvalue
instances containing structs. Depending on your needs. Try an object first.
On Apr 16, 2012 10:25 PM, "Rick C." wrote:
>
> Hi,
>
> So I'm working on a view-ba
A thanks, that explains a lot. I'm just a bit confused why the compiler needs
to know the declared methods in the header file - I can't imagine a case where
a protocol method is 'used' in the header. In the implementation file it's
clear to me that the protocol must be known, however it's import
On 17/04/2012, at 12:47 PM, Dave Zarzycki wrote:
> On Apr 16, 2012, at 8:10 PM, Graham Cox wrote:
>
>> Memory management is really quite straightforward, and consists of a few
>> rules that everything follows (the framework invariably does; your code
>> should do).
>
>
> If that were true,
On 16/04/2012, at 2:27 AM, John Wilund wrote:
> Hi,
>
> I'm porting an old MOD tracker to be build able with the current xCode and
> current OS X (10.7.3).
> And there is a lot of calls both for updating the screen and making the
> sounds in carbine.
>
> My guess is that I have to port the co
On Apr 17, 2012, at 1:28 AM, Graham Cox wrote:
> …having been using Objective C productively for over 10 years now, that I
> still find ARC something I have not needed. So far. I'm kinda hoping that
> remains true, because it actually seems pretty complicated in order to cover
> all the arcane
32 matches
Mail list logo
