Re: Proper UTI for accepting files dropped on my table view?

[Rick Mann]

On Aug 9, 2010, at 23:48:34, Kyle Sluder wrote:

> On Mon, Aug 9, 2010 at 11:42 PM, Rick Mann  wrote:
>> Well, that seemed to do the trick. In the validate drop method, the 
>> pasteboard claims to have that type. But when I call propertyListForType: 
>> with that type, I get back null.
> 
> You might want to consider using the modern pasteboard API.

Could you elaborate? I'm trying to handle drops in an outline view. It calls 
delegate methods like:

- (NSDragOperation)
outlineView: (NSOutlineView*) inView
validateDrop: (id) inSender
proposedItem: (id) inItem
proposedChildIndex: (NSInteger) inIndex


From that I can only get an NSPasteboard, as far as I can tell.

I pretty much followed Apple direction to get to this point. If there's a more 
modern pasteboard, they should mention it in the old pasteboard docs.

-- 
Rick

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Custom zones...

[Quincey Morris]

On Aug 9, 2010, at 21:18, charlie wrote:

> NSString * string = [[NSString allocWithZone:zone] initWithFormat:@"abc!!!"];

> As you can see, the c string is successfully allocated from space in the 
> custom zone.  But the NSString object is allocated from the default zone, 
> despite having called +[NSObject allocWithZone:].

Well, the first result from googling "nsstring allocwithzone" is this:


http://www.cocoabuilder.com/archive/cocoa/52643-allocwithzone-not-working-with-class-clusters.html

which is pretty old but is still a valid reason why the specified zone might 
not be honored.

A second possibility is that the initializer you chose to use makes a decision 
where to put the NSString object based on where the format string is.

Whatever the reason, you don't have absolute control over the zone an object is 
allocated in, and I believe that specifying a zone at all is currently regarded 
as undesirable, if not yet actually deprecated.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Proper UTI for accepting files dropped on my table view?

[Kyle Sluder]

On Mon, Aug 9, 2010 at 11:42 PM, Rick Mann  wrote:
> Well, that seemed to do the trick. In the validate drop method, the 
> pasteboard claims to have that type. But when I call propertyListForType: 
> with that type, I get back null.

You might want to consider using the modern pasteboard API.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Proper UTI for accepting files dropped on my table view?

[Rick Mann]

On Aug 7, 2010, at 11:21:22, Joar Wingfors wrote:

> 
> On 7 aug 2010, at 02.34, Rick Mann wrote:
> 
>> I think you misunderstand (or I do). I don't want to specify a file of a 
>> particular type(s). I want to specify that a *file* is what I accept (as 
>> opposed to the contents of that file).
> 
> 
> Sounds like you're looking for NSFilenamesPboardType or NSURLPboardType. Or 
> if you want to use UTIs, perhaps kUTTypeFileURL is what you're after. Not 
> absolutely sure.
> 
> 

Well, that seemed to do the trick. In the validate drop method, the pasteboard 
claims to have that type. But when I call propertyListForType: with that type, 
I get back null.

This is lame.

-- 
Rick


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: UIPinchGestureRecognizer and MPMovieController view

[Marcel Borsten]

Thank you for your response, that did the trick.

> I was working on something similar. I ended up setting userInteractionEnabled 
> to false on the MPMoviePlayerController. The GR will then get the events 
> properly.
>-logan
>  
> On Jul 14, 2010, at 7:57 AM, MB wrote:
> 
>> I would like to use a UIPinchGestureRecognizer on a view container a 
>> MPMovieController.view as a subview. When the pinch happens within the view 
>> of the MPMovieController the gesture gets forwarded to the MPMovieController 
>> and is used for scaling fullscreen. I would like to capture the gestures 
>> before they reach the MPMovieController view and use them myself. Any idea 
>> on how to do this?
>> 
>> MB

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: how to include pure C++ header in obj-C in Xcode

[Velocityboy]

Name your Obj-C source file ending in .mm rather than .m.

-- Jim

On Aug 9, 2010, at 11:01 PM, Wayne Shao wrote:

> Hi,
> 
> I have a C++ util class (note: pure C++, it does not use obj-c objects in
> the C++ files).
> 
> When I added the C++ classes to Cocoa project, it compiles fine.
> But when I add C++ include from the ObjC class, it gives all kinds of
> errors.
> (Note: this is different from what the guide describes here
> http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html#//apple_ref/doc/uid/TP30001163-CH10-SW1
> )
> 
> 
> What is the right way to include C++ headers from objc?
> 
> // In objC class
> 
> #include "my_util.h"   (or #import "my_util.h")
> 
> @interface MyObjC : NSObject {
>   /// typical objc members skipped
> 
>  MyUtil*  util_;   // C++ object, compiling error : expected
> specifier-qualifier-list before 'MyUtil'
> 
> 
> }
> @end
> 
> 
> -- 
> W. Shao
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/velocityboy%40rodentia.net
> 
> This email sent to velocity...@rodentia.net

___

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

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

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

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

how to include pure C++ header in obj-C in Xcode

[Wayne Shao]

Hi,

I have a C++ util class (note: pure C++, it does not use obj-c objects in
the C++ files).

When I added the C++ classes to Cocoa project, it compiles fine.
But when I add C++ include from the ObjC class, it gives all kinds of
errors.
(Note: this is different from what the guide describes here
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocCPlusPlus.html#//apple_ref/doc/uid/TP30001163-CH10-SW1
)


What is the right way to include C++ headers from objc?

// In objC class

#include "my_util.h"   (or #import "my_util.h")

@interface MyObjC : NSObject {
   /// typical objc members skipped

  MyUtil*  util_;   // C++ object, compiling error : expected
specifier-qualifier-list before 'MyUtil'


}
@end


-- 
W. Shao
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: help with linking combo boxes

[One Only]

On Aug 9, 2010, at 10:52 AM, Quincey Morris wrote:

> On Aug 8, 2010, at 21:08, Rounak Jain wrote:
> 
>> I have an array called "Products". It has some product names which are saved 
>> in a plist file. More Products are added to it through the combo box (named 
>> Product) and they too get saved in the plist file automatically.
>> 
>> Now I want to create a second Combo Box (named Brand) and a third Combo Box 
>> (named Size). 
>> 
>> The idea is this:
>> 
>> Depending on the Product selected in the Product Combo Box, the Brand Combo 
>> Box must display a list of Brands for the user to select for that Product. 
>> Each Product will have many different brands. This means each Product will 
>> have its own array of Brands. Also, when a user types in a new Brand instead 
>> of using the existing ones, the new Brand should also be added in the array 
>> of Brands for that particular Product.
>> 
>> Finally, each Brand will have its own array of Sizes just like each Product 
>> had its own array of Brands. 
>> 
>> Please guide me on how I should do this.
> 
> You probably shouldn't even try.
> Despite superficial appearances, NSComboBox is a kind of text field, *not* a 
> kind of menu. If the intent is to choose an object from a list of objects, 
> NSComboBox is definitely not the way to go about it. Only use NSComboBox 
> where you want text entry, but also want to accelerate the text entry by 
> providing several pre-determined strings. Otherwise, use a menu or a 
> NSPopUpButton instead.
> 
> 

Hi Quincey, 
Thanks for the reply. It seems I did not make myself clear. I did write that 

>> the Brand Combo Box must display a list of Brands for the user to select for 
>> that Product.
but i also wrote
>> . Also, when a user types in a new Brand instead of using the existing ones, 
>> the new Brand should also be added in the array of Brands for that 
>> particular Product.
> 
So basically, i was only interested in the auto-complete (setComplete: method) 
of comboBox when I wrote the first sentence. 

But as you can see in the second sentence, I want the user to type in new 
Brands so that they are also available for auto-completion the next time. So I 
hope ComboBox is the right choice. Please guide me now.
Regards,
Rounak Jain___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Custom zones...

[charlie]

Having trouble getting objects to use a specific zone.

The following test code snippet demonstrates the problem I'm having:

NSZone * zone = NSCreateZone(vm_page_size * 2, vm_page_size, YES);
if (zone)
{
NSSetZoneName(zone, @"IN THE ZONE!!!");

char * cstring = (char *)NSZoneCalloc(zone, 50, 1);
if (cstring)
{
sprintf(cstring, "abc!!");
NSLog(@"   zone = %p", (void *)zone);
NSLog(@"cstring = %p", (void *)cstring);
			NSLog(@"end = %p", (void *)(((unsigned char 
*)cstring)+(vm_page_size * 2)));


NSZone * _czone = NSZoneFromPointer((void *)cstring);
if (_czone)
{
NSLog(@"cstring.zone name = %@", 
NSZoneName(_czone));
}

}

		NSString * string = [[NSString allocWithZone:zone] 
initWithFormat:@"abc!!!"];

if (string)
{
NSLog(@"  zone = %p", (void *)zone);
NSLog(@"string = %p", (void *)string);
			NSLog(@"   end = %p", (void *)(((unsigned char 
*)string)+(vm_page_size * 2)));


NSZone * _zone = NSZoneFromPointer((void *)string);
if (_zone)
{
NSLog(@"string.zone name = %@", 
NSZoneName(_zone));
}
}
}


... this code generates the following output:

2010-08-09 22:06:22.765 zonetest[24440:a0f]zone = 0x114658000
2010-08-09 22:06:22.768 zonetest[24440:a0f] cstring = 0x114b00010
2010-08-09 22:06:22.769 zonetest[24440:a0f] end = 0x114b02010
2010-08-09 22:06:22.770 zonetest[24440:a0f] cstring.zone name = IN THE 
ZONE!!!

2010-08-09 22:06:22.770 zonetest[24440:a0f]   zone = 0x114658000
2010-08-09 22:06:22.771 zonetest[24440:a0f] string = 0x10010ab30
2010-08-09 22:06:22.771 zonetest[24440:a0f]end = 0x10010cb30
2010-08-09 22:06:22.772 zonetest[24440:a0f] string.zone name = 
DefaultMallocZone



As you can see, the c string is successfully allocated from space in 
the custom zone.  But the NSString object is allocated from the default 
zone, despite having called +[NSObject allocWithZone:].


Anyone know the trick to this?

Thanks.

Chuck






___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: calling a function in one class from another

[Graham Cox]

On 10/08/2010, at 7:13 AM, Geoffrey Holden wrote:

