On 18 Jul 2011, at 01:12, Gideon King wrote:
> Hi all, in the documentation "Using Managed Objects", it says that we should
> use:
>
> [moc processPendingChanges]; // flush operations for which you want undos
> [[moc undoManager] disableUndoRegistration];
> // make changes for which undo opera
> Well, one thing that's wrong is that the tracking area is supposed to be in
> the "target" view's coordinate system,
> that is, blueView's, but you specified it in blueView's parent view's
> coordinate system.
>
> IAC, if what you want is to track the mouse when it enter's blueView, then
> mos
Hi,
Still banging my head on this one. Here's what I've done:
1- Adding a breakpoint on objc_exception_throw: brings the debugger on
NSApplicationMain...
2- I've enabled MallocStackLoggingNoCompact environment variable. After my app
crashes, I've tried
shell malloc_history 1480 0x7fff71192b
On Jul 17, 2011, at 10:32 PM, John Brownie wrote:
> [HandlerClass createHandlerWith...]
I think your model is correct, but Cocoa convention is that method names
beginning with create confer ownership to the caller. If the caller does not
need to release the object, the method name should not be
I literally mean that _exact_ snippet is leaking, 2 lines of code with no
retaining by any superviews. I only have limited experience with Cocoa and
don't use Objective C so maybe someone else could test this. Just allocate,
initialize then release the object and see if it's ever deallocated. Im
Maybe I am missing something, but given your example - which in some sense
contradicts your comment, why do you expect dealloc to be called?
If the retain count is in fact > 0 after the release (4 in your example below)
dealloc is not called, since the view can not yet be deallocated.
View.relea
Le 18 juil. 2011 à 15:26, Ryan Joseph a écrit :
> I literally mean that _exact_ snippet is leaking, 2 lines of code with no
> retaining by any superviews. I only have limited experience with Cocoa and
> don't use Objective C so maybe someone else could test this. Just allocate,
> initialize the
Sure, I get reference counted memory and it could very well be true that Cocoa
has no intent on releasing this at anytime I could expect and that was its
design.
If that's true when I would ask WHEN will it be deallocated? I'm leaking memory
like crazy allocating these objects and would argue i
Andre,
> Any other ideas?
Try to use the Zombies Instrument. If you're sending a message to a deallocated
object (as this is certainly the case), it will pop up.
Bonne chance ! ;)
Vincent
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Plea
You do know about autorelease pools, right? See whether the object survives the
next event cycle. I'm betting it doesn't.
Retain counts are none of your business, as is repeated almost daily on this
list. Don't peek at them, infer nothing from them. Follow the ownership rules,
and you'll be fin
On Jul 18, 2011, at 8:18 AM, Scott Ribe wrote:
> On Jul 17, 2011, at 10:32 PM, John Brownie wrote:
>
>> [HandlerClass createHandlerWith...]
>
> I think your model is correct, but Cocoa convention is that method names
> beginning with create confer ownership to the caller. If the caller does not
err hmm - running out of ideas. That's a heck of an address by the way - you
must be in 64 bit mode, I'm still not.
I often put a try-catch block around the body of the code in main.m NSLog()ed
the exception at that point and stuck in a breakpoint. I do that because I have
had issues with unha
On Jul 17, 2011, at 7:34 PM, Andre Masse wrote:
> -[NSCFString string]: unrecognized selector sent to instance 0x7fff71192b70
>
> Is there a way to know which instance is referred at that address? I tried
> "info symbol *0x7fff71192b70" in gdb and all i get is a blank line. The
> address is con
On Mon, Jul 18, 2011 at 7:20 AM, Vincent Habchi wrote:
> Try to use the Zombies Instrument. If you're sending a message to a
> deallocated object (as this is certainly the case), it will pop up.
Yes, this is the best idea. You can then follow the history of that
address and see what used to live
I am collecting track information (titles) and I would like to trim off
certain things
01 - Barracuda
becomes Barracuda
02 - Love Alive
becomes Love Alive
What is the best way to trim those off the front?
Thanks,
Eric
___
Cocoa-dev mailing list (Coco
Regular Expression find and replace? Basically, replace something like @"^\\d+
- " with @"".
Dave
On Jul 18, 2011, at 10:46 AM, Eric E. Dolecki wrote:
> I am collecting track information (titles) and I would like to trim off
> certain things
>
> 01 - Barracuda
> becomes Barracuda
>
> 02 - Lo
Le 18 juil. 2011 à 19:46, Eric E. Dolecki a écrit :
> I am collecting track information (titles) and I would like to trim off
> certain things
>
> 01 - Barracuda
> becomes Barracuda
>
> 02 - Love Alive
> becomes Love Alive
If your prefix is always "XX - " then you can use -[title
substringFrom
Does this look about right?
NSError *error = NULL;
NSRegularExpression *regex = [NSRegularExpression
regularExpressionWithPattern:@"^\\d+ - "
options:NSRegularExpressionCaseInsensitive
error:&error];
songTitle = [regex stringByReplacingMatchesInString:songTitle
On Jul 18, 2011, at 04:59, Gabriel Roth wrote:
> Thanks for the corrections. But changing the line in question to
>
> myTrackingArea = [[NSTrackingArea alloc]
> initWithRect:self.blueView.bounds
> options:(NSTrackingMouseEnteredAndExited |
> NSTrackingActiveInActiveApp | NSTrackingInVisibleR
On Jul 18, 2011, at 05:48, Andre Masse wrote:
> -[NSCFString string]: unrecognized selector sent to instance 0x7fff71192b70
I don't think anyone's pointed you in the direction of *reading* this error
message. Note that it says -[NSCFString string], not +[NSCFString string].
Someone has sent a '
As was pointed out below the CString doesn't support instance method string:.
Crashing this in a debugger should give you call stack so you can trace who is
doing the calling. You should also have a crash log that can be symbolized.
But, if this is your code run it in the debugger and have it c
I have a project that have one UIScroView who is loaded by viewDidLoad. On
nib of this class, I have an UIButton who I put there by IntefaceBuilder.
Then, when I run the project, the UIScrowView always stay on top of my
button.
how do I get my button is on top of UIScrollView?
Thanks!
--
*
Ah! Bullseye!
On 18/07/2011, at 14:13 , Quincey Morris wrote:
> Is this in Xcode 4? Make sure the "level of detail" slider at the bottom of
> the debugger view in the navigator pane is all the way to the right. If it's
> in its default middle position, it often collapses the call stack, mislea
You can open the XIB in Interface Builder, than use the Arrange > Bring To
Front command to make sure the button is always at front. I think this is the
best solution if the bug really is this simple. Otherwise maybe -[UIView
bringSubviewToFront:].
-ev
On Jul 19, 2011, at 04:41, Fernando Aur
Yes - so the more appropriate question is why it was retained 4 times.
I don't see Cocoa doing it.
It's the programmer - mostly.
Could you give us more code?
Cocoa gives us a very reliable way to know, when an object is released: If the
reference count goes down to 0.
The question now is how to b
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TextUILayer/Tasks/CreateTextViewProg.html%23//apple_ref/doc/uid/2930
On Jul 18, 3:30 pm, Peter wrote:
> Yes - so the more appropriate question is why it was retained 4 times.
> I don't see Cocoa doing it.
> It's the pro
On Mon, Jul 18, 2011 at 2:30 PM, Peter wrote:
> Yes - so the more appropriate question is why it was retained 4 times.
> I don't see Cocoa doing it.
> It's the programmer - mostly.
> Could you give us more code?
>
> Cocoa gives us a very reliable way to know, when an object is released: If
> the
In my simplified example this was indeed correct, it was autoreleased and was
deallocated on the next event cycle. I was convinced there as a problem with
NSTextView because other views were deallocated instantly but there was good
reason. I guess I'm just retaining it somewhere that I'll need t
On Mon, Jul 18, 2011 at 3:40 PM, Ryan Joseph wrote:
> In my simplified example this was indeed correct, it was autoreleased and was
> deallocated on the next event cycle. I was convinced there as a problem with
> NSTextView because other views were deallocated instantly but there was good
> rea
;) I was being stupid in that example, I see how my ownership was still
retained until I called release (for NSTextView.alloc.initWithFrame) and
removeFromSuperview (for parent.addSubview). Since there's nothing strange with
NSTextView like I originally thought I just need to pay very close atte
On Mon, Jul 18, 2011 at 3:55 PM, Ryan Joseph wrote:
> ;) I was being stupid in that example, I see how my ownership was still
> retained until I called release (for NSTextView.alloc.initWithFrame) and
> removeFromSuperview (for parent.addSubview). Since there's nothing strange
> with NSTextView
Absolutely. I saw that and started looking for crazy complicated answers before
looking for the obvious sensible ones. My case was poor use of
NSTextView/NSScrollView which was creating confusing cross-ownership scenarios
that were difficult to balance in my code.
On Jul 18, 2011, at 5:09 PM, K
I have a class (MyClass) that conforms to the collection methods for mutable
collections such as...
-(void)insert:(NSArray *)locationArray atIndexes:(NSIndexSet *)indexes
In my nib I have an NSArrayController and an instance of MyClass
My binding for the NSArrayController content looks like:
B
> I have a class (MyClass) that conforms to the collection methods for mutable
> collections such as...
>
> -(void)insert:(NSArray *)locationArray atIndexes:(NSIndexSet *)indexes
>
>
> In my nib I have an NSArrayController and an instance of MyClass
>
> My binding for the NSArrayController cont
Yes, that works—thanks very much.
If anyone can explain why my original version didn't
work, I'd appreciate it. My understanding was that the NSTrackingArea
object would be allocate, initialized, and assigned to an ivar in the
applicationDidFinishLaunching: method, and could then be added to and
r
On Jul 18, 2011, at 18:41, Trygve Inda wrote:
> The other possibly related issue is that I have my table delegate defined in
> the nib and seem to get
>
> -(void)tableViewSelectionDidChange:(NSNotification *)aNotification
>
> Before awakeFromNib which means my binding has not taken place yet. Do
> On Jul 18, 2011, at 18:41, Trygve Inda wrote:
>
>> The other possibly related issue is that I have my table delegate defined in
>> the nib and seem to get
>>
>> -(void)tableViewSelectionDidChange:(NSNotification *)aNotification
>>
>> Before awakeFromNib which means my binding has not taken pla
2011/7/18 Trygve Inda :
> I have a class (MyClass) that conforms to the collection methods for mutable
> collections such as...
>
> -(void)insert:(NSArray *)locationArray atIndexes:(NSIndexSet *)indexes
What happens if instead of implementing the collection methods, you
just expose the NSMutableAr
On Jul 18, 2011, at 19:13, Trygve Inda wrote:
> Where am I not KVO compliant?
I can't answer exactly, because you didn't provide enough information. So let
me provide an example.
Let's assume the array controller was bound to an array property of an object
in the nib of class MyClass, and you
Hi, I'm doing a fetch of some objects like this:
entity = [NSEntityDescription entityForName:kNMTopicNodeEntityKey
inManagedObjectContext:[self managedObjectContext]];
request = [[NSFetchRequest alloc] init];
[request setEntity:entity];
[request setRelationshipKeyPathsForPrefetching:[NSArray
arr
Thanks for the suggestions. I decided to go with having the handler
object retain itself and release itself when the interaction is
completed. That avoids having to have more instance variables in the
document object to track handlers and release them when done.
Also, thanks for the pointers t
41 matches
Mail list logo