> On a related note, how does this relate to plugin bundles?  I've created a 
> plugin (using the tutorial in Aaron Hillegass's excellent book) - and it 
> works perfectly.  I want to be able to respond to events in the plugin though 
> - would IBAction be the best way to do this since there doesn't seem to be a 
> way of getting the App to be a delegate for one of its plugins?


What do you mean by 'events'? Actual events, such as mouse down, key strokes, 
that sort of thing? Or do you really mean 'actions', which are responders to 
button clicks, menu choices, etc.

IBActions are useful for the latter. Events are a lower level concept (for 
example, a mouse down, mouse drag and mouse up could be a whole series of 
events that a button responds to, but which trigger one action, which informs 
the button's controller that the button was "clicked"). Actions are typically 
used to connect a user interface item to a controller that gives that user 
interface item some functional meaning by manipulating the data model 
appropriately.

A plug-in is not restricted as to what sort of UI it can present. You typically 
don't want the app (or its delegate) to be a controller on behalf of a 
plug-in's UI. It's not actually impossible but it's a crazy design, so I'm glad 
you think it is impossible! A plug-in can have a nib or nibs that provide a 
user interface just as the app can. How the plug-in interfaces to the app 
itself is up to you, but this should be happening at the controller or 
data-model level, not the UI. Other than that there's not much advice to give, 
given that I don't know anything about what your app or its plugins 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NStoolbarItem, custom view, setAction:

[Tony Romano]

That's the conclusion I came to but wanted to make sure I didn't miss something 
obvious.  The documentation is omitted this detail.  I'll file a bug for this.  

For the life of me, I cannot understand why NSToolbarItem contains the view and 
is not derived from a view, it just adds more work on the developer to do 
custom work.  I wanted to do some work and need to track the mouse messages.  
It would have been much simpler if it was derived from the view and I could 
over-ride the methods.

Thanks for confirming this Peter,
-Tony

On Aug 9, 2010, at 5:51 PM, Peter Ammon wrote:

> 
> On Aug 9, 2010, at 5:37 PM, Tony Romano wrote:
> 
> [...]
>> 
>> 
>> Looking at the documentation for NSToolbarItem setAction:, it has a little 
>> note: "For a custom view item, this method calls setAction: on the view if 
>> it responds.".   Which I infer to mean, that the basic Custom View should 
>> work.  What really interesting is NSToolbarItem is derived from 
>> NSObject(which is a whole other discussion on this design), so the setAction 
>> and setTarget need to get stored somewhere, there are no apparent private 
>> variables to store these items. Looking at the toolbar item in the debugger, 
>> the object knows that the view doesn't support set/get action because they 
>> set some bits on creation and look at the bit setting instead of calling 
>> respondsToSelector every time.
>> 
>> Anyone have any ideas as to why I can't use a custom view derived from 
>> NSView?
> 
> You can set any custom view you want.  However, NSToolbarItem delegates its 
> target/action entirely to its view, and has no storage for these properties.  
> If your view does not implement -target or -action, then the toolbar item's 
> target and action will both be NULL.
> 
> Hope this helps,
> -Peter
> 

-Tony

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NStoolbarItem, custom view, setAction:

[Peter Ammon]

On Aug 9, 2010, at 5:37 PM, Tony Romano wrote:

[...]
> 
> 
> Looking at the documentation for NSToolbarItem setAction:, it has a little 
> note: "For a custom view item, this method calls setAction: on the view if it 
> responds.".   Which I infer to mean, that the basic Custom View should work.  
> What really interesting is NSToolbarItem is derived from NSObject(which is a 
> whole other discussion on this design), so the setAction and setTarget need 
> to get stored somewhere, there are no apparent private variables to store 
> these items. Looking at the toolbar item in the debugger, the object knows 
> that the view doesn't support set/get action because they set some bits on 
> creation and look at the bit setting instead of calling respondsToSelector 
> every time.
> 
> Anyone have any ideas as to why I can't use a custom view derived from NSView?

You can set any custom view you want.  However, NSToolbarItem delegates its 
target/action entirely to its view, and has no storage for these properties.  
If your view does not implement -target or -action, then the toolbar item's 
target and action will both be NULL.

Hope this helps,
-Peter

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

NStoolbarItem, custom view, setAction:

[Tony Romano]

I'm trying to add a toolbar item that has a custom view.  I suspect there is a 
bug with the NSToolbarItem setAction: method if I choose to use a basic custom 
view(derived from NSView). In my mouse down, calling [NSApp 
sendAction:[_toolbarItem1 action] to:[_toolbarItem1 target] from:_toolbarItem1] 
has no effect, the action selector is nil;  The item draws fine, so the view 
appears to be wired up correctly. (_toolbarItem1 is the correct pointer, fyi).

Overview:

Scenario 1 -If I set the NSToolbarItem's view to a custom view that is derived 
from an NSControll(most of the ones from the Input and Values controls), then 
calling set action/target works and in my mouseDown, the action selector is 
valid and the action gets invoked.

Scenario 2 -If I set the NSToolbarItem's view to a custom view that is derived 
from NSView(from the layout view such as the basic Custom View), then calling 
set action/target has NO effect, i.e. the action selector in nil.

According to the documentation, I can use ANY custom view that is derived from 
NSView.

"The procedure for adding a custom view item is very similar to that for a 
custom image item. (“Custom” in this context means any object from the 
Interface Builder library as well as instances of a custom NSView subclass.) 
Just drag any view object from the library onto the Allowed Toolbar Items area. 
Click the item once and press Command-1 to display the Attributes pane for the 
object as a toolbar item; click again to edit the attributes of the item as 
itself. You should modify the size of the custom view item in the Size pane of 
the inspector, not directly. If you drag a Custom View object into the 
allowed-items set, click it twice and set the name of the custom NSView class 
in the Identity pane of the inspector (Command-6)."


Looking at the documentation for NSToolbarItem setAction:, it has a little 
note: "For a custom view item, this method calls setAction: on the view if it 
responds.".   Which I infer to mean, that the basic Custom View should work.  
What really interesting is NSToolbarItem is derived from NSObject(which is a 
whole other discussion on this design), so the setAction and setTarget need to 
get stored somewhere, there are no apparent private variables to store these 
items. Looking at the toolbar item in the debugger, the object knows that the 
view doesn't support set/get action because they set some bits on creation and 
look at the bit setting instead of calling respondsToSelector every time.

 Anyone have any ideas as to why I can't use a custom view derived from NSView?

Thanks,
-Tony

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

How to search for specific bindings in IB

[Chris Tracewell]

On occasion I refactor a controller or model by deleting a property. I do my 
best to remove associated bindings in IB, but many times I miss something - a 
textfield bound to a deleted property for example. This leads to...

this class is not key value coding-compliant for the key myProperty.

In larger NIB files this can be hard to find and remove. Is there anyway to 
search IB for bindings other than selecting individual elements and looking at 
the bindings inspector?

Thanks


-- chris___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Gideon King]

Thanks for all the feedback guys. I really need to rethink how I use KVO 
throughout my application.

I've read Mike Ash's post, and see the issues there - I'm surprised there 
aren't more places where the standard observations are tripping over each other.

Time for some refactoring...

Gideon___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

re: KVO and Core data

[Ben Trumbull]

> Hi all,
> 
> I have a KVO registration like this:
> 
> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
> 
> I establish this on -awakeFromInsert or -awakeFromFetch, and have the 
> corresponding removeObserver called on -willTurnIntoFault.
> 
> The problem is that when I do a Save As on my document, it migrates the 
> persistent store, which appears to cause the object at the destination of the 
> toOne relationship to be turned into a fault before the object that 
> registered as an observer is. Now when I check the observationInfo for the 
> object that is being faulted (at the end of the toOne relationship), it has 
> itself registered as an observer for "attribute". 
> 
> I guess this means that behind the scenes, the KVO establishes observation 
> information automatically at every level of a key path (something I hadn't 
> realized before, but which appears to make sense). 
> 
> Then something behind the scenes tries to access the attribute on an object 
> that has been turned into a fault, and invalidated, and everything comes 
> crashing down.
> 
> So I have two questions:
> 
> 1. Is it the "right way" for me to be adding observation on the awake methods 
> and removing it on willTurnToFault?
> 
> 2. If this is OK, then what could be affecting the system such that it 
> doesn't remove the observation information in the destination of the to-one 
> relationship? I'm wondering if there could be something in my data model that 
> could be affecting it. This relationship is modeled as a one to one, with a 
> delete rule of cascade from the parent to the child, and the inverse 
> relationship is also modeled, with a deny rule. There's also another optional 
> relationship from the child to the parent with a deny rule, modeled in one 
> direction only (and not used in the data I am testing with anyway).

Your problem here is this MOC is being torn down, and the "toOne" managed 
object is already toast.  So it's not possible to get its "attribute".  KVO 
isn't really in a position to deal with this.

Probably the best solution is for the toOne object to traverse the inverse and 
tell it's parent when to add or remove the KVO observation.  So this way when 
"attribute" is nuked, parent stops observing it.

Another possibility is to just have the accessor methods on "toOne" for the 
setter for "attribute" traverse the inverse manually and inform the parent 
outside of KVO.

- Ben



___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: IB Bug? maybe?

[Brian Postow]

On Aug 9, 2010, at 6:19 PM, Bill Monk wrote:

> 
>> Hmm, well, good things to do for sure, but I added [super init] and return 
>> self; to my scancontroller and it didn't help any.
>> 
> 
> Um, those are required things. 
> 
> 
>> Note: This bug ONLY shows up on 10.5. the program runs fine on 10.6...
> 
> Here, it crashes every few runs. 
> 
> Your AppController's -init also doesn't call [super init].  
> 
> May not be the bug you're looking for, but they are bugs all the same...and 
> you did ask. :)
> 


Fair enough. Although the no return was a casualty of the making it minimal 
process...  The thing that runs fine on 10.6 is the full version...  I think I 
found the problem, the top popup. Why that was a problem I dont know. But I 
deleted it and re-made it, and it seems to be ok now... weird.


Brian Postow
Senior Software Engineer
Acordex Imaging Systems

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: IB Bug? maybe?

[Bill Monk]

> Hmm, well, good things to do for sure, but I added [super init] and return 
> self; to my scancontroller and it didn't help any.
> 

Um, those are required things. 


> Note: This bug ONLY shows up on 10.5. the program runs fine on 10.6...

Here, it crashes every few runs. 

Your AppController's -init also doesn't call [super init].  

May not be the bug you're looking for, but they are bugs all the same...and you 
did ask. :)
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: IB Bug? maybe?

[Brian Postow]

On Aug 9, 2010, at 5:42 PM, Brian Postow wrote:

Ok, the problem is in the top popup (auto, doublesided, single sided) If I 
delete that one, it works, if I leave it, it doesn't.

Can anyone tell me what's different about that one?

The solution seems to be to just delete and re-make that popup, but now I'm 
curious...


Brian Postow
Senior Software Engineer
Acordex Imaging Systems

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: IB Bug? maybe?

[Brian Postow]

On Aug 9, 2010, at 5:32 PM, Bill Monk wrote:

> 
> On Aug 9, 2010, at 2:03 PM, cocoa-dev-requ...@lists.apple.com wrote:
> 
>> I created a minimal application that exhibits the problem:
>> 
>> http://www.acordex.com/temp/scancontrolltest.zip
>> 
>> thank you for anything you notice.
> 
> There's a warning on ScanController's -init: "control reaches end of non-void 
> function".
> 
> -(id) init
> {
> // scanner is automatically set up once it's found.   
>   [NSBundle loadNibNamed:@"ScannerControl" owner:self];
> }
> 
> 
> IOW, you forgot to return self. Or to call [super init]. 
> 


Hmm, well, good things to do for sure, but I added [super init] and return 
self; to my scancontroller and it didn't help any.

Note: This bug ONLY shows up on 10.5. the program runs fine on 10.6...

Brian Postow
Senior Software Engineer
Acordex Imaging Systems

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: IB Bug? maybe?

[Bill Monk]

On Aug 9, 2010, at 2:03 PM, cocoa-dev-requ...@lists.apple.com wrote:

> I created a minimal application that exhibits the problem:
> 
> http://www.acordex.com/temp/scancontrolltest.zip
> 
> thank you for anything you notice.

There's a warning on ScanController's -init: "control reaches end of non-void 
function".

-(id) init
{
// scanner is automatically set up once it's found. 
[NSBundle loadNibNamed:@"ScannerControl" owner:self];
}


IOW, you forgot to return self. Or to call [super init]. 
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: calling a function in one class from another

[Geoffrey Holden]

That's perfect, easy to understand, and it works too.  You're an  
excellent teacher - and my apologies for not knowing the correct  
terms.  I'm more used to plain old C (but I try to better myself).


On a related note, how does this relate to plugin bundles?  I've  
created a plugin (using the tutorial in Aaron Hillegass's excellent  
book) - and it works perfectly.  I want to be able to respond to  
events in the plugin though - would IBAction be the best way to do  
this since there doesn't seem to be a way of getting the App to be a  
delegate for one of its plugins?



On 6 Aug 2010, at 02:04, Graham Cox wrote:



On 06/08/2010, at 1:36 AM, Geoffrey Holden wrote:


So, the header for Foo contains

Bar* bar;

And when Foo is initialised it contains:

bar = [[Bar alloc] init];

And now I'd like to be able to call Wabble in Foo from a function  
within bar (I realise that this seems to be going the wrong way  
along the hierarchy).


Bar doesn't have any particular reference to Foo other than that  
Foo called it - unless ObjC provides such a reference for free.


Thanks for your help.



No, you don't get this for free. And you need to be careful about  
proper memory management and clear lines of ownership.


Foo owns Bar. Bar needs a pointer to Foo. As Foo is responsible for  
instantiating  (it owns it), then it can also set the pointer  
back to itself (what I typically call "back pointers"). This should  
be done through an accessor (e.g. -setFoo:) or perhaps a parameter  
to the designated initializer, e.g.:


//Foo:

bar = [[Bar alloc] initWithFoo:self];

//Bar:

- (id) initWithFoo:(id) foo
{
   self = [super init];
   if( self )
   {
   m_FooRef = foo;   // m_FooRef is the ivar "back pointer",  
does not retain 

   }

   return self;
}

This is commonly done, or you could make the ivar m_Foo an IBOutlet  
and connect it in IB if  is an object in the nib. There are a  
few things to be aware of when you create these references. First if  
Foo retains  then Bar shouldn't retain . That's a retain  
cycle and would prevent either object from being released, and so  
leak memory (unless you're using Garbage Collection, where that  
isn't an issue). My usual convention for ivars that reference but do  
not retain objects is to use the suffix Ref, as above. That's just a  
reminder to me about the ivar's function, it doesn't cause any magic  
to happen.


Anyone else could also retain , so when  is dealloc'ed,  
and releases , bar might not actually be deallocated at that  
time, meaning that it now has a stale reference to . So even if  
the logic suggests that the two things will be deallocated together,  
you need to remove the reference to  from  at that time -  
following a stale reference will cause a crash.


//Foo:

- (void)dealloc
{
   [bar setFoo:nil];// remove back pointer to this as we are  
about to disappear
   [bar release];   // release bar - might not deallocate it if  
someone else is retaining it

   [super dealloc];
}


Review of the general documentation on memory management and object  
ownership are a vital read, and should help you get all this clear.



--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Core Data bindings: add entity to relationship

[James Maxwell]

> 
> 
> As to the rest of it, I'm lost as to what you're talking about. What does 
> "ran the assignment in the app" mean?

Yeah, I just mean when I try to access the data programmatically from another 
part of the app -- when I iterate over the object hierarchy.

> What's the exact text of the reported error? There is no such error as 
> "valueUndefinedForKey". Maybe you're referring to "valueForUndefinedKey"?

Sorry, yes, that's correct.
> 
> It sounds like your popup button selection is getting bound to the 'name' 
> property of the Articulation object, and you run into an exception because 
> there's no setter for that property. As I said before, configuring 
> NSPopUpButton bindings is hard.
> 

hard it is. Cold comfort, I suppose.
Thanks for your help.

J.




> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com
> 
> This email sent to jbmaxw...@rubato-music.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: PropertyLocks?: strange exc_bad_access crash

[James Maxwell]

ah, good to know. Thanks.

J.


On 2010-08-09, at 11:04 AM, Kyle Sluder wrote:

> On Mon, Aug 9, 2010 at 10:42 AM, James Maxwell
>  wrote:
>> Yes, so I always use accessors in my initWithCoder routines. Is that a bad 
>> idea?
> 
> Yes, this is a bad idea. You should access instance variables directly
> from within initializers and -dealloc.
> 
> --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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Dave Fernandes]

Ah. OK. keyPathsForValuesAffecting wouldn't be directly helpful there. But 
KVO is easier to use with NS*Controller objects than directly with managed 
objects. Can you bind your view to one of the standard controllers instead, and 
have that controller track your managed object?

On 2010-08-09, at 1:03 PM, Gideon King wrote:

> It's a graphical application, and when things change in the back end, I often 
> need to move things around on the screen, so need to invalidate the drawing 
> rect at the old location, perhaps remove some bezier paths, and then need to 
> set it to need display at the new location. I was just thinking that it may 
> be handy for situations like this where I may have a whole lot of different 
> things that could happen in the back end, which all lead to the same action 
> required at the front end (though I will probably still need to use something 
> like a notification queue and coalescing to make sure that I only do the 
> expensive calculations once for a bunch of related changes in the back end.
> 
> 
> Gideon
> 
> On 10/08/2010, at 2:38 AM, Dave Fernandes wrote:
> 
>> 
>> On 2010-08-09, at 11:13 AM, Gideon King wrote:
>> 
>>> Dave's idea of using + (NSSet*)keyPathsForValuesAffecting may help in 
>>> some situations, but I don't think it's practical for all, especially where 
>>> I'm using KVO for my front end to observe changes in the back end and 
>>> react, where I sometimes need to know the before and after values. I'd have 
>>> to think about that some more...
>> 
>> Actually, it's particularly effective for keeping the UI updated and works 
>> with bindings. You provide an accessor method for your attribute and when 
>> called, the method first checks toOne's attributes that it depends on and 
>> then updates itself to be consistent before returning the new value. 
>> However, if you want the 'before' value, you will need your own 
>> caching/messaging in there somewhere. How is this information used?
>> 
>> 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: PropertyLocks?: strange exc_bad_access crash

[Greg Parker]

On Aug 9, 2010, at 10:07 AM, James Maxwell wrote:
> I'm getting a crash with this trace:
> 
> #00x99535ed7 in objc_msgSend
> #10xa0bf5224 in PropertyLocks
> #20x0001b792 in -[HSMM_Sequencer inputMemory] at HSMM_Sequencer.m:664
> #30x0001903b in -[HSMM_Sequencer predictForward:] at HSMM_Sequencer.m:262
> #40x00010253 in __-[HSMM_NetworkController 
> runNetworkPrediction]_block_invoke_ at HSMM_NetworkController.m:256
> #50x97762aa0 in _dispatch_apply2
> #60x976332b2 in _dispatch_worker_thread2
> #70x97632d41 in _pthread_wqthread
> #80x97632b86 in start_wqthread
> 
> 
> It only happens when running a particular function from its saved state 
> (i.e., from initWithCoder). I've looked for the usual suspects, in terms of 
> zombies and such, but I can't see anything obvious. The same algorithm runs 
> fine from its newly created state (i.e., using init, rather than 
> initWithCoder), so decoding must be somehow involved.
> Does this trace indicate anything special? Snooping into the objc_msgSend in 
> gdb I see that the selector is a retain, which I'm assuming would only cause 
> a crash if it was sent to a released object. I've not been able to find any 
> info on "PropertyLocks", but it certainly sounds as though it's related to 
> locking atomic properties... don't know though. What's strange, to me, is 
> that if this is a threading problem, why does it only happen from a decoded 
> state, not from a clean inited state?

PropertyLocks is an array of spinlocks used in the runtime's implementation of 
atomic properties. Importantly, it's a data array, not code, so it won't show 
up in any correct backtrace. It's likely that the stack trace is confused, or 
that you don't have debug info for frame #1 and PropertyLocks was merely the 
closest available symbol. 


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Dave Fernandes]

On 2010-08-09, at 12:57 PM, Quincey Morris wrote:

>> On 10/08/2010, at 12:20 AM, Keary Suska wrote:
>> 
>>> 
>>> The trace shows that the destination has been invalidated before your 
>>> object is faulted, and so the exception is raised when it tries to remove 
>>> observation. Invalidated object references should be rare--I would expect 
>>> Core Data to "clean up" relationships when a MOC is reset but that does not 
>>> appear to be the case (at least not all the time). Have you re-looked at 
>>> the issues around the question you asked back in 
>>> April:http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html
>>>  ?
> 
> But you haven't addressed Keary's excellent point that the problem is not 
> with faulting, but with the observed object being invalidated (apparently). 
> If faulting an observed object caused a crash, then I don't see how Core Data 
> could work at all.
> 
> Similarly, keyPathsForValuesAffecting seems like a red herring. It uses 
> observation internally (perhaps setting it up via a fast path not available 
> to applications), so it doesn't really change the picture.

I have no idea how keyPathsForValuesAffecting works under the hood, but it 
automagically handles setting up and tearing down observers when a MOC is 
reset, released, etc. So these kinds of problems simply don't happen. It's 
really the easy way to do it (unless you have to support Tiger).

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Dynamic loading of a third party .dylib

[Greg Parker]

On Aug 7, 2010, at 3:44 PM, jonat...@mugginsoft.com wrote:
> 1. In Xcode I link to my dylib and mark it as weak.
> 2. In my app I call dlopen() before accessing any of the library symbols.
> 
> But the symbol doesn't get resolved.
> 
> The crash log reports:
> 
> Dyld Error Message:
>  can't resolve symbol _G__main in /Nuzzle/And/Scratch/MacOS/Contents/boo 
> because dependent dylib #5 could not be loaded
> 
> Do I have to manually call dlsym() or am I missing a weak attribute somewhere.

You need to call dlsym(). A later dlopen() cannot fix a missing weak symbol. A 
weak symbol reference only gets one chance to resolve. If the symbol is not 
present at load time, then the reference is set to NULL and won't change after 
that. 


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Core Data bindings: add entity to relationship

[Quincey Morris]

On Aug 9, 2010, at 12:31, James Maxwell wrote:

> Yes, you're right. The Content for the menu is bound to 
> [Articulations_controller arrangedObjects], and Content Values is bound to 
> [Articulations_controller arrangedObjects].name. This works as expected, in 
> that I see the correct set of choices (Articulations_controller manages all 
> the stored articulations, not the assigned ones).
> In terms of the popup, I'm not binding to the cell directly, but rather to 
> the table column -- could that be the problem? I'm binding the Selected Value 
> to [AssignedArticulations_controller arrangedObjects].articulation.name. And 
> that just reverts to "No Value". I tried binding the column to Selected 
> Object [AssignedArticulations_controller arrangedObjects].articulation and 
> this at least **appeared** to work, since the chosen articulation stuck in 
> the menu. But when I ran the assignment in the app it crashed on Articulation 
> valueUndefinedForKey "name", which seemed a bit weird. 
> 
> So, I haven't been binding the cell itself. I've been under the impression 
> that it's the column that gets bound, not the cell -- so, yes, I meant 
> "Selected Value"...

Again, I was going only on what you said, which was "looking at the IB file, 
I've noticed that it already is a NSPopUpButtonCell, not a combo". Yes, 
typically you specify the binding on the table column, not on the cell.

As to the rest of it, I'm lost as to what you're talking about. What does "ran 
the assignment in the app" mean? What's the exact text of the reported error? 
There is no such error as "valueUndefinedForKey". Maybe you're referring to 
"valueForUndefinedKey"?

It sounds like your popup button selection is getting bound to the 'name' 
property of the Articulation object, and you run into an exception because 
there's no setter for that property. As I said before, configuring 
NSPopUpButton bindings is hard.




___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: PropertyLocks?: strange exc_bad_access crash

[Quincey Morris]

On Aug 9, 2010, at 11:48, James Maxwell wrote:

> Sorry, no, the initWithCoder happens at program launch, in the main thread - 
> nothing fancy there. 

You said "It only happens when running a particular function from its saved 
state (i.e., from initWithCoder)". That "when" and "from" made it sound very 
much as if you were creating the background thread in initWithCoder. But never 
mind, that's apparently not what you meant.

The backtrace suggests that either:

a. It's trying to acquire a lock on the 'inputMemory' property of the 
HSMM_Sequencer object.

b. It's trying to acquire a lock on a property of an object that's in the 
'inputMemory' array.

Either way, you likely have one of these problems:

1. Your archive was decoded correctly, but the encode was incorrect.

2. Your archive was decoded incorrectly (or incompletely).

3. You inadvertently have a threading error that destroys an object's internal 
state, which could relate to any object in the archive.

4. You inadvertently over-released something and therefore have a pure memory 
management error, which could relate to any object in the archive.

So you have a bit of work to do to pin it down, perhaps by validating your 
archive more thoroughly somewhere. Nothing but debugging will get you any 
further with this, I think.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Core Data bindings: add entity to relationship

[James Maxwell]

Yes, you're right. The Content for the menu is bound to 
[Articulations_controller arrangedObjects], and Content Values is bound to 
[Articulations_controller arrangedObjects].name. This works as expected, in 
that I see the correct set of choices (Articulations_controller manages all the 
stored articulations, not the assigned ones).
In terms of the popup, I'm not binding to the cell directly, but rather to the 
table column -- could that be the problem? I'm binding the Selected Value to 
[AssignedArticulations_controller arrangedObjects].articulation.name. And that 
just reverts to "No Value". I tried binding the column to Selected Object 
[AssignedArticulations_controller arrangedObjects].articulation and this at 
least **appeared** to work, since the chosen articulation stuck in the menu. 
But when I ran the assignment in the app it crashed on Articulation 
valueUndefinedForKey "name", which seemed a bit weird. 

So, I haven't been binding the cell itself. I've been under the impression that 
it's the column that gets bound, not the cell -- so, yes, I meant "Selected 
Value"...

J.


On 2010-08-09, at 12:16 PM, Quincey Morris wrote:

> On Aug 9, 2010, at 11:47, James Maxwell wrote:
> 
>> The other mistake in my original description is that the Value of the pop-up 
>> is bound to [AssignedArticulation_controller 
>> arrangedObjects].articulation.name (i.e., not "selection"), which does seem 
>> correct, since we don't know the selection yet... (I also tried binding it 
>> to the Index, rather than the Value, and this seemed a little closer, since 
>> it got rid of "No Value", and actually listed one of the created 
>> articulations. But I'm guessing this is just because the default index is 
>> assumed to be zero.)
> 
> This doesn't sound right. NSPopUpButtonCell doesn't have a "Value" binding. 
> Do you mean "selectedValue"?
> 
> NSPopupButton/Cell is hard to configure by bindings simply because you have 
> to very carefully keep track of the correct binding to use. There's content, 
> contentValues and contentObject. And selectedIndex, selectedValue and 
> selectedObject. Using some of the bindings affects the validity of others.
> 
> Also, consider what [AssignedArticulation_controller 
> arrangedObjects].articulation.name means. [AssignedArticulation_controller 
> arrangedObjects] is an array, so sending the 'articulation' message to it 
> returns (because of NSArray behavior, nothing directly to do with KVO or 
> bindings) an array containing the result of sending 'articulation' to each of 
> its members. Sending that the 'name' message returns an array of the names of 
> the Articulation objects in it.
> 
> That is, it builds a list of names of Articulations that have already been 
> assigned -- likely an empty list when your application starts.
> 
> It seems like the content of the menu from which articulations are chosen 
> needs needs to be an array of Articulation.name strings, and has nothing to 
> do with AssignedArticulation.articulation, unless you're doing something a 
> whole lot more obscure.
> 
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com
> 
> This email sent to jbmaxw...@rubato-music.com

James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Core Data bindings: add entity to relationship

[Quincey Morris]

On Aug 9, 2010, at 11:47, James Maxwell wrote:

> The other mistake in my original description is that the Value of the pop-up 
> is bound to [AssignedArticulation_controller 
> arrangedObjects].articulation.name (i.e., not "selection"), which does seem 
> correct, since we don't know the selection yet... (I also tried binding it to 
> the Index, rather than the Value, and this seemed a little closer, since it 
> got rid of "No Value", and actually listed one of the created articulations. 
> But I'm guessing this is just because the default index is assumed to be 
> zero.)

This doesn't sound right. NSPopUpButtonCell doesn't have a "Value" binding. Do 
you mean "selectedValue"?

NSPopupButton/Cell is hard to configure by bindings simply because you have to 
very carefully keep track of the correct binding to use. There's content, 
contentValues and contentObject. And selectedIndex, selectedValue and 
selectedObject. Using some of the bindings affects the validity of others.

Also, consider what [AssignedArticulation_controller 
arrangedObjects].articulation.name means. [AssignedArticulation_controller 
arrangedObjects] is an array, so sending the 'articulation' message to it 
returns (because of NSArray behavior, nothing directly to do with KVO or 
bindings) an array containing the result of sending 'articulation' to each of 
its members. Sending that the 'name' message returns an array of the names of 
the Articulation objects in it.

That is, it builds a list of names of Articulations that have already been 
assigned -- likely an empty list when your application starts.

It seems like the content of the menu from which articulations are chosen needs 
needs to be an array of Articulation.name strings, and has nothing to do with 
AssignedArticulation.articulation, unless you're doing something a whole lot 
more obscure.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSGlyphGenerator behavior

[Aki Inoue]

On 2010/08/07, at 22:08, vincent habchi wrote:

> Aki,
> 
>> No, it doesn't chunk based on word boundary. 
>> It could callback in chunks in order to prevent allocating too large buffer, 
>> though. 
>> 
>> So, you should be prepare to insert whatever requested. 
> 
> In fact, you're (of course) right. What I see is that it does cut as long as 
> I keep typing in the field. But, when the field looses and regains first 
> responder status, all the text is sent at once.
This behavior is resulted by how the text system invalidates existing layout 
cache.  While typing, the invalidated range is roughly limited to the paragraph 
being edited.

> 
> Since I have to identify keywords in a flow of chars, I do the surgery (or 
> butcher ;)) operation myself in my custom 
> -(void)generateGlyphsForGlyphStorage:… method, generating multiple calls (one 
> for each chunk) to the shared instance NSGlyphGenerator 
> -(void)generateGlyphsForGlyphStorage:…, and I analyse the return product.
> 
> Yet, I assume that – more or less in accordance to what the documentation 
> says –, the shared instance glyph generator does a basic one to one 
> translation between unicode and glyph, so that the length parameter in the 
> callback -(void)insertGlyphs: length: is valid not only for the glyph buffer, 
> but also for the original string. Is that hypothesis correct?
Yes, that's correct.

Aki

> Thanks a lot (and thanks also for the very informative talk you gave, without 
> which I surely wouldn't have been able to figure out all this)!
> 
> 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: PropertyLocks?: strange exc_bad_access crash

[James Maxwell]

Sorry, no, the initWithCoder happens at program launch, in the main thread - 
nothing fancy there. 
It's just this method (the crashing one) that's running in its own thread, and 
this is the same when creating the data structure from scratch (i.e. in init), 
where it doesn't crash.
Also, the inputMemory array isn't actually decoded - I only need it at runtime, 
so it's just inited manually in initWithCoder. 

- (id)  initWithCoder:(NSCoder *)aDecoder
{   
if(self = [super init])
{
[self setHsmmNode_s:[aDecoder 
decodeObjectForKey:@"hsmmNode_s"]];
[self setMaxSeqs:[aDecoder decodeIntForKey:@"maxSeqs"]];
[self setMaxSeqLength:[aDecoder 
decodeIntForKey:@"maxSeqLength"]];
[self setTimeScale:[aDecoder decodeIntForKey:@"timeScale"]];
[self setLZTree:[aDecoder decodeObjectForKey:@"LZTree"]];

NSMutableArray* mem = [[NSMutableArray alloc] init];
[self setInputMemory:mem];
[mem release];

[self setDefaults];
}
return self;
}

This is from HSMM_Sequencer's initWithCoder, where the accessor for inputMemory 
synthesized and retaining.
As a detail, when the program crashes, and drops into the debugger, clicking on 
line #2 of the trace (below) doesn't actually take me to the line in the code 
where inputMemory is accessed. It just takes me to the end of HSMM_Sequencer's 
implementation section. I'm guessing the memory's banjaxed enough that it just 
doesn't know where to put me, but maybe that's significant?

J.

On 2010-08-09, at 11:03 AM, Quincey Morris wrote:

> On Aug 9, 2010, at 10:07, James Maxwell wrote:
> 
>> I'm getting a crash with this trace:
>> 
>> #0   0x99535ed7 in objc_msgSend
>> #1   0xa0bf5224 in PropertyLocks
>> #2   0x0001b792 in -[HSMM_Sequencer inputMemory] at HSMM_Sequencer.m:664
>> #3   0x0001903b in -[HSMM_Sequencer predictForward:] at HSMM_Sequencer.m:262
>> #4   0x00010253 in __-[HSMM_NetworkController 
>> runNetworkPrediction]_block_invoke_ at HSMM_NetworkController.m:256
>> #5   0x97762aa0 in _dispatch_apply2
>> #6   0x976332b2 in _dispatch_worker_thread2
>> #7   0x97632d41 in _pthread_wqthread
>> #8   0x97632b86 in start_wqthread
>> 
>> 
>> It only happens when running a particular function from its saved state 
>> (i.e., from initWithCoder). I've looked for the usual suspects, in terms of 
>> zombies and such, but I can't see anything obvious. The same algorithm runs 
>> fine from its newly created state (i.e., using init, rather than 
>> initWithCoder), so decoding must be somehow involved.
>> Does this trace indicate anything special? Snooping into the objc_msgSend in 
>> gdb I see that the selector is a retain, which I'm assuming would only cause 
>> a crash if it was sent to a released object. I've not been able to find any 
>> info on "PropertyLocks", but it certainly sounds as though it's related to 
>> locking atomic properties... don't know though. What's strange, to me, is 
>> that if this is a threading problem, why does it only happen from a decoded 
>> state, not from a clean inited state?
> 
> Where is initWithCoder? Are you saying that you spun off a background thread 
> that uses just-decoded objects from within initWithCoder in a different 
> thread? In that case, how do you ensure that the decoding is complete first?
> 
> Unless you do something special, the original decoding path is going to 
> continue in parallel with the background operation. That means a mutable and 
> possibly changing object graph is actively being used by 2 threads, which 
> could be a recipe for disaster, even if only one of the threads is changing 
> anything. It could even mean that the decoding itself proceeds simultaneously 
> in multiple threads, which is likely an even bigger disaster.
> 
> Or your problem could easily be a memory management error, as Graham 
> suggests, but the conjunction of initWithCoder: and multithreading set off 
> very loud alarm bells in my head.
> 
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com
> 
> This email sent to jbmaxw...@rubato-music.com

James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca

___

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

Re: Core Data bindings: add entity to relationship

[James Maxwell]

Thanks Quincy,

But looking at the IB file, I've noticed that it already is a 
NSPopUpButtonCell, not a combo -- I got it wrong in my question, sorry.
However, your description of my mistake sounds right; i.e., that I'm trying to 
change the name rather than assign the relationship.
The other mistake in my original description is that the Value of the pop-up is 
bound to [AssignedArticulation_controller arrangedObjects].articulation.name 
(i.e., not "selection"), which does seem correct, since we don't know the 
selection yet... (I also tried binding it to the Index, rather than the Value, 
and this seemed a little closer, since it got rid of "No Value", and actually 
listed one of the created articulations. But I'm guessing this is just because 
the default index is assumed to be zero.)
I got this design from a Core Data book, though it doesn't seem to work in the 
sample project from the book either, so I wish I hadn't used it. 
(Interestingly, that code does use a ComboBox, but switching it to a popup 
didn't fix it there either.) Mind you, the design does seem totally logical, to 
me, so I'm not sure how I would do it differently... How should I assign an 
entity to the relationship of another entity?

The way I pictured it working was that the user builds an array of Articulation 
entities in one window/tab (which works). Then, in a second window/tab, s/he 
clicks one of the listed instruments in the left table, and then clicks the "+" 
at the bottom of the right table to create a new articulation mapping. This 
adds an object to the AssignedArticulation entity's articulations relationship 
- this is an Articulation entity. Picking a name from the popup then chooses 
the assigned articulation by name.
Seems reasonable...

J. 

On 2010-08-09, at 10:05 AM, Quincey Morris wrote:

> On Aug 9, 2010, at 08:52, James Maxwell wrote:
> 
>> I have a window with two tables: one showing the available instruments, and 
>> one for adding articulations to the selected instrument. The selection in 
>> the first table is bound to the [MnS_Instrument_Controller 
>> arrangedObjects].name, so that clicking a name selects a particular 
>> MnS_Instrument. The second table uses combo boxes for choosing which 
>> articulation to add; "+" and "-" buttons below the table are bound to the 
>> add: and remove: methods of AssignedArticulation_Controller. The available 
>> articulations, listed as choices in the combo boxes, are supplied by 
>> Articulation_controller, and they show up as expected. The value of the 
>> table selection is bound to [AssignedArticulation_Controller 
>> selection].articulation.name, the idea being that the AssignedArticulation 
>> will grab a named articulation from the set of stored Articulations, and 
>> assign it to the instrument. But when I release the combo box, it reverts 
>> back to "No Value" and won't make the assignment. 
>> 
>> Any ideas?
> 
> Yup. (I need to make this response a macro, I think.)
> 
> A combo box is a kind of text field, not a kind of menu, so it's the wrong 
> control to use in the circumstances described above. What you're doing by 
> making a "choice" from the combo box is trying to change the 
> Articulation.name string property, *not* the 
> AssignedArticulation.articulation relationship.
> 
> Use a menu or a NSPopUpButton in your interface, instead of NSComboBox.
> 
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/jbmaxwell%40rubato-music.com
> 
> This email sent to jbmaxw...@rubato-music.com

James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: IB Bug? maybe?

[Brian Postow]

I created a minimal application that exhibits the problem:

http://www.acordex.com/temp/scancontrolltest.zip

thank you for anything you notice.


Brian Postow
Senior Software Engineer
Acordex Imaging Systems

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTextView redraw while resigning first responder (sequel)

[vincent habchi]

Le 9 août 2010 à 19:03, Kyle Sluder a écrit :

> Oops. We have custom analogues of NSTextFieldCell that allow us to
> specify an NSTextStorage in -setObjectValue:. I forgot that
> NSTextFieldCell doesn't let you do this; it always uses its own layout
> manager.
> 
> I believe you will need to implement drawing yourself.

Hmmm. I was thinking about something, but it maybe stupid. If I back the 
NSTextField with a CALayer, it will get the glyphs drawn on it, no? Then I 
could snapshot the CALayer in the -resignFirstResponder: method, somehow make a 
copy that I would overlay, and then return to normal behavior on 
-becomesFirstResponder:? That would save the burden of laying out glyphs by 
myself.

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: String Tables

[Richard Somers]

I just noticed that iPhoto string table entries have the following form:

 Key1 = "Value1";

Not that it make any difference. Just interesting.

--Richard


On Aug 6, 2010, at 9:50 AM, Richard Somers wrote:


String table entrys have the following form.

"Key1" = "Value1";


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: PropertyLocks?: strange exc_bad_access crash

[Kyle Sluder]

On Mon, Aug 9, 2010 at 10:42 AM, James Maxwell
 wrote:
> Yes, so I always use accessors in my initWithCoder routines. Is that a bad 
> idea?

Yes, this is a bad idea. You should access instance variables directly
from within initializers and -dealloc.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: PropertyLocks?: strange exc_bad_access crash

[Quincey Morris]

On Aug 9, 2010, at 10:07, James Maxwell wrote:

> I'm getting a crash with this trace:
> 
> #00x99535ed7 in objc_msgSend
> #10xa0bf5224 in PropertyLocks
> #20x0001b792 in -[HSMM_Sequencer inputMemory] at HSMM_Sequencer.m:664
> #30x0001903b in -[HSMM_Sequencer predictForward:] at HSMM_Sequencer.m:262
> #40x00010253 in __-[HSMM_NetworkController 
> runNetworkPrediction]_block_invoke_ at HSMM_NetworkController.m:256
> #50x97762aa0 in _dispatch_apply2
> #60x976332b2 in _dispatch_worker_thread2
> #70x97632d41 in _pthread_wqthread
> #80x97632b86 in start_wqthread
> 
> 
> It only happens when running a particular function from its saved state 
> (i.e., from initWithCoder). I've looked for the usual suspects, in terms of 
> zombies and such, but I can't see anything obvious. The same algorithm runs 
> fine from its newly created state (i.e., using init, rather than 
> initWithCoder), so decoding must be somehow involved.
> Does this trace indicate anything special? Snooping into the objc_msgSend in 
> gdb I see that the selector is a retain, which I'm assuming would only cause 
> a crash if it was sent to a released object. I've not been able to find any 
> info on "PropertyLocks", but it certainly sounds as though it's related to 
> locking atomic properties... don't know though. What's strange, to me, is 
> that if this is a threading problem, why does it only happen from a decoded 
> state, not from a clean inited state?

Where is initWithCoder? Are you saying that you spun off a background thread 
that uses just-decoded objects from within initWithCoder in a different thread? 
In that case, how do you ensure that the decoding is complete first?

Unless you do something special, the original decoding path is going to 
continue in parallel with the background operation. That means a mutable and 
possibly changing object graph is actively being used by 2 threads, which could 
be a recipe for disaster, even if only one of the threads is changing anything. 
It could even mean that the decoding itself proceeds simultaneously in multiple 
threads, which is likely an even bigger disaster.

Or your problem could easily be a memory management error, as Graham suggests, 
but the conjunction of initWithCoder: and multithreading set off very loud 
alarm bells in my head.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Quincey Morris]

On Aug 9, 2010, at 10:42, Kyle Sluder wrote:

> On Mon, Aug 9, 2010 at 10:23 AM, Gideon King  wrote:
>> I don't quite get why I should be passing in something for the context when 
>> setting up observing. I would have thought that that would be only for cases 
>> where either:
>> a) you actually want to use some context data
>> b) you have more than one key path the same and the observation object isn't 
>> enough information to give you the necessary context.
>> ...neither of which is the case for my application.
> 
> The context is the only unique identifier for your observation. If
> both your implementation and your superclass's implementation register
> for the same keypath on the same object, the context is the only way
> to differentiate.
> 
> The only sane thing to do is the technique espoused by Mike Ash
> ,
> OFBinding 
> ,
> and AppKit itself (all the various NS*Binder classes): create helper
> objects for each individual binding, and have them use their self
> pointers as the context arguments.

In many cases, it's sufficient to pass any ol' unique object pointer (or unique 
non-object value, of course, but getting uniqueness via object pointers is 
easier). Many people use globally unique strings. I generally use the 
observer's class object. That's assuming, of course, that there's no real 
context information that you need to pass in.

To complete the sermon you started:

Given the unique context identifier, the 
'observeValueForKeyPath:ofObject:change:context:' *must* limit itself to 
handling invocations with the correct identifier and *must not* call the super 
implementation if it's correct. If the context is unrecognized, the method 
*must* call the super implementation instead. If Gideon didn't do that, then 
any number of application misbehaviors might result.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: PropertyLocks?: strange exc_bad_access crash

[James Maxwell]

Yes, so I always use accessors in my initWithCoder routines. Is that a bad idea?
My assumption was that the accessor would take care of the retain (most of 
these are synthesized, retaining accessors, though some are hand-written 
accessors -- but they should all be retaining).
I'll double-check everything again, but I'm pretty sure all the initWithCoders 
should be retaining.

J.


On 2010-08-09, at 10:20 AM, Graham Cox wrote:

> 
> On 10/08/2010, at 3:07 AM, James Maxwell wrote:
> 
>> What's strange, to me, is that if this is a threading problem, why does it 
>> only happen from a decoded state, not from a clean inited state?
> 
> 
> More likely to be a memory management problem. You're aware that objects 
> returned by -decodeObjectForKey: are autoreleased?
> 
> Set a breakpoint at the start of -inputMemory and step until it crashes. Then 
> you know the errant line. Perhaps the property you're setting from the result 
> of the decode is incorrectly specified. Dunno - show your code.
> 
> --Graham
> 
> 

James B Maxwell
Composer/Doctoral Student
School for the Contemporary Arts (SCA)
School for Interactive Arts + Technology (SIAT)
Simon Fraser University
jbmaxw...@rubato-music.com
jbmax...@sfu.ca

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Kyle Sluder]

On Mon, Aug 9, 2010 at 10:23 AM, Gideon King  wrote:
> I don't quite get why I should be passing in something for the context when 
> setting up observing. I would have thought that that would be only for cases 
> where either:
> a) you actually want to use some context data
> b) you have more than one key path the same and the observation object isn't 
> enough information to give you the necessary context.
> ...neither of which is the case for my application.

The context is the only unique identifier for your observation. If
both your implementation and your superclass's implementation register
for the same keypath on the same object, the context is the only way
to differentiate.

The only sane thing to do is the technique espoused by Mike Ash
,
OFBinding 
,
and AppKit itself (all the various NS*Binder classes): create helper
objects for each individual binding, and have them use their self
pointers as the context arguments.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Gideon King]

OK, it's well after 3am now, so I'll leave more detailed analysis until after 
some sleep.

The scenario is that of a simple Save As. As far as I am aware, I am not doing 
anything unusual in the process. I do not forcibly invalidate objects. It's a 
bit hard to track exactly what's happening, but I am able to look at the 
situation after willTurnIntoFault, and the observationInfo shows that the 
object at the destination of the to one relationship still has the key paths as 
registered by its parent established when it is made into a fault - i.e. I 
successfully established the observing at the parent level, which got 
automatically transferred to the child (without the first part of the key 
path), and then the child was faulted without the observing being 
removed...which is why I thought it might be some inconsistency with my model. 
I didn't establish that particular observation myself, so should not have to 
remove it myself.

I guess the topic did broaden from there to general issues around what is the 
right way to use KVO, as I have some other issues in my app related to it in 
other areas, and I'm looking for the recommended design patterns for KVO 
amongst core data entities, and between a core data backend and a gui 
controller front end.

I don't quite get why I should be passing in something for the context when 
setting up observing. I would have thought that that would be only for cases 
where either:
a) you actually want to use some context data
b) you have more than one key path the same and the observation object isn't 
enough information to give you the necessary context.
...neither of which is the case for my application.

Anyway, brain's fried...thanks for the help, and I'll check into it more in the 
morning...

Regards

Gideon

On 10/08/2010, at 2:57 AM, Quincey Morris wrote:

> 
> But you haven't addressed Keary's excellent point that the problem is not 
> with faulting, but with the observed object being invalidated (apparently). 
> If faulting an observed object caused a crash, then I don't see how Core Data 
> could work at all.
> 
> Similarly, keyPathsForValuesAffecting seems like a red herring. It uses 
> observation internally (perhaps setting it up via a fast path not available 
> to applications), so it doesn't really change the picture.
> 
> I think you will have to analyze the crash scenario more carefully. 
> Essentially, you crashed in -[NMTopicNodeMO willTurnIntoFault], which I 
> assume is one of your classes. What phase of the migration is this in -- is 
> the object in the store being migrated from, or to? Does migration do 
> something differently (such as forcibly invalidating objects) that doesn't 
> happen in normal Core Data behavior, and therefore that your code doesn't 
> expect or co-exist well with? Has the observation that's being "removed" at 
> the time of the crash even been established, or is your willTurnIntoFault 
> cause making an incorrect assumption about what happened earlier. Is it 
> necessary, when an object turns into a fault during a migration, to just add 
> a validation check that the observed object's ID is valid, before trying to 
> remove the observation?
> 
> TBH, I think you're going to have to be more disciplined in your analysis, 
> and investigate one question at a time, rather than trying a scattershot 
> approach.
> 
> Note that, given the black-box nature of much Core Data behavior, it might 
> not even be possible to formulate an answer about what's gone wrong. You may 
> be better off submitting a bug report claiming that your app's reasonable 
> behavior produces an unreasonable crash.
> 
> One final point, which I doubt has anything to do with your crash, but may 
> possibly be relevant:
> 
>> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
> 
> 
> "NULL" is a terrible choice for the context parameter. Use a value that's 
> unique (some people use a globally unique string, I use the class object of 
> the observer -- the considerations are a larger discussion) to the observer. 
> This is a defect in the KVO mechanism, BTW.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: PropertyLocks?: strange exc_bad_access crash

[Graham Cox]

On 10/08/2010, at 3:07 AM, James Maxwell wrote:

> What's strange, to me, is that if this is a threading problem, why does it 
> only happen from a decoded state, not from a clean inited state?


More likely to be a memory management problem. You're aware that objects 
returned by -decodeObjectForKey: are autoreleased?

Set a breakpoint at the start of -inputMemory and step until it crashes. Then 
you know the errant line. Perhaps the property you're setting from the result 
of the decode is incorrectly specified. Dunno - show your code.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

PropertyLocks?: strange exc_bad_access crash

[James Maxwell]

I'm getting a crash with this trace:

#0  0x99535ed7 in objc_msgSend
#1  0xa0bf5224 in PropertyLocks
#2  0x0001b792 in -[HSMM_Sequencer inputMemory] at HSMM_Sequencer.m:664
#3  0x0001903b in -[HSMM_Sequencer predictForward:] at HSMM_Sequencer.m:262
#4  0x00010253 in __-[HSMM_NetworkController 
runNetworkPrediction]_block_invoke_ at HSMM_NetworkController.m:256
#5  0x97762aa0 in _dispatch_apply2
#6  0x976332b2 in _dispatch_worker_thread2
#7  0x97632d41 in _pthread_wqthread
#8  0x97632b86 in start_wqthread


It only happens when running a particular function from its saved state (i.e., 
from initWithCoder). I've looked for the usual suspects, in terms of zombies 
and such, but I can't see anything obvious. The same algorithm runs fine from 
its newly created state (i.e., using init, rather than initWithCoder), so 
decoding must be somehow involved.
Does this trace indicate anything special? Snooping into the objc_msgSend in 
gdb I see that the selector is a retain, which I'm assuming would only cause a 
crash if it was sent to a released object. I've not been able to find any info 
on "PropertyLocks", but it certainly sounds as though it's related to locking 
atomic properties... don't know though. What's strange, to me, is that if this 
is a threading problem, why does it only happen from a decoded state, not from 
a clean inited state?

J.___

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

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

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

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

Re: Core Data bindings: add entity to relationship

[Quincey Morris]

On Aug 9, 2010, at 08:52, James Maxwell wrote:

> I have a window with two tables: one showing the available instruments, and 
> one for adding articulations to the selected instrument. The selection in the 
> first table is bound to the [MnS_Instrument_Controller arrangedObjects].name, 
> so that clicking a name selects a particular MnS_Instrument. The second table 
> uses combo boxes for choosing which articulation to add; "+" and "-" buttons 
> below the table are bound to the add: and remove: methods of 
> AssignedArticulation_Controller. The available articulations, listed as 
> choices in the combo boxes, are supplied by Articulation_controller, and they 
> show up as expected. The value of the table selection is bound to 
> [AssignedArticulation_Controller selection].articulation.name, the idea being 
> that the AssignedArticulation will grab a named articulation from the set of 
> stored Articulations, and assign it to the instrument. But when I release the 
> combo box, it reverts back to "No Value" and won't make the assignment. 
> 
> Any ideas?

Yup. (I need to make this response a macro, I think.)

A combo box is a kind of text field, not a kind of menu, so it's the wrong 
control to use in the circumstances described above. What you're doing by 
making a "choice" from the combo box is trying to change the Articulation.name 
string property, *not* the AssignedArticulation.articulation relationship.

Use a menu or a NSPopUpButton in your interface, instead of NSComboBox.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTextView redraw while resigning first responder (sequel)

[Kyle Sluder]

On Mon, Aug 9, 2010 at 8:03 AM, vincent habchi  wrote:
> Kyle,
>
> sorry for disturbing you once more.
>
> You suggested I use a custom layout manager for the NSTextField editor. 
> However, I see no way to set a layout editor for a NSTextField – I tried to 
> attach a custom field editor, but it fails the same way (that is to say, the 
> string reverts to its normal state when the field looses first responder 
> status). How should I proceed?

[Bringing this back on-list.]

Oops. We have custom analogues of NSTextFieldCell that allow us to
specify an NSTextStorage in -setObjectValue:. I forgot that
NSTextFieldCell doesn't let you do this; it always uses its own layout
manager.

I believe you will need to implement drawing yourself.

--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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Gideon King]

It's a graphical application, and when things change in the back end, I often 
need to move things around on the screen, so need to invalidate the drawing 
rect at the old location, perhaps remove some bezier paths, and then need to 
set it to need display at the new location. I was just thinking that it may be 
handy for situations like this where I may have a whole lot of different things 
that could happen in the back end, which all lead to the same action required 
at the front end (though I will probably still need to use something like a 
notification queue and coalescing to make sure that I only do the expensive 
calculations once for a bunch of related changes in the back end.


Gideon

On 10/08/2010, at 2:38 AM, Dave Fernandes wrote:

> 
> On 2010-08-09, at 11:13 AM, Gideon King wrote:
> 
>> Dave's idea of using + (NSSet*)keyPathsForValuesAffecting may help in 
>> some situations, but I don't think it's practical for all, especially where 
>> I'm using KVO for my front end to observe changes in the back end and react, 
>> where I sometimes need to know the before and after values. I'd have to 
>> think about that some more...
> 
> Actually, it's particularly effective for keeping the UI updated and works 
> with bindings. You provide an accessor method for your attribute and when 
> called, the method first checks toOne's attributes that it depends on and 
> then updates itself to be consistent before returning the new value. However, 
> if you want the 'before' value, you will need your own caching/messaging in 
> there somewhere. How is this information used?
> 
> 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Quincey Morris]

On Aug 9, 2010, at 08:13, Gideon King wrote:

> Yes, Ben helped me a lot with sorting out the underlying issues, which turned 
> out to be a number of misunderstandings about what various methods in the 
> atomic store are supposed to do, what is required, etc etc. And at the time, 
> we had got to a point where we could save, save as, open and save, and it all 
> worked, but this is the first time we have revisited the whole file saving 
> thing after making a bunch of changes to the model and lots of KVO stuff, and 
> either there were inherent problems that we didn't see before because we 
> weren't observing attributes like this, or we may have introduced issues that 
> weren't there before.
> 
> Dave's idea of using + (NSSet*)keyPathsForValuesAffecting may help in 
> some situations, but I don't think it's practical for all, especially where 
> I'm using KVO for my front end to observe changes in the back end and react, 
> where I sometimes need to know the before and after values. I'd have to think 
> about that some more...
> 
> I hadn't thought about the faulting and refetching issue, and I do need to 
> support 10.5, so don't have the awakeFromSnapshotEvents available to me.
> 
> [...]
> 
> On 10/08/2010, at 12:20 AM, Keary Suska wrote:
> 
>> 
>> The trace shows that the destination has been invalidated before your object 
>> is faulted, and so the exception is raised when it tries to remove 
>> observation. Invalidated object references should be rare--I would expect 
>> Core Data to "clean up" relationships when a MOC is reset but that does not 
>> appear to be the case (at least not all the time). Have you re-looked at the 
>> issues around the question you asked back in 
>> April:http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html
>>  ?

But you haven't addressed Keary's excellent point that the problem is not with 
faulting, but with the observed object being invalidated (apparently). If 
faulting an observed object caused a crash, then I don't see how Core Data 
could work at all.

Similarly, keyPathsForValuesAffecting seems like a red herring. It uses 
observation internally (perhaps setting it up via a fast path not available to 
applications), so it doesn't really change the picture.

I think you will have to analyze the crash scenario more carefully. 
Essentially, you crashed in -[NMTopicNodeMO willTurnIntoFault], which I assume 
is one of your classes. What phase of the migration is this in -- is the object 
in the store being migrated from, or to? Does migration do something 
differently (such as forcibly invalidating objects) that doesn't happen in 
normal Core Data behavior, and therefore that your code doesn't expect or 
co-exist well with? Has the observation that's being "removed" at the time of 
the crash even been established, or is your willTurnIntoFault cause making an 
incorrect assumption about what happened earlier. Is it necessary, when an 
object turns into a fault during a migration, to just add a validation check 
that the observed object's ID is valid, before trying to remove the observation?

TBH, I think you're going to have to be more disciplined in your analysis, and 
investigate one question at a time, rather than trying a scattershot approach.

Note that, given the black-box nature of much Core Data behavior, it might not 
even be possible to formulate an answer about what's gone wrong. You may be 
better off submitting a bug report claiming that your app's reasonable behavior 
produces an unreasonable crash.

One final point, which I doubt has anything to do with your crash, but may 
possibly be relevant:

> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];


"NULL" is a terrible choice for the context parameter. Use a value that's 
unique (some people use a globally unique string, I use the class object of the 
observer -- the considerations are a larger discussion) to the observer. This 
is a defect in the KVO mechanism, BTW.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Dave Fernandes]

On 2010-08-09, at 11:13 AM, Gideon King wrote:

> Dave's idea of using + (NSSet*)keyPathsForValuesAffecting may help in 
> some situations, but I don't think it's practical for all, especially where 
> I'm using KVO for my front end to observe changes in the back end and react, 
> where I sometimes need to know the before and after values. I'd have to think 
> about that some more...

Actually, it's particularly effective for keeping the UI updated and works with 
bindings. You provide an accessor method for your attribute and when called, 
the method first checks toOne's attributes that it depends on and then updates 
itself to be consistent before returning the new value. However, if you want 
the 'before' value, you will need your own caching/messaging in there 
somewhere. How is this information used?

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Iphone calculator application.

[Dave DeLong]

http://developer.apple.com/iphone/library/navigation/index.html

Click the "Sample Code" link in the left sidebar.

Dave

On Aug 9, 2010, at 10:23 AM, Arnab Ganguly wrote:

> Hi,
> 
> 
> I am planning to write sample iPhone calculator application.Where can I find
> sample code which can help on the approach.
> 
> 
> Thanks in advance.
> 
> -A
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/davedelong%40me.com
> 
> This email sent to davedel...@me.com



smime.p7s
Description: S/MIME cryptographic signature
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Iphone calculator application.

[Arnab Ganguly]

Hi,


I am planning to write sample iPhone calculator application.Where can I find
sample code which can help on the approach.


Thanks in advance.

-A
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Core Data bindings: add entity to relationship

[James Maxwell]

I have a problem with Core Data and bindings that I can't work out.

Here's the data model:

<>
It's a music app, and I'm trying to set up MIDI instrument customization for 
the user. The interface let's the user create new Instruments (MnS_Instrument 
entities) which map a name to a port and channel, new Articulations 
(Articulations entities) which map a name to a set of MIDI messages (controller 
changes, program changes, etc.), and then to assign the Articulations to 
Instruments. I have an array controller for each entity in the model. The 
AssignedArticulation controller gets its contentSet from 
[MnS_Instrument_controller selection].articulations, and the MIDIMessage 
controller gets its contentSet from [Articulation_controller 
selection].messages. (Note that I'm not hosting AUs yet, so virtualInstrument 
isn't used.)
Everything works as expected, up to the assignment of articulations to 
instruments.
I have a window with two tables: one showing the available instruments, and one 
for adding articulations to the selected instrument. The selection in the first 
table is bound to the [MnS_Instrument_Controller arrangedObjects].name, so that 
clicking a name selects a particular MnS_Instrument. The second table uses 
combo boxes for choosing which articulation to add; "+" and "-" buttons below 
the table are bound to the add: and remove: methods of 
AssignedArticulation_Controller. The available articulations, listed as choices 
in the combo boxes, are supplied by Articulation_controller, and they show up 
as expected. The value of the table selection is bound to 
[AssignedArticulation_Controller selection].articulation.name, the idea being 
that the AssignedArticulation will grab a named articulation from the set of 
stored Articulations, and assign it to the instrument. But when I release the 
combo box, it reverts back to "No Value" and won't make the assignment. 

Any ideas?

J.___

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

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

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

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

Re: KVO and Core data

[Gideon King]

Thanks Keary and Dave

Yes, Ben helped me a lot with sorting out the underlying issues, which turned 
out to be a number of misunderstandings about what various methods in the 
atomic store are supposed to do, what is required, etc etc. And at the time, we 
had got to a point where we could save, save as, open and save, and it all 
worked, but this is the first time we have revisited the whole file saving 
thing after making a bunch of changes to the model and lots of KVO stuff, and 
either there were inherent problems that we didn't see before because we 
weren't observing attributes like this, or we may have introduced issues that 
weren't there before.

Dave's idea of using + (NSSet*)keyPathsForValuesAffecting may help in some 
situations, but I don't think it's practical for all, especially where I'm 
using KVO for my front end to observe changes in the back end and react, where 
I sometimes need to know the before and after values. I'd have to think about 
that some more...

I hadn't thought about the faulting and refetching issue, and I do need to 
support 10.5, so don't have the awakeFromSnapshotEvents available to me.

So, still a little uncertain on the best solution for my situation...

Regards

Gideon

On 10/08/2010, at 12:20 AM, Keary Suska wrote:

> 
> The trace shows that the destination has been invalidated before your object 
> is faulted, and so the exception is raised when it tries to remove 
> observation. Invalidated object references should be rare--I would expect 
> Core Data to "clean up" relationships when a MOC is reset but that does not 
> appear to be the case (at least not all the time). Have you re-looked at the 
> issues around the question you asked back in April: 
> http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html
>  ?
> 
> If that doesn't help, the easiest workaround I can think of is have the 
> destination observe its attribute, and then call a method on all objects from 
> the inverse to-many.
> 
>> So I have two questions:
>> 
>> 1. Is it the "right way" for me to be adding observation on the awake 
>> methods and removing it on willTurnToFault?
> 
> For cross-relationship KVO, generally yes.
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 

___

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

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

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

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

Re: KVO and Core data

[Dave Fernandes]

On 2010-08-09, at 10:20 AM, Keary Suska wrote:

> 
>> So I have two questions:
>> 
>> 1. Is it the "right way" for me to be adding observation on the awake 
>> methods and removing it on willTurnToFault?
> 
> For cross-relationship KVO, generally yes.

Objects can turn into faults and then be refetched. Not sure if 
awakeFromSnapshotEvents: covers all these cases. In any case, this is only 
useful on 10.6 or later. For earlier OS versions, you will have a problem with 
the above design pattern if an object is, say, deleted and then the deletion is 
undone.___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSPathControl w/ popups and icons

[Kevin Perry]

NSPathControl doesn't map submenus in its menu to the individual 
NSPathComponentCells, so that's not going to work.

This will probably require some heavy subclassing of at least 
NSPathComponentCell, and perhaps NSPathCell (if the layout isn't quite how you 
need it). You'll need to provide some way to set a menu on your component cell, 
and you'll also need to override cell mouse tracking so you can show the menu 
when the user clicks on the cell. That might be enough, but depending on your 
expectations, you may need to do more than that.

On Jul 31, 2010, at 5:44 PM, Shane wrote:

> I'm trying to create an NSPathControl where there are several items
> (components) within the row and each item (component) is a popup menu.
> And then I would populate each of those popups w/ items. But I'm
> having a problem in understanding if that's how it really works.
> 
> I'm playing around w/ the following code. Can anyone offer guidance on
> using NSPathControl?
> 
> 
>   NSPathComponentCell *cell1 = [[NSPathComponentCell alloc] init];
>   [cell1 setTitle:@"cell 1"];
>   [networkComponents addObject:cell1];
>   
>   NSPathComponentCell *cell2 = [[NSPathComponentCell alloc] init];
>   [cell2 setTitle:@"cell 2"];
>   [networkComponents addObject:cell2];
>   
>   NSMenu *pathMenu = [[NSMenu alloc] initWithTitle:@"Main"];
>   NSMenuItem *pathItems = [[NSMenuItem alloc] initWithTitle:@"item #1"
> action:nil keyEquivalent:@""];
>   NSMenuItem *pathItems2 = [[NSMenuItem alloc] initWithTitle:@"item #2"
> action:nil keyEquivalent:@""];
>   [pathItems setSubmenu:pathMenu];
>   [pathItems2 setSubmenu:pathMenu];
>   
>   [networkPathControl setMenu:pathMenu];
> 
>   // setStringValue works, but its' only 1 single popup that's empty 
> unless
>// I click on it, then I see the string values
>   //[networkPathControl setStringValue:@"cell 3 / cell 4"];
> 
>   //[networkPathControl setPathComponentCells:networkComponents];
>   //[networkPathControl setBackgroundColor:[NSColor blueColor]];
>   //[networkPathControl setNeedsDisplay:YES];
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com
> 
> This email sent to kpe...@apple.com

___

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

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

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

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

Re: KVO and Core data

[Keary Suska]

On Aug 9, 2010, at 4:51 AM, Gideon King wrote:

> Hi all,
> 
> I have a KVO registration like this:
> 
> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
> 
> I establish this on -awakeFromInsert or -awakeFromFetch, and have the 
> corresponding removeObserver called on -willTurnIntoFault.
> 
> The problem is that when I do a Save As on my document, it migrates the 
> persistent store, which appears to cause the object at the destination of the 
> toOne relationship to be turned into a fault before the object that 
> registered as an observer is. Now when I check the observationInfo for the 
> object that is being faulted (at the end of the toOne relationship), it has 
> itself registered as an observer for "attribute". 
> 
> I guess this means that behind the scenes, the KVO establishes observation 
> information automatically at every level of a key path (something I hadn't 
> realized before, but which appears to make sense). 

Yes.

> Then something behind the scenes tries to access the attribute on an object 
> that has been turned into a fault, and invalidated, and everything comes 
> crashing down.

The trace shows that the destination has been invalidated before your object is 
faulted, and so the exception is raised when it tries to remove observation. 
Invalidated object references should be rare--I would expect Core Data to 
"clean up" relationships when a MOC is reset but that does not appear to be the 
case (at least not all the time). Have you re-looked at the issues around the 
question you asked back in April: 
http://www.cocoabuilder.com/archive/cocoa/284398-invalidated-managed-objects.html
 ?

If that doesn't help, the easiest workaround I can think of is have the 
destination observe its attribute, and then call a method on all objects from 
the inverse to-many.

> So I have two questions:
> 
> 1. Is it the "right way" for me to be adding observation on the awake methods 
> and removing it on willTurnToFault?

For cross-relationship KVO, generally yes.

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

___

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

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

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

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

Re: KVO and Core data

[Dave Fernandes]

Why does the object need to be notified of changes? Is it to change its own 
attributes in response? If so, you can define the class method
+ (NSSet*)keyPathsForValuesAffecting

There is no observer to set up or remove.

Dave

On 2010-08-09, at 8:42 AM, Gideon King wrote:

> The objective is for me to be notified when "toOne.attribute" changes (either 
> by toOne changing or by the attribute changing).
> 
> Surely what I am doing is not getting the NSManagedObject to observe itself, 
> but rather the observer is self and the "observee" is the to one relationship 
> and it's attribute.
> 
> If I made it [toOne addObserver:self forKeyPath:@"attribute" options:0 
> context:NULL], then I would have to separately keep track of when toOne 
> changed, and update the observers, and also this is a simple case - sometimes 
> I need to do "toOne.toOne.attribute".
> 
> Or maybe I'm missing something in how KVO works with key paths...
> 
> Gideon
> 
> 
> On 09/08/2010, at 9:24 PM, Michael Swan wrote:
> 
>> Gideon,
>> It looks like you have an NSManagedObject that is observing itself. If this 
>> is in fact the case what is the objective? There may be a better way to 
>> accomplish your goal if you let us know what it is.
>> 
>>> 
>>> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 
>>> context:NULL];
>>> 
>>> 
> 
> ___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%40utoronto.ca
> 
> This email sent to dave.fernan...@utoronto.ca

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Gideon King]

The objective is for me to be notified when "toOne.attribute" changes (either 
by toOne changing or by the attribute changing).

Surely what I am doing is not getting the NSManagedObject to observe itself, 
but rather the observer is self and the "observee" is the to one relationship 
and it's attribute.

If I made it [toOne addObserver:self forKeyPath:@"attribute" options:0 
context:NULL], then I would have to separately keep track of when toOne 
changed, and update the observers, and also this is a simple case - sometimes I 
need to do "toOne.toOne.attribute".

Or maybe I'm missing something in how KVO works with key paths...

Gideon


On 09/08/2010, at 9:24 PM, Michael Swan wrote:

> Gideon,
> It looks like you have an NSManagedObject that is observing itself. If this 
> is in fact the case what is the objective? There may be a better way to 
> accomplish your goal if you let us know what it is.
> 
>> 
>> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
>> 
>> 

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: KVO and Core data

[Michael Swan]

Gideon,
It looks like you have an NSManagedObject that is observing itself. If this is 
in fact the case what is the objective? There may be a better way to accomplish 
your goal if you let us know what it is.


Mike Swan
ETCP Certified Entertainment Electrician
http://www.michaelsswan.com

"As human beings our greatness lies not so much in being able to remake the 
world... as being able to remake ourselves"  - Gandhi



On Aug 9, 2010, at 6:59 AM, cocoa-dev-requ...@lists.apple.com wrote:

> Message: 15
> Date: Mon, 9 Aug 2010 20:51:44 +1000
> From: Gideon King 
> Subject: KVO and Core data
> To: cocoa-dev List 
> Message-ID: <55ff7ff0-18be-4e88-93b5-28d1da2bf...@novamind.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi all,
> 
> I have a KVO registration like this:
> 
> [self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];
> 
> I establish this on -awakeFromInsert or -awakeFromFetch, and have the 
> corresponding removeObserver called on -willTurnIntoFault.
> 
> The problem is that when I do a Save As on my document, it migrates the 
> persistent store, which appears to cause the object at the destination of the 
> toOne relationship to be turned into a fault before the object that 
> registered as an observer is. Now when I check the observationInfo for the 
> object that is being faulted (at the end of the toOne relationship), it has 
> itself registered as an observer for "attribute". 
> 
> I guess this means that behind the scenes, the KVO establishes observation 
> information automatically at every level of a key path (something I hadn't 
> realized before, but which appears to make sense). 
> 
> Then something behind the scenes tries to access the attribute on an object 
> that has been turned into a fault, and invalidated, and everything comes 
> crashing down.
> 
> So I have two questions:
> 
> 1. Is it the "right way" for me to be adding observation on the awake methods 
> and removing it on willTurnToFault?
> 
> 2. If this is OK, then what could be affecting the system such that it 
> doesn't remove the observation information in the destination of the to-one 
> relationship? I'm wondering if there could be something in my data model that 
> could be affecting it. This relationship is modeled as a one to one, with a 
> delete rule of cascade from the parent to the child, and the inverse 
> relationship is also modeled, with a deny rule. There's also another optional 
> relationship from the child to the parent with a deny rule, modeled in one 
> direction only (and not used in the data I am testing with anyway).
> 
> 
> A sample trace:
> 
> The NSManagedObject with ID:0x1240033c0 
> 
>  has been invalidated.
> 0   CoreFoundation  0x7fff88f0fcc4 
> __exceptionPreprocess + 180
> 1   libobjc.A.dylib 0x7fff823880f3 
> objc_exception_throw + 45
> 2   CoreData0x7fff8836911a 
> -[_NSInvalidationFaultHandler fulfillFault:withContext:] + 106
> 3   CoreData0x7fff8830bdbe 
> _PF_FulfillDeferredFault + 254
> 4   CoreData0x7fff8830fab7 
> _sharedIMPL_pvfk_core + 87
> 5   CoreData0x7fff8830fc28 
> -[NSManagedObject(_PFDynamicAccessorsAndPropertySupport) 
> _genericValueForKey:withIndex:flags:] + 40
> 6   CoreData0x7fff883154be -[NSManagedObject 
> valueForKey:] + 270
> 7   Foundation  0x7fff868594e5 
> -[NSKeyValueNestedProperty object:didRemoveObservance:recurse:] + 86
> 8   Foundation  0x7fff86858d3b 
> -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 190
> 9   Foundation  0x7fff86858c1f 
> -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 135
> 10  Foundation  0x7fff86859502 
> -[NSKeyValueNestedProperty object:didRemoveObservance:recurse:] + 115
> 11  Foundation  0x7fff86858d3b 
> -[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 190
> 12  Foundation  0x7fff86858c1f 
> -[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 135
> 13  NMFoundation0x0001002bbe6f -[NMTopicNodeMO 
> stopObserving] + 279
> 14  NMFoundation0x0001002b1f23 -[NMManagedObject 
> willTurnIntoFault] + 235
> 15  NMFoundation0x0001002bc070 -[NMTopicNodeMO 
> willTurnIntoFault] + 347
> 16  CoreData0x7fff88316be0 -[NSFaultHandler 
> turnObject:intoFaultWithContext:] + 96
> 17  CoreData0x7fff88316572 
> -[NSManagedObjectContext reset] + 578
> 18  CoreData0x7fff8836e0d3 
> -[NSPersistentStoreCoordinator(_NSInternalMethods) 
> _retainedAllMigratedObjectsInStore:toStore:] 

addOverlays but mapView:viewForOverlay: never called

[Gerriet M. Denkmann]

I have an MKMapView which does addOverlays:
but it's delegate MKMapViewDelegate method  mapView:viewForOverlay: is never 
called.

The overlays receive the message boundingMapRect:
- (MKMapRect)boundingMapRect 
{
MKMapPoint lowerLeft = MKMapPointForCoordinate(minC);
MKMapPoint upperRight = MKMapPointForCoordinate(maxC);
MKMapRect re = MKMapRectMake(   lowerLeft.x, upperRight.y, 

upperRight.x - lowerLeft.x, lowerLeft.y - upperRight.y
);
return re;
}

A line from  +13.720498° / +100.557946° to  +13.719897° / +100.559414°  returns 
the MKMapRect {{209199167.2, 12388.8}, {1094.4, 460.9}}
Looks creditable to me, but is it really?

Whenever the map size changes (e.g. by pinching) the message boundingMapRect is 
sent again.

So what am I missing?

Kind regards,

Gerriet.

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

KVO and Core data

[Gideon King]

Hi all,

I have a KVO registration like this:

[self addObserver:self forKeyPath:@"toOne.attribute" options:0 context:NULL];

I establish this on -awakeFromInsert or -awakeFromFetch, and have the 
corresponding removeObserver called on -willTurnIntoFault.

The problem is that when I do a Save As on my document, it migrates the 
persistent store, which appears to cause the object at the destination of the 
toOne relationship to be turned into a fault before the object that registered 
as an observer is. Now when I check the observationInfo for the object that is 
being faulted (at the end of the toOne relationship), it has itself registered 
as an observer for "attribute". 

I guess this means that behind the scenes, the KVO establishes observation 
information automatically at every level of a key path (something I hadn't 
realized before, but which appears to make sense). 

Then something behind the scenes tries to access the attribute on an object 
that has been turned into a fault, and invalidated, and everything comes 
crashing down.

So I have two questions:

1. Is it the "right way" for me to be adding observation on the awake methods 
and removing it on willTurnToFault?

2. If this is OK, then what could be affecting the system such that it doesn't 
remove the observation information in the destination of the to-one 
relationship? I'm wondering if there could be something in my data model that 
could be affecting it. This relationship is modeled as a one to one, with a 
delete rule of cascade from the parent to the child, and the inverse 
relationship is also modeled, with a deny rule. There's also another optional 
relationship from the child to the parent with a deny rule, modeled in one 
direction only (and not used in the data I am testing with anyway).
 

A sample trace:

The NSManagedObject with ID:0x1240033c0 

 has been invalidated.
0   CoreFoundation  0x7fff88f0fcc4 
__exceptionPreprocess + 180
1   libobjc.A.dylib 0x7fff823880f3 objc_exception_throw 
+ 45
2   CoreData0x7fff8836911a 
-[_NSInvalidationFaultHandler fulfillFault:withContext:] + 106
3   CoreData0x7fff8830bdbe 
_PF_FulfillDeferredFault + 254
4   CoreData0x7fff8830fab7 
_sharedIMPL_pvfk_core + 87
5   CoreData0x7fff8830fc28 
-[NSManagedObject(_PFDynamicAccessorsAndPropertySupport) 
_genericValueForKey:withIndex:flags:] + 40
6   CoreData0x7fff883154be -[NSManagedObject 
valueForKey:] + 270
7   Foundation  0x7fff868594e5 
-[NSKeyValueNestedProperty object:didRemoveObservance:recurse:] + 86
8   Foundation  0x7fff86858d3b 
-[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 190
9   Foundation  0x7fff86858c1f 
-[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 135
10  Foundation  0x7fff86859502 
-[NSKeyValueNestedProperty object:didRemoveObservance:recurse:] + 115
11  Foundation  0x7fff86858d3b 
-[NSObject(NSKeyValueObserverRegistration) _removeObserver:forProperty:] + 190
12  Foundation  0x7fff86858c1f 
-[NSObject(NSKeyValueObserverRegistration) removeObserver:forKeyPath:] + 135
13  NMFoundation0x0001002bbe6f -[NMTopicNodeMO 
stopObserving] + 279
14  NMFoundation0x0001002b1f23 -[NMManagedObject 
willTurnIntoFault] + 235
15  NMFoundation0x0001002bc070 -[NMTopicNodeMO 
willTurnIntoFault] + 347
16  CoreData0x7fff88316be0 -[NSFaultHandler 
turnObject:intoFaultWithContext:] + 96
17  CoreData0x7fff88316572 
-[NSManagedObjectContext reset] + 578
18  CoreData0x7fff8836e0d3 
-[NSPersistentStoreCoordinator(_NSInternalMethods) 
_retainedAllMigratedObjectsInStore:toStore:] + 1379
19  CoreData0x7fff8836bb54 
-[NSPersistentStoreCoordinator 
migratePersistentStore:toURL:options:withType:error:] + 676
20  AppKit  0x7fff837fdd5c 
-[NSPersistentDocument 
writeToURL:ofType:forSaveOperation:originalContentsURL:error:] + 432



TIA

Gideon







___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Understanding property/synthesize

[Stefan Nobis]

Quincey Morris  writes:

> The ability to omit the instance variable (called the "non-fragile
> instance variable" mechanism) is a feature of the latest Objective-C
> compilers and runtime, and is available for 64-bit Mac OS x64
> applications, and applications running on an iOS device.

Ah, thanks for the explanation.

> It is not available for 32-bit or PPC applications

So if backwards compatibility is of no concern, there are chances to
get rid of quite some unnecessary code. Nice. Quite a step forward.

-- 
Until the next mail...,
Stefan.
___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: retaining and releasing a Window Controller.

[Quincey Morris]

On Aug 8, 2010, at 23:27, Kevin Bracey wrote:

> I have a Report WindowController, that opens a Window from it's own nib. This 
> is great, I can open lots of different Reports all bases on the same 
> Controller. But I only need the Window and the controller to stay around 
> while the Window is open. It's all self contained and nothing else needs 
> reference it.
> 
> Is it ok to [self retain] in the Controller's init, then [self release] in 
> the - (void)windowWillClose:(NSNotification *)notification. Is that the best 
> place to do this, I'm not at all sure about an object retaining and releasing 
> itself.
> 
> at the moment I'm storing all these reports in an array to stop the 
> controller disappearing out from underneath me and then removing them when 
> the Window closes, I'm sure there's a better way.

Either approach is viable.

There's no inherent reason why an object shouldn't retain and release itself. 
In general, doing so might indicate a design problem (such as an abuse of the 
MVC paradigm), but in specific cases like this you can make an argument that 
it's a natural approach.

OTOH, I'm not sure why you think the array of controllers approach is 
"convoluted". It's also a perfectly natural approach, and it's what NSDocument 
objects do to manage their own window controllers.

In fact, the two approaches are more or less identical. In the second one, 
[windowControllers addObject: newWindowController] has the same purpose as 
[newWindowController retain] in the first one -- to preserve a strong reference 
to the window controller -- and removeObject/release are similarly equivalent 
in purpose.

My choice would actually be the array of controllers approach, because it 
sometime turns out -- further down the line, when your application's UI gets 
refined further -- that you want to know what the list of controllers is, or to 
maintain an ordering for the window controllers. For example, sometimes you 
want to manipulate the appearance of the Window menu's list of open windows, 
and you need to control what that list should look like. Even if you never need 
to consult the list, you're only wasting (basically) one line of code -- to 
create the array initially -- although in practice I'd make the list be a 
property of the app delegate in order to regularize the access.


___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: retaining and releasing a Window Controller.

[Negm-Awad Amin]

That one, who creates the WC is the owner (probably the App-Delegate or a 
document). It should retain the WC. The WC can send a message to the owner, 
when its window is closed. (And the owner probably wants to autorelease the WC 
in this case.)

Problem: When the WC is released by its owner after sending a message to its 
owner, the code execution returns to a probably deallocated instance. For that 
reason you should autorelease the WC instead of releasing it or dispatch the 
release through the run loop.

Cheers

Amin Negm-Awad
negm-a...@cocoading.de




Am Mo.,09.08.2010 um 08:27 schrieb Kevin Bracey:

> Hi guys,
> 
> every time I find myself doing something convoluted I think hey I must be 
> doing this wrong:-)
> 
> I have a Report WindowController, that opens a Window from it's own nib. This 
> is great, I can open lots of different Reports all bases on the same 
> Controller. But I only need the Window and the controller to stay around 
> while the Window is open. It's all self contained and nothing else needs 
> reference it.
> 
> Is it ok to [self retain] in the Controller's init, then [self release] in 
> the - (void)windowWillClose:(NSNotification *)notification. Is that the best 
> place to do this, I'm not at all sure about an object retaining and releasing 
> itself.
> 
> at the moment I'm storing all these reports in an array to stop the 
> controller disappearing out from underneath me and then removing them when 
> the Window closes, I'm sure there's a better way.
> 
> Cheers
> Kevin___
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de
> 
> This email sent to negm-a...@cocoading.de

___

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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