Re: Is there a Source List control in Cocoa

2008-04-01 Thread Markus Spoettl

On Apr 1, 2008, at 5:50 PM, Rob Napier wrote:
It won't exactly match Mail or iTunes, but the new Leopard way of  
doing what you're talking about is to use an NSTableView or  
NSOutlineView and call:


   [tableView  
setSelectionHighlightStyle:NSTableViewSelectionHighlightStyleSurceList 
]



Great, thanks Rob!

Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: Is there a Source List control in Cocoa

2008-04-01 Thread Markus Spoettl

On Apr 1, 2008, at 5:57 PM, Rob Keniger wrote:


http://developer.apple.com/samplecode/SourceView



Excellent, thanks Rob!

Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Question about NSTreeController/NSOutlineView instance cleanup

2008-04-10 Thread Markus Spoettl

Hi,

  I have a simple test application (modeled after the SourceView  
sample) which is a NSDocument based application. The NSDocument  
derived class contains a root NSMutableArray which serves as the  
content for an NSOutlineView which is attached to the content through  
binding.


@interface MyDocument : NSDocument {
[...]
NSMutableArray *treeContent;
[...]
}

treeContent is never accessed directly (except for initialization and  
deallocation), it's managed by a NSTreeController instance that is  
part of the document's nib file.


The problem now is i -(void)dealloc: for MyDocument:

- (void)dealloc
{
[treeContent release];

   [super dealloc];
}

This causes the following debugger log:

--
2008-04-10 17:50:02.641 AppDocTest[7852:813] An instance 0x160ad0 of  
class TreeNode is being deallocated while key value observers are  
still registered with it. Observation info is being leaked, and may  
even become mistakenly attached to some other object. Set a breakpoint  
on NSKVODeallocateBreak to stop here in the debugger. Here's the  
current observation info:

NSKeyValueObservationInfo 0x1690a0 (
NSKeyValueObservance 0x167a30: Observer: 0x160c20, Key path:  
children, Options: New: NO, Old: NO, Prior: NO Context: 0xa00be78c,  
Property: 0x160530
NSKeyValueObservance 0x1677d0: Observer: 0x160c20, Key path: isLeaf,  
Options: New: NO, Old: NO, Prior: NO Context: 0xa00be78c, Property:  
0x14f140

)
--

If I interpret this correctly I'm removing my tree content from under  
the NSTreeController while it's still using it. If found that when I add


[treeContent removeAllObjects];

before [treeContent release] this log entry goes away, but I'm not at  
all convinced this is the right procedure. So what is? How do I tell  
the NSTreeController to remove all ties to my nodes because we are  
shutting down?


I'm very new to Cocoa so there might be something I did wrong in the  
setup. I very closely followed the SourceView sample though which  
works with a NSWindowController instead of NSDocument and does not  
produce this log entry) Thanks for any pointers.


Regards
Markus
--
__
Markus Spoettl
___

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 [EMAIL PROTECTED]


Re: Question about NSTreeController/NSOutlineView instance cleanup

2008-04-10 Thread Markus Spoettl

On Apr 10, 2008, at 6:07 PM, Markus Spoettl wrote:
If I interpret this correctly I'm removing my tree content from  
under the NSTreeController while it's still using it. If found that  
when I add


   [treeContent removeAllObjects];



Small correction this (calling removeAllObject) doesn't remove the  
problem, I don't know why it appear that way at first. Overall it  
makes more sense that way because I guess that it would be called  
automatically when disposed of.


So the question remains, how to tell NSTreeController to release all  
ties to the node hierarchy so it can be cleaned up?


Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: Question about NSTreeController/NSOutlineView instance cleanup

2008-04-10 Thread Markus Spoettl
The first thing to check is how you are initializing the treeContent  
variable. What method are you using to create it, and are you  
retaining it?


OK, this is what I do:

- (id)init
{
self = [super init];
if (self) {
treeContent = [[NSMutableArray alloc] init];
}
return self;
}

- (void)dealloc
{
[treeContent release];
[super dealloc];
}

I thought I don't have to retain treeContent since I automatically do  
that with alloc-init, right?


When treeContent is released, I assume it automatically releases all  
TreeNode objects in it and that's what is reported in the log entry to  
be unexpected. I get as many warnings as root node entries in  
treeContent but none for child objects further down the hierarchy.


Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: Question about NSTreeController/NSOutlineView instance cleanup

2008-04-11 Thread Markus Spoettl

On Apr 10, 2008, at 8:48 PM, Quincey Morris wrote:
Perhaps the controller is not getting released when it should. Do  
you have an instance variable for the controller too? If so, how is  
that retained/released? You could probably avoid the error by  
sending a setContent:nil message to the controller in the  
document's dealloc, but that would just be papering over the problem.


Agreed. The NSTreeController does have an outlet on the NSDocument  
class but it's not retained/released there as it's managed through the  
nib management (at least that's what I thought).


Or perhaps the objects in treeContent are all getting overreleased.  
That could cause the error messages you're seeing.



Yes that must be it. I'm not sure how I manage to do that, though.  
Basically what I do is this:


  NSIndexPath *location = [NSIndexPath indexPathWithIndex: 
[treeContent count]];


  TreeNode *rootnode = [[TreeNode alloc] init];
  ... set treenode properties ...

  [treeController insertObject:rootnode  
atArrangedObjectIndexPath:location];


  ... do something that involves rootnode like adding sub-nodes ...

  [rootnode release]

The treeController will retain rootnode at the time insertObject is  
called and also adds rootnode to treeContent. Again, at least that's  
what I thought. There is no other place in the code that deals with or  
releases/retains TreeNode objects.


Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: Question about NSTreeController/NSOutlineView instance cleanup

2008-04-11 Thread Markus Spoettl

On Apr 11, 2008, at 12:10 AM, Quincey Morris wrote:
Well, without knowing the details of what you're doing, it's  
impossible to be certain, but this code certainly looks *very*  
wrong. For one thing, 'insertObject' is (according to the  
documentation) for controller subclasses to use to customize their  
own behavior, not for other things to use to insert objects.  
Normally, you don't want to mess with trying to change  
arrangedObjects directly.


For another thing, assuming you're approaching this using MVC design  
principles, this code gets things exactly backwards -- when setting  
up your data model, you don't make changes to the controller and  
expect them to be reflected in the model -- you make changes in the  
model and let them be reflected (via the controller) in the view.


Again assuming there's nothing very strange intended here, all you  
need to do is update treeContent in a KVO-compliant way, which (in  
the case of arrays) is:


	[[myDocument mutableArrayValueForKey:@treeContent]  
addObject:rootnode];


(or some variant such as insertObject...) and the tree controller  
will see the change and update the user interface.


There are also other ways to change treeController in a KVO- 
compliant way, but mutableArrayValueForKey seems the most direct in  
this case.



OK, thanks for the input, I'll try make sense of all this later today.  
The NSTreeController/structure code was copied/used from the Apple- 
supplied sample project SourceView


  http://developer.apple.com/samplecode/SourceView

and I thought they would know what they're doing. I'm not sure what to  
think now. Anyway, thanks again!


Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: Question about NSTreeController/NSOutlineView instance cleanup

2008-04-11 Thread Markus Spoettl

On Apr 11, 2008, at 12:10 AM, Quincey Morris wrote:
Well, without knowing the details of what you're doing, it's  
impossible to be certain, but this code certainly looks *very*  
wrong. For one thing, 'insertObject' is (according to the  
documentation) for controller subclasses to use to customize their  
own behavior, not for other things to use to insert objects.  
Normally, you don't want to mess with trying to change  
arrangedObjects directly.


For another thing, assuming you're approaching this using MVC design  
principles, this code gets things exactly backwards -- when setting  
up your data model, you don't make changes to the controller and  
expect them to be reflected in the model -- you make changes in the  
model and let them be reflected (via the controller) in the view.


Again assuming there's nothing very strange intended here, all you  
need to do is update treeContent in a KVO-compliant way, which (in  
the case of arrays) is:


	[[myDocument mutableArrayValueForKey:@treeContent]  
addObject:rootnode];


(or some variant such as insertObject...) and the tree controller  
will see the change and update the user interface.


There are also other ways to change treeController in a KVO- 
compliant way, but mutableArrayValueForKey seems the most direct in  
this case.



I got it to work. What you say makes a lot of sense now, thanks very  
much for helping me understand what really was wrong with the code. Of  
course it solved the leaking problem and works really nicely. I'm new  
to the concept that a node (or any object) will change its class to  
something else once added to the KVO structure appropriately and  
learns new things as it's added. It's quite cool.


Thanks again!

Regards
Markus

PS: Question remains why Apple doesn't know how to really do this -  
it's the sample project I got this code from.

--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: warning: Image scaling is not supported on Mac OS X versions prior to 10.5.

2008-04-14 Thread Markus Spoettl

On Apr 14, 2008, at 9:09 AM, Nathan Vander Wilt wrote:
This means your NIB/XIB has a deployment target not equal to  
10.5.x, but you have some sort of button or other view whose  
Scaling setting is not None. If you go into Interface Builder,  
and go to your file's Info window, it will show a list of all these  
warnings. Either change your deployment target, or click each  
warning to pull up the problematic view in the inspector window and  
set its Scaling to None. It may be alright to ignore these  
warnings, I don't know.



The real problem with this as I see it is that it happens with a  
default project with no changes. Create a new Cocoa application, open  
the NIB and add a Push Button/NSButton on the window. You'll get a NIB  
warning the OP describes immediately. Bad default settings in my  
opinion.


In order to make the warning go away you can either set the build  
target for the NIB file to 10.5 or set the Scaling attribute to  
none for the button. Neither of this is immediately obvious to  
newbies like myself because you would assume things like that just  
work.


What I've been wondering: What happens if I get a warning like this,  
switch my build target to 10.5 and the final application runs on a pre  
10.5 system? Will it crash, will the scaling functionality just don't  
work or will the user get lots of error messages when starting the  
application?


Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


NSTreeController and NSOutlineView: How do I get to the outline view's item

2008-04-15 Thread Markus Spoettl

Hi,

  this probably sounds terribly stupid but apparently I can't find  
this out on my own so here I am asking for help again:


I have a NSDocument subclass with a simple tree structure attached to  
an NSOutlineView via NSTreeController and bindings. I learned -  
through this list - to add items in KVO compliant way like this


 TreeNode *node = [[TreeNode init] alloc];
 [[self mutableArrayValueForKeyPath:@treeContent] addObject:node];

this works very well the NSOutlineView gets updated and displays the  
structure I fill into my model.


The only thing that I can't seem to figure out is how to get to the  
NSOutlineView's item for a specific node that was added. Say I want to  
expand or collapse a specific node when it's added:


  [myOutlineView expandItem:node];

does not work - I believe because it's the model's data object not the  
item that represents it in the OutlineView (right?).


So how do I determine the outline item for a data node? I hope this  
makes any sense at all. I feel like a bloody beginner.


Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: NSTreeController and NSOutlineView: How do I get to the outline view's item

2008-04-16 Thread Markus Spoettl

On Apr 16, 2008, at 12:18 AM, Quincey Morris wrote:
If you're doing this in the context of populating the data model  
(e.g. creating nodes when initializing a new document), you'd  
probably want to do it by brute force: create the model data, then  
examine suitable rows of the outline view (possibly all of them),  
expanding the ones that correspond to a model object that needs to  
be expanded. In your scenario, the outline view items are NSTreeNode  
objects provided by the tree controller, and the NSTreeNode's  
representedObject is your model object -- a TreeNode, I guess.



representedObject is what I couldn't find. Thanks very much once again!

Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Custom View initialization: where?

2008-05-02 Thread Markus Spoettl
Following the View Programming Guide for Cocoa if I use a Custom- 
View proxy in IB, the view's initWithFrame: method will be called when  
the NIB is loaded (this can be found in Initializing View Instances  
Created in Interface Builder).


I do have a custom NSView derived view and a simple window with one  
proxy custom view in it. The class name is set to my view's class, but  
the initializer does not get called. awakeFromNib: is called, though.


Is this a documentation error or is there something I have to do  
before the dedicated initializer is getting called by the framework?  
My view has a couple of objects it has to allocate, the initializer  
being the best place.


I'm using Xcode 3.0 on 10.5.2

Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: Custom View initialization: where?

2008-05-02 Thread Markus Spoettl

On May 2, 2008, at 7:11 PM, Graham Cox wrote:

Sounds OK - so post your code. The documentation is correct.



Well the code is totally straight forward:

@interface MyView : NSView {
MyObjectData *data;
}

@property (readonly) MyObjectData *data;

- (id)initWithFrame:(NSRect)frame;

@end


@implementation MyView

@synthesize data;

- (id)initWithFrame:(NSRect)frame {
self = [super initWithFrame:frame];
if (self) {
data = [[MyObjectData alloc] init];
}
return self;
}

@end

The view is instantiated correctly because it draws right. When I put  
the debugger breakpoint in initWithFrame: it doesn't get called. Is  
there something wrong with this?


Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Multi-window document app: How to only show the main window when opening

2008-05-14 Thread Markus Spoettl

Hello,

  I have an NSDocument based application with multiple  
NSWindowControllers that visualize different aspects of the document.  
One is the main view and this is the only one that should be visible  
by default. The question is how does one do that?


When I create all window controllers in  
MyDocument:makeWindowControllers: all contained windows become visible  
immediately.


I've tried moving the creation of secondary NSWindowControllers out of  
makeWindowControllers: to the point where they're first needed (an  
IBAction message) using this code:


   if (!trackView) {
trackView = [[TrackViewController alloc]  
initWithWindowNibName:@TrackView];
[[self document] addWindowController:trackView]; // self is  
the main NSWindowController

[trackView setShouldCloseDocument:NO];
   }
   // make trackView show/hide windows now

but for reasons I don't understand the window will never show up. The  
nib doesn't seem to get loaded - at least  
TrackViewController:awakeFromNib: is never called. Thus I thought  
window controllers in a document based app may have to be created  
within MyDocument:makeWindowControllers:. Sounds wrong to me but what  
do I know.


If so, how can I hide the secondary windows by default (note that  
Visible at launch is switched off in IB for all windows in the  
application). Or alternatively defer the creation of secondary  
NSWindowControllers?


Any insight would be much appreciated!

I'm using Xcode 3.0 on 10.5.2

Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


releasing NSKeyedUnarchiver causes crash

2008-05-18 Thread Markus Spoettl

Hi all,

  once again I have a question I can't seem to figure out on my own.

I'm trying to implementing an NSDocument application, more  
specifically the load/store part of it. It actually works as expected,  
reading and writing my object graph to and from a file works fine. The  
problem is that when releasing the NSKeyedUnarchiver instance used to  
read the data, the application crashes - and I don't know why.


This is the exact code I'm using (tracks is an object that conforms to  
 NSCoding )


- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
NSMutableData *data = [[NSMutableData alloc] init];
NSKeyedArchiver *archiver = [[NSKeyedArchiver alloc]  
initForWritingWithMutableData: data];

[archiver setOutputFormat: NSPropertyListBinaryFormat_v1_0];
[archiver encodeObject:tracks forKey: @myobject];
[archiver finishEncoding];
[archiver release];
return [data autorelease];
}

- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error: 
(NSError **)outError

{
*outError = nil;
NSKeyedUnarchiver *archiver;
archiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:  
data];


// release current data
[tracks release];
tracks = [archiver decodeObjectForKey: @myobject];
[tracks retain];
[archiver release]; // --- crash here, no crash if commented out
return YES;
}

The crash happens when [archiver release] is called. Since I own the  
object I have to release it and in my understanding it should no  
longer be necessary (the reading is finished at that point).  
Furthermore Leaks reports a leak if archiver is not released (which  
seem to be perfectly valid).


I've also tried [archiver autorelease] but that only delays the crash  
a little.


I don't understand the mistake I'm making, please help. Thanks!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: releasing NSKeyedUnarchiver causes crash

2008-05-18 Thread Markus Spoettl

On May 18, 2008, at 5:25 AM, Klaus Backert wrote:
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName  
error:(NSError **)outError

{
   *outError = nil;
   NSKeyedUnarchiver *archiver;
   archiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:  
data];


   // release current data
   [tracks release];
   tracks = [archiver decodeObjectForKey: @myobject];
   [tracks retain];


may be because this is missing:

[archiver finishDecoding];



That wasn't it but thanks for helping.

The real reason was that I forgot to retain the objects decoded in  
tracks:initWithCoder: after decoding, so instead of


  timeStamp = [[decoder decodeObjectForKey:@timeStamp] retain];

I had

  timeStamp = [decoder decodeObjectForKey:@timeStamp];

and apparently the NSKeyedUnarchiver was the only think keeping that  
data alive.


Well, I apologize for wasting your time.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: releasing NSKeyedUnarchiver causes crash

2008-05-18 Thread Markus Spoettl

On May 18, 2008, at 1:53 PM, Jonathan Dann wrote:
Sorry if I've told you things you know already and there was another  
perfectly valid reason for doing what you did.



Actually it's a good question why I didn't use a property. I'm using  
properties all the time - one of the reasons being the automatic  
retain release handing. thanks for pointing that out.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Is there an NSCollectionView selection change notification?

2008-05-18 Thread Markus Spoettl

Hello List,

  I've started playing with NSCollectionView and everything worked  
out beautifully (custom views, selection state handling for items  
etc.). One thing I can't figure out is how my application/document  
gets notified about a change of selection.


I could go through the NSCollectionViewItem:setSelected: property  
setter (which I'm implementing to probagate the selected state to the  
view) and notify the proper authorities in my application. However,  
that just isn't proper design and there must be a much better  
solution. There is no documentation on delegate methods or  
notifications for NSCollectionView, so I'm wondering how one gets  
notified about things like that.


I have a feeling there's something I'm overlooking here. Is there?

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Is there an NSCollectionView selection change notification?

2008-05-18 Thread Markus Spoettl

On May 18, 2008, at 8:36 PM, Jens Alfke wrote:
I've started playing with NSCollectionView and everything worked  
out beautifully (custom views, selection state handling for items  
etc.). One thing I can't figure out is how my application/document  
gets notified about a change of selection.


If you bind the collection view to an NSArrayController, you can  
observe the controller's selection-related properties, either  
programmatically or by using bindings in IB. For example, you can  
bind a button's enabled property to the controller's canRemove,  
to enable the button only when there's a selection.


Up until now I've tried to stay away from manual KVO, the complexity  
of things is overwhelming as it is. However, I have to say it's rather  
elegant and works perfectly for this case. Just to be sure I did  
things right, this is what I came up with:


@implementation MyCollectionViewController

- (void)dealloc
{
[arrayController removeObserver:self  
forKeyPath:@selectedObjects];

[super dealloc];
}

-(void)awakeFromNib
{
[arrayController addObserver:self forKeyPath:@selectedObjects
 options:NSKeyValueObservingOptionNew  
context:nil];

}

- (void)observeValueForKeyPath:(NSString *)keyPath
  ofObject:(id)object
change:(NSDictionary *)change
   context:(void *)context
{
// do whatever necessary here
}

Does this look OK, especially, is removeObserver: in dealloc: not too  
late?


Thanks for you help!

Regards
Markus
--
__
Markus Spoettl

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 [EMAIL PROTECTED]

Re: Is there an NSCollectionView selection change notification?

2008-05-19 Thread Markus Spoettl

On May 18, 2008, at 11:43 PM, Jens Alfke wrote:
Does this look OK, especially, is removeObserver: in dealloc: not  
too late?


Yup, that looks fine.


Excellent, thanks!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

NSCollectionView problems

2008-05-23 Thread Markus Spoettl

Hello List,

  I have an NSCollectionView set up with bindings to visualize an  
NSMutableArray. When I call arrayController:setContent: the view  
(which initially doesn't have a content assigned) displays the items.  
So far so good. The problems are these:


If there are two many items for one page to display, the vertical  
scroller appears. However, it's not the correct size. It's displayed  
as if all items would fit into the view (all but an imaginary 10 pixel  
row). It doesn't get the correct size until after the view is resized.  
Is there some way to force the view to recalculate it's scroll bar  
sizes? Or could this be caused by how the content is assigned (I'm  
using an array controller)?


The second problem is when the view is resized (due to window resizing  
or any other reason). When the collection view is scrolled down with  
some item in the middle of the collection selected (so the scrollbar  
is not on it's topmost position), the resize causes the collection  
display to jump to the first item row. This problem can be observed in  
the Apple supplied IconCollection demo. Is there a way to prevent that?


Thanks for any input!

I'm using Xcode 3.0 on 10.5.2

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSCollectionView problems

2008-05-24 Thread Markus Spoettl

Hello again,

On May 23, 2008, at 1:20 PM, Markus Spoettl wrote:
 I have an NSCollectionView set up with bindings to visualize an  
NSMutableArray. When I call arrayController:setContent: the view  
(which initially doesn't have a content assigned) displays the  
items. So far so good. The problems are these:


If there are two many items for one page to display, the vertical  
scroller appears. However, it's not the correct size. It's displayed  
as if all items would fit into the view (all but an imaginary 10  
pixel row). It doesn't get the correct size until after the view is  
resized. Is there some way to force the view to recalculate it's  
scroll bar sizes? Or could this be caused by how the content is  
assigned (I'm using an array controller)?


The second problem is when the view is resized (due to window  
resizing or any other reason). When the collection view is scrolled  
down with some item in the middle of the collection selected (so the  
scrollbar is not on it's topmost position), the resize causes the  
collection display to jump to the first item row. This problem can  
be observed in the Apple supplied IconCollection demo. Is there a  
way to prevent that?



For those interested, both issues go away if Automatically Hide  
Scrollers is switched OFF for the enclosing scroll view. I had  
scrollers switched off by default for esthetic reasons. Apparently  
NSCollectionView can't handle that case properly.


Does anyone know is this a known issue? If not I'd be glad to file a  
report.


Regards
Markus
--
__
Markus Spoettl

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 [EMAIL PROTECTED]

Weird NSInvocationOperation init behavior

2008-05-31 Thread Markus Spoettl

Hello List,

  I just came across a strange thing with initializing an  
NSInvocationOperation object that I wanted to share and see if this is  
a bug in either the docs or the framework:


I had this

NSInvocationOperation *theOp = [[NSInvocationOperation alloc]
   initWithTarget:self
 selector:@selector(func1:)
   object:nil];

func1 is a parameter-less method of self. The docs state that  
selector: can either have 0 or 1 parameters, in case of 0 object has  
to be nil. That's the case. However, the initialization always failed  
and theOp was nil when after the call. I had a feeling something  
wasn't right and tried this:


NSInvocationOperation *theOp = [[NSInvocationOperation alloc]
   initWithTarget:self
 selector:@selector(func2:)
   object:anObject];

func2 had 1 parameter (type id). Voila, it worked.

The question is, was this my fault?

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Weird NSInvocationOperation init behavior

2008-05-31 Thread Markus Spoettl

On May 31, 2008, at 1:19 AM, Michael Vannorsdel wrote:

If you method is something like:

- (void)func1

then you should use @selector(func1) without the colon.



Indeed. Thank you.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Converting string to double: NSString or NSScanner

2008-05-31 Thread Markus Spoettl

Hello List,

  I'm having troubles deciphering the documentation. I have doubles  
stored in a text file which always use the dot . as decimal  
separator. When converting the strings to doubles the conversion to be  
locale independent. The NSString:doubleValue documentation says:


 This method uses formatting information stored in the non-localized  
value;
 use an NSScanner object for localized scanning of numeric values  
from a string.


Formatting information stored in the non-localized value is really a  
little cryptic - what formatting information and where is the non- 
localized value stored. The part about NSScanner indicates that  
NSString:doubleValue is what I want, is it?


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Converting string to double: NSString or NSScanner

2008-06-01 Thread Markus Spoettl

On May 31, 2008, at 9:35 PM, Michael Vannorsdel wrote:
Basically NSString's floatValue and doubleValue methods only work  
when the numbers use the US style dot separator (as opposed to other  
locale separators such as a comma).  If your NSString might contain  
non-US separators (or other formatting differences) you'll have to  
use NSScanner to do a localized scan of the NSString to extract the  
correct number.  If you tried to use NSString's doubleValue on  
something like 12,34 you would get 12.000.



OK, thanks for confirming that. US-style is exactly what I need.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSArray

2008-06-01 Thread Markus Spoettl

On Jun 1, 2008, at 5:02 PM, Nathan wrote:

int x;
- (IBAction)addNew:(id)sender {
NSString *temp = @Enter Todo Item Here;
   [Items addObject: temp];
x=[Items count];
[label setIntValue: x];
[tableView setDataSource: Items];
[tableView reloadData];
}

Items is a mutable array. label is a label for debugging.  
tableView is a tableview. When addNew is called, I want an object  
with the value of temp added to array items. Then the tableView  
needs updating, so that it is displaying all items in the array. The  
code runs, I know my connections are good, but nothing happens. So I  
added the label who's connection I also know is good to make sure  
the items are getting added to the array and they aren't. When the  
button is pressed, no matter how many times, label always equals  
zero. What's wrong?


Not sure without seeing the rest of your code but if Items is nil that  
would cause exactly the behavior your are seeing. You can message nil  
objects (will will not cause a crash) and the return values will  
basically be some form of 0 (depending on the return type of methods),  
so [Items count] will return zero.


Are you initializing Items at some point? It should be something like:  
Items = [[NSMutableArray] alloc] init];.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

How to TAB away from an NSCollectionView

2008-06-02 Thread Markus Spoettl

Hello List,

I have a problem with NSCollectionView being a dead end for keyboard  
focus cycling. When pressing TAB the keyboard focus switches to the  
next suitable view until the NSCollectionView gets the focus. The  
cycle stops there and I can only use the mouse to set the focus  
somewhere else.


I've already tried to set the next key view explicitly using  
setNextKeyView on the collection view and the collection view's items  
don't become first responder (acceptsFirstResponder returns NO).  
Anything else that needs to be done to make the collection view play  
nice with TAB focus cycling?


The behavior is also visible in Apple's IconCollection demo at 
http://developer.apple.com/samplecode/IconCollection/index.html

Regards
Markus
--
__
Markus Spoettl

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 [EMAIL PROTECTED]

Re: How to implement window fade-in fade-out effects

2008-06-04 Thread Markus Spoettl

On Jun 3, 2008, at 11:25 PM, Brian Christensen wrote:

On Jun 4, 2008, at 2:01 , Markus Spoettl wrote:
The window's frame is an animatable property, so you could try  
something like this:



WOW that is very impressive. I didn't imagine it was that easy, thanks  
so much for the quick help!


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: How to implement window fade-in fade-out effects

2008-06-04 Thread Markus Spoettl

On Jun 4, 2008, at 8:32 AM, Sean McBride wrote:
That'll work, but in my experience if any of the controls in the  
window
make use of 'autoresizing springs' then they will resize incorrectly  
if

starting from a window size smaller that the control's minimum size.



I'll keep that in mind, thanks for mentioning. The window that I  
animate doesn't resize and the controls on it don't use springs so it  
appears to be safe in this respect.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Using NSTrackingArea on overlay child windows

2008-06-08 Thread Markus Spoettl

Hello List,

  I have the following code which works as expected on a normal  
NSView in a normal window. However it does not work when used on a  
view hosted on a completely transparent overlay window. The overlay is  
a child window of a normal NSDocument main window in case that  
matters. I've tried to make the overlay non-transparent to see if that  
causes it but it doesn't make any difference. MyView cursorUpdate: is  
never called.


Is there something wrong with my code or is there a chance tracking  
areas don't work on child windows?


Thanks for any pointers.

Regards
Markus

@implementation MyView

- (void)cursorUpdate:(NSEvent *)theEvent
{
NSLog(@cursor updated);
[[NSCursor openHandCursor] set];
}

- (void)updateTrackingRect
{
if (cursorTrackingArea) {
[self removeTrackingArea:cursorTrackingArea];
[cursorTrackingArea release];
cursorTrackingArea = nil;
NSLog(@tracking area removed);
}

NSRect rect = NSInsetRect([self bounds], 6, 6);
if ((rect.size.width  1)  (rect.size.height  1)) {
cursorTrackingArea = [[NSTrackingArea alloc]
  initWithRect:rect
   options:(NSTrackingCursorUpdate |  
NSTrackingActiveInActiveApp)

 owner:self userInfo:nil];
[self addTrackingArea:cursorTrackingArea];
NSLog(@tracking area updated);
}
}

@end
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Using NSTrackingArea on overlay child windows

2008-06-08 Thread Markus Spoettl

On Jun 8, 2008, at 5:57 PM, Ron Fleckner wrote:
I think you need to explicitly set the transparent window as  
accepting first responder.  By default, borderless windows aren't  
included in the repsonder chain.



I think you are right. I did some experimenting and it appears the  
updateCursor: message is only sent to the view if its window is key.  
That's a problem in my case because the window is not and cannot  
become key.


Anyway, thanks for your help.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Using NSTrackingArea on overlay child windows

2008-06-09 Thread Markus Spoettl

On Jun 8, 2008, at 10:59 PM, Ron Fleckner wrote:
Is updateCursor: a Leopard thing?  I'm still on Tiger and there's no  
such method on my machine that I could find.  If it is your own  
method, why can't you just call it yourself?  I guess I don't really  
understand your problem.



Yes it's new in Leopard. Register a tracking area with  
NSTrackingCursorUpdate and the updateCursor: event will be triggered  
when necessary (see link for details)


http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/chapter_7_section_5.html

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSSplitview. Stopping the split moving

2008-06-14 Thread Markus Spoettl

On Jun 14, 2008, at 4:15 PM, Steven Hamilton wrote:
I have an NSplitview similar to Mails. I'm trying to fix the split  
so it doesn't move just like Mail but can't for the life of me  
figure out how to do it. My left split has an Outlineview and the  
right split a tableview. Resizing the window always moves the split  
upsetting the visual appearance of the sourcelist in the left split.



You can do this by implementing the resizeSubviewsWithOldSize delegate  
method, here is what I do. I have 2 views left is flexible in width,  
right has fixed width.


- (void)splitView:(NSSplitView *)sender resizeSubviewsWithOldSize: 
(NSSize)oldSize

{
NSRect newFrame = [sender frame];
CGFloat dt = [sender dividerThickness];

// this is the fixed view (right)
// on top on being fixed it is also collapsible
NSRect rightFrame = [rightView frame];
// this is the flexible view (left)
NSRect leftFrame = [leftView frame];

rightFrame.size.height = newFrame.size.height;
leftFrame.size.height = newFrame.size.height;

if (![splitView isSubviewCollapsed:rightView]) {
rightFrame.origin.x = newFrame.size.width -  
rightFrame.size.width;

rightFrame.origin.y = 0;

leftFrame.origin = NSMakePoint(0,0);
leftFrame.size.width = newFrame.size.width -  
rightFrame.size.width - dt;

} else {
rightFrame.origin.x = newFrame.size.width;
rightFrame.origin.y = 0;
rightFrame.size.width = 0;

leftFrame.origin = NSMakePoint(0,0);
leftFrame.size.width = newFrame.size.width - dt;
}
[leftView setFrame: leftFrame];
[rightView setFrame:rightFrame];
}

The code above is a little modified from what I actually use and I  
didn't compile it so it might need change. Also it can be condensed  
considerably. Also note that you may need to implement  
canCollapseSubview, constrainMaxCoordinate and constrainMinCoordinate  
depending on what exactly you're trying to achieve.


The main disadvantage when doing this (as far as I can see) is that  
you're responsible for correctly setting up all the child view frames.  
The split view prints debug logs when you do something that is  
completely wrong, so that helps.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

How to disconnect bound views temporarily

2008-06-15 Thread Markus Spoettl

Hi List,

  I have a document window that can show the same data in more than  
one way, very much like Finder, one view mode is an outline, the other  
is a collection. Both are bound to the same data, so they reflect  
changes automatically.


I was wondering if there is some way to tell a controller class (like  
NSArrayController) to temporarily disconnect the bound view from the  
data (other than removing the binding itself). It seems that the views  
are updating the data even if they are not visible, consuming memory  
and processor time. Moreover, NSCollectionView does seem to have  
problems when it's not visible and the data changes (I get debug log  
entries about assertion failures in NSView lockFocus).


Thanks
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: How to disconnect bound views temporarily

2008-06-17 Thread Markus Spoettl

On Jun 15, 2008, at 8:26 AM, Andy Mroczkowski wrote:
I'm guessing that your NSArrayController is in the nib itself.  One  
thing you could do is instantiate it programmatically and set it as  
an ivar of some other controller class in the nib (lets call it  
MyWindowController).  Then bind the views to the  
MyWindowController.arrayController.arrangedObjects (or whatever the  
applicable keypath is).


When your view is hidden, you can set  
MyWindowContoller.arrayController to nil and it *should* just work.   
We've used this same pattern in our code, but we're only using the  
arrangeObjects and selectedObjects keypaths of NSArrayController.


I'll give this a try, thanks for the input!

Also, I haven't played with NSCollectionView, but it seems odd that  
it has problems if the data changes when its not visible.  It sounds  
like a bug to me...



Yes.

Thanks again
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

NSKeyedArchiver finishEncoding takes forever

2008-06-18 Thread Markus Spoettl

Hello List,

  I'm having a problem with a performance problem in NSKeyedArchiver  
which I can't find a cause for. Let me first describe the data I'm  
storing:


It's a simple object hierarchy consisting of the following

Root  custom  NSCoding  compliant object
  |-- ANodes  (NSMutableArray)
   |-- A  (custom  NSCoding  compliant object
   |- NNodes  (NSMutableArray)
|- N  (custom  NSCoding  compliant object
   |- 4 double ivars

There is 1 root object with 120 A objects each containing 1000-3000 N  
objects, that makes about 200k N objects in the hierarchy.


For some reason N is causing the performance problem, but in a very  
strange way. The encodeWithCoder method looks like this:


--
- (void)encodeWithCoder:(NSCoder *)encoder
{
[encoder encodeDouble:v1 forKey:@v1];
[encoder encodeDouble:v2 forKey:@v2];
[encoder encodeDouble:v3 forKey:@v3];
[encoder encodeDouble:v4 forKey:@v4];
}
--

v1, v2, v3, v4 are all ivars of N.

It is not the encoding itself that takes so long (the whole hierarchy  
is encoded in less than one second), it's when I call [archiver  
finishEncoding] in my document's dataOfType: which looks like this:


--
- (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError
{
NSMutableData *data = [[NSMutableData alloc] init];

NSKeyedArchiver *archiver = [[NSKeyedArchiver alloc]  
initForWritingWithMutableData: data];

[archiver setOutputFormat: NSPropertyListBinaryFormat_v1_0];

[archiver encodeObject: root forKey:@root];

[archiver finishEncoding];

[archiver release];

[data autorelease];

if ((!data)  (outError != NULL)) {
   *outError = [NSError errorWithDomain:NSOSStatusErrorDomain
   code:unimpErr userInfo:NULL];
}

return data;
}
--

With the above mentioned test data it takes more than 5 minutes on my  
MBP 2.5GHz for finishEncoding to complete.


I've experimented and found the following:

1) When I change the values of v1, v2, v3, v4 to 1.0, 2.0, 3.0 and 4.0  
everything works with acceptable speed (the process takes less than 5  
seconds). It's still saving the same hierarchy, just the numbers  
stored are different. How can that be?


2) I also noticed that when I use the NSPropertyListXMLFormat_v1_0  
instead of binary, the process speeds up considerably, taking just  
below 10 seconds. The problem with this is that the output file is  
huge (100 MB) which is too big for my purposes. Also, decoding the XML  
data is much slower than with binary data.


3) I've tried converting the doubles to strings and encode those. This  
also is a lot faster, almost as fast a with straight double values.


I've found nothing on Google or the list archives with respect to  
performance of NSArchiver and I'm puzzled. Also instruments isn't  
telling me much except that flattenProperties (if I recall  
correctly) is what most of the time is going.


What am I doing wrong? Thanks for any pointers!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSKeyedArchiver finishEncoding takes forever

2008-06-18 Thread Markus Spoettl

On Jun 18, 2008, at 11:25 AM, Kyle Sluder wrote:

On Wed, Jun 18, 2008 at 2:13 PM, Markus Spoettl
[EMAIL PROTECTED] wrote:
2) I also noticed that when I use the NSPropertyListXMLFormat_v1_0  
instead
of binary, the process speeds up considerably, taking just below 10  
seconds.
The problem with this is that the output file is huge (100 MB)  
which is too
big for my purposes. Also, decoding the XML data is much slower  
than with

binary data.


Maybe serialize it to an XML plist data object, and then gzip that on
a background thread?  Won't help much with the decompression, I'm
afraid.  Or, you could grap an XML plist blob and then, on a
background thread, reinstate that and write it out again as binary.
This will consume a LOT of memory.  I have this vision that you need
to take a snapshot of the state of your object hierarchy at point X,
so my suggestions might not be that helpful.  It all has to do with
what tradeoffs you're willing to make.


If there is no other solution to it, I may consider this. But I have a  
feeling there's something wrong with the doubles I encode which causes  
the whole mess. Anyway, thanks for the suggestion.



Also, what OS and SDK are you using?



Sorry I forgot. I'm on 10.5.3 using Xcode 3.0 and targeting 10.5+.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSKeyedArchiver finishEncoding takes forever

2008-06-18 Thread Markus Spoettl
	   
CFDictionaryAddValue	
	0.0%	0.0%	CoreFoundation	   
_flattenPlist	
	0.0%	0.0%	CoreFoundation	   
CFSetGetCount	
	0.0%	0.0%	CoreFoundation	   
CFDictionaryGetValue	
	0.0%	0.0%	CoreFoundation	   
CFArrayGetCount	
	0.0%	0.0%	CoreFoundation	   
_CFArrayReplaceValues	
	0.0%	0.0%	CoreFoundation	   
__CFSetFindBuckets1b	
	0.0%	0.0%	CoreFoundation	  
CFDictionaryGetKeysAndValues	
	0.0%	0.0%	CoreFoundation	  
CFDictionaryAddValue	
	0.0%	0.0%	CoreFoundation	  
CFArrayAppendValue	
	0.0%	0.0%	CoreFoundation	  
CFSetAddValue	
	0.0%	0.0%	CoreFoundation	  
CFArrayGetCount	
	0.0%	0.0%	CoreFoundation	  
CFSetGetCount	
	0.0%	0.0%	CoreFoundation	  
CFDictionaryGetValue	
	0.0%	0.0%	CoreFoundation	 
CFStorageGetValues	
	0.0%	0.0%	CoreFoundation	 
CFDictionaryGetKeysAndValues	



--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSKeyedArchiver finishEncoding takes forever

2008-06-18 Thread Markus Spoettl

On Jun 18, 2008, at 1:59 PM, Quincey Morris wrote:
Yes, but look at where the time is *really* being spent. At a guess,  
finishEncoding is comparing every number object against every other  
number object to see if it can archive just one object of each  
distinct numeric value. With the number of objects you said you're  
using, this O(n**2) optimization -- if that's what it's doing -- is  
hideously expensive.



Exactly and the test data isn't particularly big. Any ideas how to  
tell the archiver not to do this with my doubles (that doesn't involve  
conversion to strings and back)?


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSKeyedArchiver finishEncoding takes forever

2008-06-18 Thread Markus Spoettl

On Jun 18, 2008, at 2:50 PM, Quincey Morris wrote:
I suppose you could byte-move each group of 4 doubles in one NSData  
and give that to the archiver instead. Or do it further upstream and  
make a bigger array of numbers in a NSData. (But you'll have to deal  
with endianness and -- egads! -- floating point representation  
issues across architectures yourself.)


Perhaps you could avoid the endianness and representation issues by  
archiving each group of 4 doubles (with a different archive object)  
into a NSData and give that to your main archiver. This sounds like  
it would be slow, but probably not as slow as what you already tried.


I just tried this. It is slower than saving XML (around 10 seconds),  
which is orders of magnitudes faster than without this optimization.


One problem is that each 4 double value object gets blown up to 307  
bytes when in its NSData container. That makes the overall file  
increase from 18MB to 38MB. That's a bit of a problem and compressing  
the data won't make things faster, so that's not an option.


I'll try the further upstream approach, it should lower the memory  
impact but I will pay for that with much slower performance - I'll  
report back how that turns out.


Probably the real answer is that NSKeyedArchiver isn't designed to  
handle such large numbers of objects efficiently.



It's more like lots of numbers rather than lots of objects. It  
doesn't matter whether the doubles are located in separate objects or  
not. Iit would be nice to see a warning in the documentation if such a  
design limitation really exists - it may be a bug.


Anyway thanks for your input!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSKeyedArchiver finishEncoding takes forever

2008-06-18 Thread Markus Spoettl

On Jun 18, 2008, at 2:50 PM, Quincey Morris wrote:
I suppose you could byte-move each group of 4 doubles in one NSData  
and give that to the archiver instead. Or do it further upstream and  
make a bigger array of numbers in a NSData. (But you'll have to deal  
with endianness and -- egads! -- floating point representation  
issues across architectures yourself.)



I've now completed testing the third approach saving each ANode into  
it's own NSData and writing a number of those into the file archive:


Optimization  Write TimeFile Size
- ----
None4:48 min   17.2 MB
4-double NSData 0:10 min   38.3 MB
Upstream NSData 0:15 min   12.1 MB

Surprisingly the file size is 1/3 smaller with the latest approach,  
the save time is still too long but much better than the original  
(almost 5 minutes).


I'm not exactly sure about the speed, blocking the UI for 15 seconds  
isn't the best idea and the real data will be even bigger. So, a cure  
for NSKeyedArchiver's optimization would be great.


Anyway, this is certainly interesting to learn all this, thanks for  
your help!


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSKeyedArchiver finishEncoding takes forever

2008-06-18 Thread Markus Spoettl

On Jun 18, 2008, at 5:04 PM, Adam R. Maxwell wrote:
It's not recommended, but have you tried using old-style archiving  
as another approach?  It used to be considerably faster than keyed  
archiving under some circumstances.



I have thought about trying this until I read it's deprecated since  
10.2. Also they don't play well with changes to the data structure,  
both very good reasons to stay away.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSKeyedArchiver finishEncoding takes forever

2008-06-18 Thread Markus Spoettl

On Jun 18, 2008, at 2:41 PM, Michael Ash wrote:

Although it partially defeats the purpose of using NSCoder, you'll
avoid this whole path if you stuff all four doubles into a single
NSData. Don't forget to use the byte-swapping functions to ensure that
they all have a consistent representation across architectures.



Well, what can I say, you and Quincey Morris are absolutely right.  
This is the way to go.


The same data set takes just 4 seconds to store with a file size of  
17.2MB.


Thanks for all the help guys! For the record I'm posting the code below.

Regards
Markus

- (void)encodeDouble:(double)value forKey:(NSString *)key withCoder: 
(NSCoder *)encoder

{
NSSwappedDouble sd = NSSwapHostDoubleToLittle(value);
[encoder encodeBytes:(const uint8_t *)sd  
length:sizeof(NSSwappedDouble) forKey:key];

}

- (double)decodeDoubleForKey:(NSString *)key withCoder:(NSCoder  
*)decoder

{
double result = 0.0;
NSUInteger retsize;
NSSwappedDouble *sd = (NSSwappedDouble *)[decoder  
decodeBytesForKey:key returnedLength:retsize];

if (retsize == sizeof(NSSwappedDouble)) {
result = NSSwapLittleDoubleToHost(*sd);
}
return result;
}

--
__
Markus Spoettl



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 [EMAIL PROTECTED]

How to hide the divider in a collapsed NSSplitView pane

2008-06-21 Thread Markus Spoettl

Hello List,

  I've done a lot of testing and googling but I can't figure out how  
or even if it is possible to completely hide a divider of a NSSplitView.


Suppose I have a split view setup like this:

   A  B
|--|--|

B is collapsible through a button, not through dragging (there is a  
min and max constraint on the divider too). I have a button that  
toggles the view from collapsed to expanded and back. However, when  
view is collapsed the divider is still visible on the right edge of  
the split view.


I've tried sizing the subviews myself in my own custom SplitView  
subclass - not using NSSplitView's -setPosition: - but even that  
doesn't help. The splitview somehow adjusts the the frames after they  
have been set so the divider stays visible, not matter what you do.


Instruments is an example of an app that has splitters that work like  
I want it. The Extended Details pane toggles on and off using a button  
(on the bottom toolbar). When collapsed there is no divider visible  
and you can expand it by using the button only.


Is that something I can do with NSSplitView? If so, how?

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: How to hide the divider in a collapsed NSSplitView pane

2008-06-21 Thread Markus Spoettl

Hi Milen,

On Jun 21, 2008, at 6:21 PM, Milen Dzhumerov wrote:
A common UI pattern now is to provide a button to show and hide one  
subview or another of a split view, and completely hide the divider  
when the subview between it and the edge of the window is hidden. To  
make it easy for you to do this there is a new - 
splitView:shouldHideDividerAtIndex: delegate method you can  
implement.



Ahhh. That's great, I just tried. Thanks so much for the tip!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: How to hide the divider in a collapsed NSSplitView pane

2008-06-21 Thread Markus Spoettl

On Jun 21, 2008, at 5:53 PM, Andreas Mayer wrote:

The documentation for NSSplitView says:


dividerThickness
Returns the thickness of the divider.

- (CGFloat)dividerThickness

Discussion
You can subclass NSSplitView and override this method to change the  
divider’s size, if necessary.



I guess I didn't think of that, thanks for the tip. There's actually a  
better way that Milen pointed out, though.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: How to hide the divider in a collapsed NSSplitView pane

2008-06-21 Thread Markus Spoettl

On Jun 21, 2008, at 7:53 PM, Andreas Mayer wrote:

There's actually a better way that Milen pointed out, though.


If you don't need to support systems earlier than 10.5, yes.


Yes, that's right. I forgot to mention that.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSKeyedArchiver finishEncoding takes forever

2008-06-22 Thread Markus Spoettl

On Jun 21, 2008, at 11:46 PM, Mark Munz wrote:

I also recommend logging a bug with Apple against this issue. You
shouldn't need to jump through those sorts of hoops with
NSKeyedArchiver.



I did (as requested by an Apple engineer). He told me that this has  
been fixed internally already, he couldn't say when it will be  
released, though.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Sourcelist background colors

2008-06-24 Thread Markus Spoettl

Hello List,

  is there a way to get the background color of an NSOutlineView when  
in sourcelist mode (for both key and non-ket state)? NSColor doesn't  
seem to define the color. If not, is there a way to derive the color  
somehow, by blending or highlighting with another system defined color?


Thanks for any pointers!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Sourcelist background colors

2008-06-24 Thread Markus Spoettl

On Jun 24, 2008, at 1:13 PM, Dave DeLong wrote:

Sourcelist active background color:  RGB(214, 221, 229)  (#d6dde5)
Sourcelist inactive background color: RGB(232, 232, 232)  (#e8e8e8)

I got this by taking two screenshots and using the color palette's
magnifying glass.

This is what you're looking for, right?



Yes and no. Measuring the actual RGB values gives you what your system  
is displaying it with at the moment, not the computation that leads to  
that color - assuming such a computation takes place. Whether or not  
those are fixed values, I don't know. I guess that's part of the  
question (only Apple might be able to answer). I should have been more  
careful when asking. Sorry.


Thanks for your suggestion!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: wrapping multiple IBOutlet objects for reuse

2008-06-24 Thread Markus Spoettl

On Jun 24, 2008, at 1:36 PM, Keary Suska wrote:
I would have each row of controls as a vanilla NSView in a  
separate nib.
Your controller class, which would be the nib owner, could manage  
each set

of controls. You'll need to familiarize yourself with nib loading
(particularly NSNib's methods) and the cocoa drawing system  
(particularly
views and subviews, and the coordinate system), at least. There may  
be more

that I am not thinking of.



In addition to what Keary Suska said, you can use NSViewController to  
manage the custom compound view located it's own NIB. NSViewController  
will manage memory, help with bindings and general management.  
Basically everyhing you would have to do manually otherwise.


NSViewController is available in 10.5.

See http://developer.apple.com/documentation/Cocoa/Reference/NSViewController_Class/Introduction/Introduction.html 
 for more information.


The basic steps are these:

1) create a custom NSViewController derived class (MyViewController)  
which will manage one row of controls in your UI (define outlets for  
one row)


2) create a view XIB/NIB in Xcode and set it up in IB.

3) In IB make sure you set the File's Owner class to your custom  
NSViewController class.


4) Set the view outlet of the File's Owner to your compound view in  
the XIB


5) Add other views, controls buttons and wire them to the outlets in  
the custom controller.


6) Prepare your main UI by setting up a container view that will host  
the compound view and create an outlet for that view (container).


7) In the main controller (the one that embeds the individual rows),  
create an instance of your view controller like this:


  myViewController = [[MyViewController alloc]  
initWithNibName:@MyViewNib bundle:nil];


(release it in -dealloc of that class).

8) Embed the compound view in your container using:

 [container addSubview:[myViewController view]];
 [[myViewController view] setFrame:WHERE_YOUR_WANT_IT];
 [[myViewController view] setHidden:NO];

9) You can also use NSViewControllers representedObject to wire  
bindings or add your own UI management code that loads and saves data.


10) Repeat steps 7-9 for each row you need to display.

In your case you would have an array of MyViewControllers than let you  
access the individual rows.


Hope this helps.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Sourcelist background colors

2008-06-25 Thread Markus Spoettl

Hi Corbin,

On Jun 25, 2008, at 10:28 AM, Corbin Dunn wrote:
Yes. It is a magical NSColor that draws correctly depending on the  
window key-state. Create an NSOutlineView, set it to be a source  
list, and get the -backgroundColor. Keep it around and use it as you  
wish. Be sure to redisplay your view when the window looses key-ness.



Excellent, thanks for the information! Works perfectly.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Sourcelist background colors

2008-06-25 Thread Markus Spoettl

On Jun 25, 2008, at 3:33 PM, Keith Duncan wrote:

Be sure to redisplay your view when the window looses key-ness.


How would this be achieved? I've been trying to figure it out, I'm  
sure there's something simple eluding me.



It appears to me that the view/window will repaint when the hosting  
window looses/gains -isMainWindow status (at least my window does  
that). So all you need to do is using -backgroundColor dynamically,  
whenever you redraw the view. The background color changes  
automatically and you don't have to update manually.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Sourcelist background colors

2008-06-25 Thread Markus Spoettl

On Jun 25, 2008, at 4:09 PM, Corbin Dunn wrote:
That may be a fluke -- certain views might do this, but not all. It  
is best to watch the appropriate notifications for your window:


NSWindowDidBecomeKeyNotification  NSWindowDidResignKeyNotification



My view is a custom NSView subclass, I'm not sure NSView is supposed  
to do this automatically by default. Anyway, thanks for the warning,  
I've changed my view to get notified explicitly.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

NSTrackingArea message lag

2008-06-26 Thread Markus Spoettl

Hello List,

 I have a custom NSView that draws a number of rectangles of  
different heights, overlapping 1 pixel on the left and right edge.  
Each rectangle gets its own tracking area


 NSTrackingAreaOptions opts = (NSTrackingMouseEnteredAndExited |
   NSTrackingActiveInKeyWindow);
 NSDictionary *dict = Dictionary with 2 entries;
 NSTrackingArea *ta = [[NSTrackingArea alloc] initWithRect:rect
   options:opts
 owner:self
  userInfo:dict];
 [self addTrackingArea:ta];

The -mouseEntered and -mouseExited messages are being fired, causing a  
redraw of the view. Everything works nicely with a low number of areas  
(10).


When the number of bars increases to more than 20, there is a visible  
lag between mouse movement and the location that is being redrawn. The  
more areas there are the greater the lag.


The result is that the view redraws an area (highlighting a bar) that  
the mouse passed long ago (up to 1 second and more, depending on the  
bar count).


I have double (quadruple actually) checked that the redrawing is not  
the problem, the view draws very quickly. When the mouse is being  
dragged over the view, the same series of redrawing events is  
completely instant up to a bar count of more than 200. I've even  
completely disabled redrawing as a result of tracking area events and  
the lag is still there. So the drawing is not causing the lag.


My suspicion is that only one (or a very small number) of tracking  
area events are being fired for a view in each run loop cycle (or some  
other limitation with respect to the number of tracking area events  
that can be delivered instantly). That would explain the visible lag  
with greater numbers of areas (thus events). This would explain why  
the events keep coming in in an asynchronous fashion.


I have two questions:

1) Is this a known problem/limitation or is it my fault?

2) Is there a way to cancel tracking area events? Some way to ask the  
system not to fire a tracking event when a new event has arrived prior  
to the delivery of an existing one?


Thanks!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSTrackingArea message lag

2008-06-26 Thread Markus Spoettl

On Jun 25, 2008, at 11:57 PM, Quincey Morris wrote:
These statements are a bit puzzling. What does redrawing mean  
here? Are you talking about what you do inside drawRect:, or what  
you do to cause drawRect: to be invoked? Are you using  
setNeedsDisplay: or setNeedsDisplayInRect: to trigger drawing, or  
some other technique?


Redrawing means setting needsDisplay. I'm using

if (![self needsDisplay]) {
[self setNeedsDisplayInRect:rect];
}

I found the needsDisplay check to speed it up a little. rect is the  
tracking area.


If you literally meant the mouse is being dragged, you weren't  
getting mouseEntered events (they're not sent during dragging unless  
you ask for them, and you didn't ask for them in your tracking area  
options) so what was causing drawing to be requested in that case?


The drag starts with mouseDown: and ends with mouseUp:. In between you  
get mouseDragged: events. Every time such an event arrives, I update  
the internal selection structure and redraw the view accordingly. It's  
exactly the same drawing operation that happens when the tracking area  
messages fire. The same code is executed (using different colors).


If you really completely disabled redrawing, how were you  
detecting lag? The lag you started out with was between mouse moving  
and redrawing, but if nothing was redrawn ... ?


Instant logging to a NSTextField showing an increasing integer  
counter. As tracking areas events arrive at the view, the counter is  
increased and the field is updated. With a higher number (20+) of  
areas, the counter was not in synch with the mouse movement,  
increasing its value well after the mouse has stopped. That means that  
the mouse movement was not in synch with the tracking area event, so  
tracking area events are delayed for some reason.


I'm wondering whether, even when you've suppressed the drawing of  
rectangles, you're still flooding the graphics system with  
setNeedsDisplay... updates, and *that's* what is slowing things down.


Drawing was suppressed, no call to setNeedsDisplay was made in the  
test. There is no flooding the graphics system, so that's not the case.


P.S. An alternative approach might be to use a single tracking area  
for your entire custom view, and do your own rectangle hit testing  
on mouseMoved events that occur inside it.


As I explained in my reply to Graham Cox, the documentation suggests  
that tracking areas are the way to go. There's no apparent reason for  
me not to trust the documentation and per se no reason why the  
system's implementation should be any slower than my own. I'd just be  
implementing tracking areas myself, checking which rectangle the mouse  
is in at the moment and firing events accordingly.


It appears that I'll have to do this. It's not a problem of  
implementation, I was just wondering if there was a reason for it to  
be lagging.


Also using mouseMoved: events requires you to set  
setAcceptsMouseMovedEvents: on the hosting window. That means the  
window has to do something for all views on it when only this one view  
needs tracking. I thought that was a little overkill. Plus tracking  
areas are really elegant.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSTrackingArea message lag

2008-06-26 Thread Markus Spoettl

On Jun 26, 2008, at 2:01 AM, Quincey Morris wrote:
Tracking rectangles were perhaps mostly used for dealing with  
cursors. Tracking areas (NSTrackingArea) are useful for more things.


The NSWindow documentation used to (and I suppose still does)  
discourages use of setAcceptMouseMovedEvents. The mouseMoved events  
generated by tracking areas (NSTrackingMouseMoved option) aren't  
discouraged, because they only occur upon movement inside the  
tracking area, and the mouseMoved message is sent directly to the  
tracking area's owner. You do *not* need to  
setAcceptMouseMovedEvents:YES to use these tracking area mouseMoved  
events. You don't even have to test if the event belongs to the  
view, since you know it does. You just have to do a simple rectangle  
check to find out which of your rects you hit (and with your  
original implementation, don't you still have a few lines of code to  
work out -- from the tracking area in the mouseEntered event --  
which rectangle was hit?).



I must have overlooked the -mouseMoved: feature of tracking areas.  
I've now changed from multiple tracking areas to one big area covering  
the entire view. Doing the rectangle checks myself the view is as  
responsive as expected. Thanks for pointing me in the right direction!


Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: NSTrackingArea message lag

2008-06-26 Thread Markus Spoettl

On Jun 26, 2008, at 5:21 PM, Graham Cox wrote:
you can still (and should) use -setNeedsDisplayInRect:, just don't  
make this conditional on -needsDisplay.


I think to really get to the bottom of the delay problem we'd need  
to see the code in its full context. For example how does your  
drawRect: method know which rect(s) to repaint? Or does it just go  
over the whole lot? There could be many reasons why it's slow.



Unfortunately that's not an option, but it isn't really necessary.  
I've switched to updating the view from -mouseMoved: events doing my  
own hit testing and it works very quickly now, there is no more lag.


Notice the drawing mechanism didn't change, so the drawing wasn't  
causing the lag. I have no other explanation than a strange delay in  
the delivery of tracking area messages. What causes the delay I don't  
know, it's very likely my fault but it's most definitely not the  
drawing code.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSTrackingArea message lag

2008-06-26 Thread Markus Spoettl

On Jun 26, 2008, at 6:11 PM, Kyle Sluder wrote:

Well you've avoided the problem, but you should still remove the
condition on -needsDisplay.  It's semantically incorrect.



I did that (I thought I mentioned that).

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

How can I find the source of random crashes when using debug frameworks

2008-06-27 Thread Markus Spoettl

Hello All,

  I'm trying to hunt down a crash bug for two days now and I'm at a  
complete loss, have finally run out of ideas what else I can try.


I've read the Corbin Dunn's EXC_BAD_ACCESS blog post as well as the  
debugger magic tech note. I turned on debug frameworks,  
NSZombieEnabled and NSAutoreleaseFreedObjectCheckEnabled environment  
variables and since then all hell broke loose. I'm getting crashes  
deep in the frameworks, some called from my code, some seemingly random.


One thing I noticed is that I don't get any Zombie warnings. I don't  
know whether that means that it actually is working as expected (in  
the sense that I'm not over-releasing objects) or that something is  
corrupt and the system is unable to tell me what's going on for some  
reason.


I've reviewed my code over and over again and disabled large portions,  
and while I'm sure there is something wrong that I cause, I have no  
idea how I could be causing crashes like the ones below. If anyone has  
an idea what I can do to get to the source of this, I'd really  
appreciate pointers.


I'm using Xcode 3.0 on 10.5.3. The app uses WebKit and QuartzCore  
frameworks. I'm using the debug build configuration (no default  
settings changed) and I've set up the target to use the debug  
framework suffix and set NSZombieEnabled and  
NSAutoreleaseFreedObjectCheckEnabled to YES in the target's  
environment variables.


Regards
Markus

Example Crash Stack 1

GDB: Program received signal:  “EXC_BAD_ACCESS”.

#0  0x943a9036 in CFEqual
#1  0x94375ac5 in __CFDictionaryFindBuckets2
#2  0x943780cc in CFDictionaryAddValue
#3  0x948c4ddf in _LSCopyDownloadAssessmentDictionaryInternal
#4  0x948c338a in _LSCopyDownloadAssessmentDictionary
#5  0x9579fdc9 in _initDownloadAssessment
#6  0x9579f926 in CFURLResponseCopySuggestedFilename
#7  0x931de91e in -[NSURLResponse suggestedFilename]
#8  0x92bca05b in WebCore::ResourceResponse::doUpdateResourceResponse
#9  0x92b75deb in WebCore::ResourceResponseBase::updateResourceResponse
#10 0x92b75dc2 in WebCore::ResourceResponseBase::mimeType
#11 0x92c3ed23 in WebCore::SubresourceLoader::didReceiveResponse
#12	0x92bc9a00 in -[WebCoreResourceHandleAsDelegate  
connection:didReceiveResponse:]
#13	0x931de81a in -[NSURLConnection(NSURLConnectionReallyInternal)  
sendDidReceiveResponse:]

#14 0x931de76a in _NSURLConnectionDidReceiveResponse
#15 0x9579f645 in sendDidReceiveResponseCallback
#16 0x9579dcde in _CFURLConnectionSendCallbacks
#17 0x9579d63f in muxerSourcePerform
#18 0x943a660e in CFRunLoopRunSpecific
#19 0x943a6cf8 in CFRunLoopRunInMode
#20 0x94e28da4 in RunCurrentEventLoopInMode
#21 0x94e28bbd in ReceiveNextEventCommon
#22 0x94e28a31 in BlockUntilNextEventMatchingListInMode
#23 0x9162d505 in _DPSNextEvent
#24	0x9162cdb8 in -[NSApplication  
nextEventMatchingMask:untilDate:inMode:dequeue:]

#25 0x91625df3 in -[NSApplication run]
#26 0x915f3030 in NSApplicationMain
#27 0x394c in main at main.m:13

Example Crash Stack 2

GDB: Program received signal:  “EXC_BAD_ACCESS”.

#0  0x943a91d5 in CFHash
#1  0x943ac7fb in __CFSetFindBuckets1b
#2  0x943acfdd in CFSetGetValue
#3  0x943a1890 in __CFRunLoopFindMode
#4  0x943a515c in CFRunLoopAddTimer
#5	0x931ba517 in -[NSObject(NSDelayedPerforming)  
performSelector:withObject:afterDelay:inModes:]

#6  0x917d10a5 in -[NSToolbarView windowDidUpdate:]
#7  0x9317954a in _nsnote_callback
#8  0x943879ba in __CFXNotificationPost
#9  0x94387c93 in _CFXNotificationPostNotification
#10	0x931767b0 in -[NSNotificationCenter  
postNotificationName:object:userInfo:]

#11 0x9317fff8 in -[NSNotificationCenter postNotificationName:object:]
#12 0x916ec312 in -[NSWindow update]
#13 0x94414c85 in -[NSArray makeObjectsPerformSelector:]
#14	0x9162eb22 in -[NSApplication(NSWindowCache)  
_updateWindowsUsingCache]

#15 0x9162e955 in -[NSApplication updateWindows]
#16 0x9162e897 in _handleWindowsNeedUpdateNote
#17 0x943a49a2 in __CFRunLoopDoObservers
#18 0x943a5d05 in CFRunLoopRunSpecific
#19 0x943a6cf8 in CFRunLoopRunInMode
#20 0x94e28da4 in RunCurrentEventLoopInMode
#21 0x94e28bbd in ReceiveNextEventCommon
#22 0x94e28a31 in BlockUntilNextEventMatchingListInMode
#23 0x9162d505 in _DPSNextEvent
#24	0x9162cdb8 in -[NSApplication  
nextEventMatchingMask:untilDate:inMode:dequeue:]

#25 0x91625df3 in -[NSApplication run]
#26 0x915f3030 in NSApplicationMain
#27 0x394c in main at main.m:13


--
__
Markus Spoettl



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

List of Indexed Accessor Names for NSMutableArray

2008-06-28 Thread Markus Spoettl

Hello List,

  is there a complete list of indexed accessor names that can be  
implemented? The KVC guides just mentions the basic ones


- (NSUInteger)countOfkey
- (id)objectInkeyAtIndex:(unsigned)theIndex
- (void)getkey:(id *)objsPtr range:(NSRange)range
- (void)insertObject:(id)obj inkeyAtIndex:(NSUInteger)theIndex
- (void)removeObjectFromkeyAtIndex:(NSUInteger)theIndex
- (void)replaceObjectInkeyAtIndex:(NSUInteger)theIndex withObject: 
(id)obj


I had this in my code

- (void)removekeyAtIndexes:(NSIndexSet *)indexes
{
NSMutableArray *kva = [self mutableArrayValueForKey:@key];
[kva removeObjectsAtIndexes:indexes];
}

which caused an endless recursion because [kva  
removeObjectsAtIndexes:] assumes that removeKeyAtIndexes: is the KVC  
implementation for it. Of course it was not. I can't find any mention  
in the documentation about this accessor name.


So, is there complete list of method names or is it just all  
NSMutableArray methods that contain Objects in their name with  
Objects replaced by key ?


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: List of Indexed Accessor Names for NSMutableArray

2008-06-28 Thread Markus Spoettl

On Jun 28, 2008, at 1:03 PM, Kyle Sluder wrote:

And you're surprised that this caused an infinite loop?


As a matter of fact, yes I was until I realized what was happening. I  
read the documentation and there was no mention about this specific  
accessor. That was not the question, though, only an explanation of  
what has happened and why I asked the question I am asking.


The real question is if there is a list of accessor methods that can  
be implemented optionally so you don't run into this accidentially as  
I did.


Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: List of Indexed Accessor Names for NSMutableArray

2008-06-28 Thread Markus Spoettl

On Jun 28, 2008, at 4:06 PM, Clark Cox wrote:

They're listed in the NSKeyValueCoding.h header, but it seems that
they aren't included in the equivalent documentation
(http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/mutableArrayValueForKey: 
).



That's it! This is what the comment for NSMutableArray says. In the  
first paragraph notice that -insertKey:atIndexes: and - 
removekeyAtIndexes: is not in the documentation.


Thanks Clark!

Regards
Markus

From NSKeyValueCoding.h:

1. Searches the class of the receiver for methods whose names  
match the patterns -insertObject:inKeyAtIndex: and - 
removeObjectFromKeyAtIndex: (corresponding to the two most primitive  
methods defined by the NSMutableArray class), and (introduced in Mac  
OS 10.4) also -insertKey:atIndexes: and -removeKeyAtIndexes:  
(corresponding to -[NSMutableArray insertObjects:atIndexes:] and - 
[NSMutableArray removeObjectsAtIndexes:). If at least one insertion  
method and at least one removal method are found each NSMutableArray  
message sent to the collection proxy object will result in some  
combination of -insertObject:inKeyAtIndex:, - 
removeObjectFromKeyAtIndex:, -insertKey:atIndexes:, and - 
removeKeyAtIndexes: messages being sent to the original receiver of - 
mutableArrayValueForKey:. If the class of the receiver also implements  
an optional method whose name matches the pattern - 
replaceObjectInKeyAtIndex:withObject: or (introduced in Mac OS 10.4)  
-replaceKeyAtIndexes:withKey: that method will be used when  
appropriate for best performance.
2. Otherwise (no set of array mutation methods is found),  
searches the class of the receiver for an accessor method whose name  
matches the pattern -setKey:. If such a method is found each  
NSMutableArray message sent to the collection proxy object will result  
in a -setKey: message being sent to the original receiver of - 
mutableArrayValueForKey:.
3. Otherwise (no set of array mutation methods or simple accessor  
method is found), if the receiver's class'  
+accessInstanceVariablesDirectly method returns YES, searches the  
class of the receiver for an instance variable whose name matches the  
pattern _key or key, in that order. If such an instance variable  
is found, each NSMutableArray message sent to the collection proxy  
object will be forwarded to the instance variable's value, which  
therefore must typically be an instance of NSMutableArray or a  
subclass of NSMutableArray.
4. Otherwise (no set of array mutation methods, simple accessor  
method, or instance variable is found), returns a mutable collection  
proxy object anyway. Each NSMutableArray message sent to the  
collection proxy object will result in a -setValue:forUndefinedKey:  
message being sent to the original receiver of - 
mutableArrayValueForKey:. The default implementation of - 
setValue:forUndefinedKey: raises an NSUndefinedKeyException, but you  
can override it in your application.


--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: List of Indexed Accessor Names for NSMutableArray

2008-06-28 Thread Markus Spoettl

On Jun 28, 2008, at 5:07 PM, Quincey Morris wrote:
The last-modified date on that page is Feb, 2007. Seems like a long  
time for such a fundamental document to be incomplete. That may be a  
good thing to mention when you file a bug report against the  
documentation. ;)



Done, 6042235.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Methods that return autoreleased objects?

2008-06-28 Thread Markus Spoettl

On Jun 28, 2008, at 5:25 PM, john muchow wrote:

The last thread that I saw on this topic was dated sometime in
2004if there is something more recent that I didn't find, I
apologize up front...

I realize nothing has probably changed as far as the API and the
documentation to indicate autoreleased methods, however, can someone
provide any insight as to how one knows if a method from a framework
returns an autoreleased object?



Methods that begin with alloc or new or contain copy will return  
objects you are responsible for. All other objects returned from  
methods are taken care of.


More information here:

http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Getting mouse moved events on overlay windows

2008-07-01 Thread Markus Spoettl

On Jul 1, 2008, at 3:54 PM, Brett Powley wrote:
I ran into exactly the same problem; my view was in a transparent,  
borderless, and nonactivating panel.  It didn't get mouse moved  
events, and tracking rectangles didn't work either.  (My problem was  
that I wanted to change the cursor when it was inside my view, but  
it never worked).


I eventually concluded that Cocoa doesn't expect you to be  
interested in mouse moved events or setting the cursor for a window  
that's not active and gave up.  I suspected at the time that it was  
the nonactivating property of the panel that was causing the issue.


If you get any further, I'd be keen to hear what you find out.



That doesn't sound very promising.

One thing I didn't try so far is - instead of trying to overlay the  
WebView - make it draw into an off-screen buffer which I then use to  
paint my own view's background. Of course that comes with its own set  
of problems (coordinating the view sizes). Some of the problems are  
the same as with overlays, just the other way round (view resizing).  
Some I'm not even aware of - I'm sure of that.


I have no idea how to do that, or if it's a futile attempt. I also  
don't like the whole idea particularly much because it just smells  
like a troublesome hack. Even more so as WebView -drawRect doesn't do  
the drawing so I don't know how to make it draw exactly when I want it  
and where I want it.


If someone has input on how to go about this, I'd be more than happy  
to hear your insight.


Regards
Markus
--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: Getting mouse moved events on overlay windows

2008-07-01 Thread Markus Spoettl

On Jul 1, 2008, at 3:54 PM, Brett Powley wrote:

If you get any further, I'd be keen to hear what you find out.



As a matter of fact, I seem to have found something that is much  
simpler than overlaying:


Add a subview to the WebView that doesn't clear its content before  
drawing. When I first tried this months ago I never tried not clearing  
the view's background and always ended up with a completely black  
content area where the WebView content should be drawing, so I though  
WebView just doesn't like subviews (IB doesn't allow you to put one  
there either).


Just minutes ago I retried this and to my complete surprise it works  
perfectly (see code example below). The only thing I fear is that  
redrawing works by pure coincidence. Does anyone think this is a  
doable solution?


I'm using Xcode 3.0 on Mac OS 10.5.4, I have no idea if it works on  
previous systems but I'd be most interested in hearing whether or not  
it does.


Regards
Markus

In the controller (responsible for the WebView) -awakeFromNib I added  
a subview:


- (void)awakeFromNib
{
NSViewTest *sub = [[NSViewTest alloc] initWithFrame:[webview  
bounds]];

[webview addSubview:sub];
[sub setHidden:NO];
[sub setAutoresizingMask:[webview autoresizingMask]];
}

And this is my super-simplistic NSView:

@interface NSViewTest : NSView {
NSTrackingArea *ta;
NSPoint mp;
}
@end

@implementation NSViewTest

- (id)initWithFrame:(NSRect)rect
{
self = [super initWithFrame:rect];
if (self) {
ta = [[NSTrackingArea alloc] initWithRect:[self bounds]  
options:(NSTrackingMouseEnteredAndExited | NSTrackingMouseMoved |  
NSTrackingActiveInKeyWindow) owner:self userInfo:nil];

[self addTrackingArea:ta];
}
return self;
}

- (void)dealloc
{
[self removeTrackingArea:ta];
[ta release];
[super dealloc];
}

- (void)updateTrackingAreas
{
if (ta) {
[self removeTrackingArea:ta];
[ta release];
}
ta = [[NSTrackingArea alloc] initWithRect:[self bounds] options: 
(NSTrackingMouseEnteredAndExited | NSTrackingMouseMoved |  
NSTrackingActiveInKeyWindow) owner:self userInfo:nil];

[self addTrackingArea:ta];
}

- (void)drawRect:(NSRect)rect
{
[[NSColor redColor] set];
NSFrameRect([self bounds]);

if (!NSEqualPoints(mp, NSZeroPoint)) {
NSBezierPath *pt = [NSBezierPath  
bezierPathWithOvalInRect:NSMakeRect(mp.x-5, mp.y-5, 10, 10)];

[[NSColor blueColor] set];
[pt setLineWidth:2.0];
[pt stroke];
}
}

- (void)mouseEntered:(NSEvent *)theEvent
{
}

- (void)mouseExited:(NSEvent *)theEvent
{
mp = NSZeroPoint;
[self setNeedsDisplay:YES];
}

- (void)mouseMoved:(NSEvent *)theEvent
{
mp = [self convertPoint:[theEvent locationInWindow] fromView:nil];
[self setNeedsDisplay:YES];
}

@end


--
__
Markus Spoettl

___

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 [EMAIL PROTECTED]


Re: How to keep a window always in foreground?

2008-07-04 Thread Markus Spoettl

On Jul 4, 2008, at 10:51 AM, Greg wrote:
I've searched the list but haven't been able to find out how to  
*always* keep a window in the foreground.  If you set the layer on  
it and display it, it will appear above all windows, but you can  
still obscure it by switching to another application.  How do I keep  
it floating in front regardless of what application is active?



I think what you are looking for is the window level:

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#/ 
/apple_ref/doc/uid/2013-BCICJDAF


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Mini Popup Window (Like iCal)

2008-07-10 Thread Markus Spoettl

On Jul 10, 2008, at 11:33 AM, Seth Willits wrote:
Has anyone created a custom window like the event info editor in  
iCal in 10.5? There's a few things I'm not sure how to do:


1) Drawing the window background gradient is pretty straightforward,  
but creating the thin border on the window is not. I'm concerned  
about not being getting it thin enough. Any tips on that?


Don't know but it appears a thin border is added to the content view  
automatically - at least that is what I see in my own version.


2) The zoom-in effect. I'm going to go out on a limb here and say  
that this is probably done using private methods. The only public  
way I can think of to do it would be to grab an image of my window  
using the CGWindow API while the window is still hidden, then scale  
that in an overlay window for the effect.



On 10.5 this is probably done with an animation. The following is  
basically what I'm using in a custom window class (you can set  
startFrom to something suitable for your zoom start position):


- (void)showWindowUsingZoomin:(NSRect)targetRect
{
 NSRect startFrom = NSZeroRect;  // - size component should be {0,0}
 CGFloat duration = 1.0; // - make much less in real life like 0.1

 [self setFrame:startFrom display:NO];
 [self makeKeyAndOrderFront:nil];

 [NSAnimationContext beginGrouping];
 [[NSAnimationContext currentContext] setDuration:duration];

 [[self animator] setFrame:targetRect display:YES];

 [NSAnimationContext endGrouping];
}

Be warned that since startFrom.size is {0,0} this causes trouble with  
controls that auto-size based on the window's size.


Regards
Markus
--
__
Markus Spoettl


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 [EMAIL PROTECTED]

Re: Protocol-conforming object does not include retain?

2008-07-11 Thread Markus Spoettl

On Jul 11, 2008, at 7:59 PM, Bill Bumgarner wrote:

id mGrid;

... you would be indicating to the compiler that mGrid might  
potentially respond to any method ever seen.


I'm either misunderstand what you're saying or something is wrong with  
my compiler because this:


id bar;

[bar foo:NSZeroRect super:nil underConstruction:YES];

triggers a compiler warning for me (Xcode 3.0):

warning: no '-foo:super:underConstruction:' method found

The only thing that removes that warning (for me) is an informal  
protocol on NSObject that declares the method.


Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

[[NSDate alloc] initWithString] crashes with valid string

2008-07-15 Thread Markus Spoettl

Hi List,

  I've a problem I am failing to track down (let alone understand)  
for a couple of weeks now. My application imports XML files that  
contain - amongst other things - dates. Once in a while, the string to  
date conversion causes a crash (EXC_BAD_ACCESS):


#0  0x90b1da14 in ures_getIntVector
#1  0x90b20eb0 in icu::Calendar::setWeekCountData
#2  0x90b1f463 in icu::GregorianCalendar::GregorianCalendar
#3  0x90b1ee16 in icu::Calendar::createInstance
#4  0x90b1c73e in ucal_open
#5  0x940a097b in __CFCalendarCreateUCalendar
#6  0x940a0a22 in __CFCalendarSetupCal
#7  0x940a15d7 in _CFCalendarComposeAbsoluteTimeV
#8  0x95428cbc in -[NSCFCalendar dateFromComponents:]
#9  0x9542879b in -[NSDate(NSDate) initWithString:]

This specific crash happened with the string: 2008-05-09 19:47:47  
+, which seems perfectly valid input for NSDate -initWithString:.


The string appears to be a valid object - if it is any indication (I  
don't know if it is) the debugger tells me the string value on the  
call stack just fine.


Any ideas what could be causing something like this?

Thanks!
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

2008-07-15 Thread Markus Spoettl

On Jul 15, 2008, at 5:00 PM, Nick Zitzmann wrote:
In addition to what everyone else has suggested, have you tried  
running your application under Guard Malloc to make sure memory is  
not being corrupted? I've caught all sorts of weird behavior in  
applications before by using Guard Malloc.



Thanks for the suggestion, I just tried this and now it crashes in  
initialization of NSXMLDocument (see call stack below). My (unfounded)  
suspicion was that the XMLDocument somehow was responsible for all the  
trouble.


The call stack tells me something strange is going on when opening the  
URL. So I changed the NSXMLDocument initialization to use a NSData  
instance that I load from the file manually and viola, the random  
crashing is gone. So apparently there is a big difference between  
loading an XMLDocument using URL and loading from NSData. Which I  
don't know, the documentation doesn't indicate special behaviour.  
Apparently it didn't like the XML URL but it does work with the data  
in it.


Thanks everyone for your suggestions, this issue gave me quite a  
number of sleepless nights.


Thanks again!

Regards
Markus


#0  0x00332556 in _mach_msg_trap at syscall_sw.h:83
#1  0x0033c8ad in mach_msg
#2  0x00360861 in vm_protect
#3  0x0009a034 in GMmalloc_zone_malloc
#4  0x940eb451 in _CFRuntimeCreateInstance
#5  0x940795a8 in __CFArrayInit
#6  0x940e0ebf in parseXMLElement
#7  0x940e27ea in parseDictTag
#8  0x940e0e95 in parseXMLElement
#9  0x940e27ea in parseDictTag
#10 0x940e0e95 in parseXMLElement
#11 0x940e0ad0 in parseXMLElement
#12 0x940e2082 in _CFPropertyListCreateFromXMLData
#13 0x940e262b in CFPropertyListCreateFromXMLData
#14 0x96e62075 in loadPolicyFromFile
#15 0x96e61faa in initializePolicy
#16 0x003588a9 in pthread_once
#17 0x96e6071e in _LSCopyDownloadAssessmentDictionaryInternal
#18 0x96e6038a in _LSCopyDownloadAssessmentDictionary
#19 0x93e3ccfd in _initDownloadAssessment
#20 0x93e50f20 in _CFURLResponseGuessMIMEType
#21 0x93e8122b in sniffForContentTypeWithData
#22 0x93e3d608 in sendDidReceiveDataCallback
#23 0x93e3ac22 in _CFURLConnectionSendCallbacks
#24 0x93e3a573 in muxerSourcePerform
#25 0x940e9615 in CFRunLoopRunSpecific
#26 0x940e9cf8 in CFRunLoopRunInMode
#27 0x93e5db42 in CFURLConnectionSendSynchronousRequest
#28	0x9545680b in +[NSURLConnection  
sendSynchronousRequest:returningResponse:error:]

#29 0x9554fe56 in -[NSXMLDocument initWithContentsOfURL:options:error:]
#30	0x0003d601 in -[RubiData(Import) importFromFile:] at RubiData 
+Import.m:257





--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: [[NSDate alloc] initWithString] crashes with valid string

2008-07-15 Thread Markus Spoettl

On Jul 15, 2008, at 6:33 PM, Nick Zitzmann wrote:
Have you reported this to Apple through http://bugreport.apple.com/ 
? That is very strange behavior that obviously shouldn't be  
happening.


I will do this once I can confirm my crashes are gone. Obviously this  
takes a little extra effort because they most certainly will ignore  
the issue unless I produce a test application that recreates the crash  
reliably (which could be tricky).


Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSOutlineView force expansion/refresh?

2008-07-16 Thread Markus Spoettl

On Jul 16, 2008, at 3:22 PM, Michael Hanna wrote:

I'm using observeValueForKeyPath:ofObject:change:context: to detect
when a change occurs in my data model. When a non-leaf node gets
added, the outline view draws the new item, but in an unexpanded
state. I try this code:

   [m_rulesOutlineView noteNumberOfRowsChanged];

   //  expand all items in outline view
   int c;
   for (c = 0; c  [m_rulesOutlineView numberOfRows]; c++)
   {
   id item = [m_rulesOutlineView itemAtRow:c];
   [m_rulesOutlineView expandItem:item];

   [m_rulesOutlineView
setNeedsDisplayInRect:[m_rulesOutlineView rectOfRow:c]];
   }

in order to expand the new item. The new item expands(i.e. the
triangle points downward) but the leaf nodes aren't actually drawn.
The user has to undisclose, then disclose the new triangle in order to
see the children.



I don't know if that causes your problem but you should know that - 
numberOfRows: grows as you expand items. The most simple way to get  
around implications that are caused by this behaviour this is going  
through the items in reverse order like this:


for (c = [m_rulesOutlineView numberOfRows] - 1; c =  ; c--)
{
   // expand items here
}

That way you will avoid looking at rows that have been created as a  
result of expanding an item.


Also, I don't think that you have to call -setNeedsDisplayInRect: on  
the items, that's something NSOutlineView should be managing.


Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Getting the keyEquivalent as a string

2008-07-16 Thread Markus Spoettl

Hi List,

  I'll probably going to regret asking this but despite extensive  
Googling and documentation reading I couldn't find out if there's a  
framework function to get a NSMenuItem's keyEquivalent +  
keyEquivalentModifierMask as printable text (the way it's drawn in a  
menu item). Obviously assembling it myself wouldn't be a big deal but  
I'm sure there's a function for that somewhere already. Is there?


Thanks
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Getting the keyEquivalent as a string

2008-07-16 Thread Markus Spoettl

On Jul 16, 2008, at 8:21 PM, Ken Ferry wrote:

I don't think there is anything that makes it easy to draw a visual
representation of a key equivalent.  There's a bug for it,
rdar://problem/5662562 (not that you can see that).

You can probably crib code from http://wafflesoftware.net/shortcut/.



Thanks Ken.

Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

NSWindowController getting over-released by NSDocument?

2008-07-21 Thread Markus Spoettl

Hi List,

  I'm having some problems with memory management of a window  
controller in a standard NSDocument based application. The problem is  
that my window controller gets released through an autorelease pool  
after the document has been deallocated (and released it in the  
process).


I've overwritten release and retain on the this window controller be  
able to examine the retain/release cycle. Unfortunately overwriting - 
autorelease does not work (contrary to -retain and -release) so I  
can't break when it's being put into the autorelease pool (why I don't  
know).


My document is creating the window controller in

- (void)makeWindowControllers
{
controller = [[RubiWindowController alloc]  
initWithWindowNibName:@RubiDocument];

[controller setShouldCloseDocument:YES];
[self addWindowController:controller];

}

and releases it in -dealloc:

- (void)dealloc
{
[controller release];
[super dealloc];
}

Until here everything is balanced. The release here causes the  
controller's -dealloc: being executed.


However after this, an autorelease pool releases it again, which  
causes a EXC_BAD_ACCESS crash:


#0  0x949e36e8 in objc_msgSend
#1  0x94078cb6 in CFArrayApplyFunction
#2  0x9574d305 in -[NSView _recursiveBreakKeyViewLoop]
#3  0x94078cb6 in CFArrayApplyFunction
#4  0x9574d305 in -[NSView _recursiveBreakKeyViewLoop]
#5  0x94078cb6 in CFArrayApplyFunction
#6  0x9574d305 in -[NSView _recursiveBreakKeyViewLoop]
#7  0x9574bbe9 in -[NSWindow dealloc]
#8  0x9539e57f in NSPopAutoreleasePool
#9  0x956e2e54 in -[NSApplication run]
#10 0x956b0030 in NSApplicationMain
#11 0x3946 in main at main.m:13

I've tried both settings of Releases when closed in IB, but it  
crashes regardless of this setting.


Am I not supposed to release the window controller in the document  
even though I create it?


Thanks for any pointers!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSWindowController getting over-released by NSDocument?

2008-07-21 Thread Markus Spoettl

On Jul 20, 2008, at 11:53 PM, Markus Spoettl wrote:
 I'm having some problems with memory management of a window  
controller in a standard NSDocument based application. The problem  
is that my window controller gets released through an autorelease  
pool after the document has been deallocated (and released it in the  
process).



Please ignore this, it's not the window controller that is being  
release, I was fooled by the debugger break I had in dealloc.


Sorry for wasting your time.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Avoiding mutual retain cycles

2008-07-21 Thread Markus Spoettl

Hi List,

  in the course of debugging a -dealloc in a data structure that is  
part of an NSDocument app, I've discovered that my document and all  
it's data never gets deallocated. After some extensive digging I  
nailed the problem down to mutual retain cycles (not sure this is the  
right term). I actually had a number of those, it always followed this  
scheme:


An object A was retained by an object B which was owned by A. A  
releases B in its -dealloc, B releases A in its -dealloc. Since  
neither retain count would ever go to zero, neither dealloc would ever  
be called and everything would just stay there forever.


By changing the reference from B to A to a weak reference which  
doesn't retain and release A, the problem goes away. However,  
generally speaking this is dangerous road to go  (and against memory  
management guidelines) because now it's no longer guaranteed that A  
still exists if B is using it. Sure, there could be measures  
implemented that help with that (like A notifying B that it's going  
away) but that would mean a lot of additional housekeeping.


Defining who owns who (owners get a strong reference to owned) also  
helps, because it's then guaranteed that A will be there for as long  
as B exists, thus a strong reference is not needed. But there are  
still cases where it is unknown which of the objects is going to be  
released first (because it's hidden in the inner workings of AppKit  
for example).


I'm wondering if there is a general rule or mechanism that suggests  
what to do in such a case. For instance, how are delegates implemented  
in AppKit, are they retained? If so, when are they released. It can't  
be in -dealloc, otherwise everything would lock itself out of  
deallocation?


Thoughts?

Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Avoiding mutual retain cycles

2008-07-21 Thread Markus Spoettl

On Jul 21, 2008, at 12:21 PM, Andreas Mayer wrote:
I'm wondering if there is a general rule or mechanism that suggests  
what to do in such a case.


About retain cycles:

http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html

The solution to the problem of retain cycles is that the “parent”  
object should retain its “children,” but that the children should  
not retain their parents.


For instance, how are delegates implemented in AppKit, are they  
retained?


http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_4.html

Delegating objects do not (and should not) retain their delegates.


Thanks for those links.

But there are still cases where it is unknown which of the objects  
is going to be released first


Care to name one?


For example NSCollectionView, NSCollectionViewItem and its view. One  
may or may not suspect the NSCollectionViewItem owns the corresponding  
view. It may as well not own it and instead the NSCollectionView owns  
both. Of course once you run into a retain cycle problem with this and  
no NSCollectionViewItem ever gets released because of it (like I did)  
you quickly learn why and who owns the view.


The point is, unless this is documented explicitly the ownership  
relations are not clear all the time.


I generally do not find it difficult to decide which object needs to  
own which. In case you can't decide, maybe neither should and you  
are better off adding a third object that handles both.



Agreed, if it's in your own power and you know what your structure  
looks like it's simple.


Regards
Markus
--
__
Markus Spoettl

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 [EMAIL PROTECTED]

Re: Avoiding mutual retain cycles

2008-07-21 Thread Markus Spoettl

On Jul 21, 2008, at 12:28 PM, Ken Thomases wrote:
Actually, it is not against the guidelines, it is in keeping with  
them.


See here: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#/ 
/apple_ref/doc/uid/2043-1000698


That explicitly discusses retain cycles and the use of weak  
references to break them.



Thanks for the link.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Avoiding mutual retain cycles

2008-07-21 Thread Markus Spoettl

On Jul 21, 2008, at 7:23 PM, Michael Ash wrote:

Without investigating things more deeply, just from the basic stuff I
know about the classes in question, I'd assume that the
NSCollectionView owns the NSCollectionViewItems and the views, and the
NSCollectionViewItems would also own the views. Where is the retain
cycle?



Well there is none in the default setup, of course. But here's a non  
far-fetched example to easily create one.


If you're implementing a custom NSView that for some reason has to  
have access to the NSCollectionViewItem or NSCollectionView it belongs  
to, the only proper way to do so (in the collection view world) is by  
accessing the NSCollectionViewItem which has a -collectionView method  
that returns the collection view.


So you need a way back and this you do with a pointer to the  
NSCollectionViewItem in a suitable place. As you don't know the  
ownership circumstances of NSCollectionViewItem and its view the  
safest thing to do is to retain the NSCollectionViewItem in the view.  
There's the retain cycle, because - as it turns out - the  
NSCollectionViewItem seems to retain the view.


The point of all this is not that it's avoided easily - which it is.  
The point is that you can't know the circumstances unless it's  
documented and the original question was how AppKit does avoid things  
like that.


Now that I read more on retain cycles it's clear there is no ingenious  
Cocoa solution to this problem, just plain old defensive programming  
techniques - which is what I was wondering about.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Avoiding mutual retain cycles

2008-07-21 Thread Markus Spoettl

On Jul 21, 2008, at 1:03 PM, Philippe Mougin wrote:
In the general case, there is no rule or mechanism to deal with  
retain cycles other than implementing something equivalent to a  
garbage collector. In some situations, however, the specific  
semantics and life-cycle of the objects you are dealing with allow  
implementing more simpler, ad hoc solutions (e.g., ownership  
management in the view hierarchy). Still, this requires notable  
housekeeping efforts and is often error prone. If you are in a  
situation where you can make use of Cocoa's garbage collector, you  
should go for it. It will free you from a bunch of low-level memory  
management tasks, including having to care about cyclic references.



Call me a retro coward, but I absolutely dislike the idea of GC. I  
just don't see the point of it given the complicated implications it  
can have.


Anyway, thanks for your suggestion.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Avoiding mutual retain cycles

2008-07-21 Thread Markus Spoettl

On Jul 21, 2008, at 7:49 PM, Andreas Mayer wrote:
I don't know why you'd think the collection view might own the  
item's view. You set the view for the view item, so the hierarchy  
seems to be quite clear. (The collection view *might* retain the  
view too. That's an implementation detail.)


Well that's exactly what is important here, isn't it.

How would you get a retain cycle here? You just hold on to the  
collection view. Everything else should not be your responsibility.


Unless you have to have access to the collection view or the view's  
item controller.


If you set something, it's usually retained. Exceptions from this  
norm should certainly be documented - like it is with delegates.



That basically answers the original question I had, but things can get  
complicated and details become important.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Avoiding mutual retain cycles

2008-07-22 Thread Markus Spoettl

On Jul 21, 2008, at 11:20 PM, Quincey Morris wrote:
Call me a retro coward, but I absolutely dislike the idea of GC. I  
just don't see the point of it given the complicated implications  
it can have.


But I hope you do see the irony of that last statement, in the  
context of this thread.



I knew this would backfire when I wrote it. What I meant to say was  
that you give up a lot of control over the inner workings of your  
application with GC and I don't like that idea too much. Just don't.


Anyway, it's great to have choices, so everyone can use what they  
think suits them best.


Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Putting a spinning progress indicator in a outline

2008-08-01 Thread Markus Spoettl

Hello List,

 I'm trying to figure out how I might be able to do something like  
Mail.app does displaying a spinning progress indicator as part of an  
outline item. Is this a custom cell type that AppKit doesn't have or  
is it something that's already there waiting to be used? I'd be  
grateful is someone could push me in the right direction.


Thanks!
Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Putting a spinning progress indicator in a outline

2008-08-02 Thread Markus Spoettl

On Aug 1, 2008, at 4:42 PM, Markus Spoettl wrote:
Thanks, that looks pretty good. I can't get it to work with binding  
right now, not sure why that is. When I bind to a bool property of  
the item object (which is KVC compliant) I get this logged:


8/1/08 4:06:37 PM myApp[1280] [NSTableColumn 0x1cfeb0  
valueForUndefinedKey:]: this class is not key value coding-compliant  
for the key value.


which - I guess means - that the cell is not compliant (because my  
value is). I can't find out a way to get the name of the key it is  
looking for, that would give me a clue as to what is missing. Any  
ideas?



Well to answer my own question, NSCell doesn't expose bindings, that's  
why I think it doesn't work. So either I manage to feed values to the  
column through the datasource delegate methods - which doesn't seem to  
work, can one even mix binding and datasource driven columns on a  
NSOutline? - or I have to add a value binding to the cell  
implementation.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Putting a spinning progress indicator in a outline

2008-08-02 Thread Markus Spoettl

On Aug 2, 2008, at 6:15 AM, Andreas Mayer wrote:
which doesn't seem to work, can one even mix binding and datasource  
driven columns on a NSOutline?


I think that should be possible.


Turns out that if you mix binding and datasource, you have to  
implement not only


- (id)outlineView:(NSOutlineView *)outlineView  
objectValueForTableColumn:(NSTableColumn *)tableColumn byItem:(id)item


but also

- (BOOL)outlineView:(NSOutlineView *)outlineView isItemExpandable: 
(id)item
- (id)outlineView:(NSOutlineView *)outlineView child:(int)index ofItem: 
(id)item
- (NSInteger)outlineView:(NSOutlineView *)outlineView  
numberOfChildrenOfItem:(id)item


Unless you implemented those three, -objectValueForTableColumn: will  
never be called, even though the three never get called due to binding.


I'd say it's not originally intended to use NSOutlineView with both  
bindings and datasource, at least that's what it smells like for me.



or I have to add a value binding to the cell implementation.


In case you do, I'd appreciate if you shared your code. :)



You can count on that, but since I got it working without I might not  
do this. Unless it turns out that the mixed mode comes with issues.


Thanks for the progress implementation, works nicely!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: NSTableView Question

2008-08-02 Thread Markus Spoettl

On Aug 2, 2008, at 12:10 PM, Eric Lee wrote:
So, here's my question. How do you have two table view's in the  
same .h/.m file? I try to reimplement the needed protocols, but I  
can't, so I then try to add the code to adding data to the same  
protocols that the 1st table view is implementing, but then, both  
table view's stop working!


Does anyone have any suggestions?


The first argument in all delegate and datasource methods is the table  
view, that's how you can distinguish which table it is you need to  
provide data for.


Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Preventing deselection of NSOutlineView item

2008-08-07 Thread Markus Spoettl

Hi List,

  I have an app with a bound NSOutlineView (source list style) and  
I'm wondering if there's a way to prevent deselection of a selection  
by the user. The delegate method


- (BOOL)outlineView:(NSOutlineView *)outlineView shouldSelectItem: 
(id)item;


is not called when no new item is selected (for example if the user  
clicks in the empty space of the outline view, or when COMMAND-clicks  
the selected item).


Basically I'd like the outline view only to change selection to other  
items, but not completely deselect all items. Is there a way to do this?


The closest thing I came up with is re-setting the selection indexes  
of the tree controller to the last known selected item (via - 
performSelector:withObject:afterDelay:0.0). However, that produces a  
flicker effect because the selection goes away briefly before it comes  
back. Resetting the selection index from within a change notification  
(via observing -selectedObjects of the tree controller) has no effect.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Preventing deselection of NSOutlineView item

2008-08-07 Thread Markus Spoettl

On Aug 7, 2008, at 2:34 PM, Markus Spoettl wrote:
Basically I'd like the outline view only to change selection to  
other items, but not completely deselect all items. Is there a way  
to do this?



Sometimes things are really simple but I still fail to see them:

  [outlineView setAllowsEmptySelection:NO];

does exactly what I needed. Sorry for the noise and thanks to  
Chaitanya Pandit for pointing it out to me.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

How to switch off NSCollectionView fade animations

2008-08-10 Thread Markus Spoettl

Hello List,

  is there a way to switch off the fade-in and fade-out animation  
that take place when NSCollectionView shows new or hides removed  
items? Those things can really decrease performance when it displays a  
lot of collection items that have complex drawing routines. On top of  
it I keep getting assertion failures when the bound array changes  
while the collection view is hidden (bug reported already).


So I'd really really like to completely switch animation off for the  
collection view if that is possible. Is it?


I'm using Xcode 3.0 on 10.5.4

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Hiding the disclosure triangle of a specific group item in a bound NSOutlineView

2008-08-10 Thread Markus Spoettl

Hi List,

  I have an NSOutlineView based source list bound to a tree  
controller and I can't figure out how to create a group item that does  
not have a disclosure triangle - as an example, the MAILBOXES folder  
group in Mail.app does that.


I thought it might be possible by returning NO for the - 
shouldCollapseItem: and -shouldExpandItem: delegate methods for the  
group item in question but that doesn't do have that effect. It makes  
the item non-expandable/non-collapsable but it still shows its  
disclosure triangle. I also set the datasource (the outline is bound)  
and implemented the datasource method


- (BOOL)outlineView:(NSOutlineView *)outlineView isItemExpandable: 
(id)item


but that never gets called.

Any ideas on how to make the disclosure triangle disappear for a  
specific item? Is this only possible in data source driven outline  
views?


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Hiding the disclosure triangle of a specific group item in a bound NSOutlineView

2008-08-10 Thread Markus Spoettl

On Aug 10, 2008, at 4:27 PM, Kyle Sluder wrote:

From the documentation:

You can override this method in a subclass to return a custom frame
for the outline button cell. If your override returns an empty rect,
no outline cell is drawn for that row. You might do that, for example,
so that the disclosure triangle will not be shown for a row that
should never be expanded.

Then you'll want to manually expand all of those entries.  And then
you'll want to file a bug with Apple to make this part of the
NSOutlineView API.



Thanks a lot, works perfectly!

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Creating popup window/panel

2008-08-12 Thread Markus Spoettl

On Aug 12, 2008, at 12:01 AM, Devraj Mukherjee wrote:

I am trying to create a window that pops up from the toolbar (like say
the project selection window in Pages or the window that pops up if
you drag an existing source file onto XCode). I am trying design a UI
so the user doesn't have to bring up a separate window.

Is this done using a normal window and these are just display
properties or is this done using a view?



Such windows are called Sheets. Here are all the details:

http://developer.apple.com/documentation/Cocoa/Conceptual/Sheets/Sheets.html

more specifically

http://developer.apple.com/documentation/Cocoa/Conceptual/Sheets/Tasks/UsingCustomSheets.html

and

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class/Reference/Reference.html#/ 
/apple_ref/doc/uid/2012-BAJJGDJB


Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Making a bound view re-read its value

2008-08-14 Thread Markus Spoettl

Hi List,

  how can I make a view value which is bound to a property manually  
re-read (or update) the value it displays?


The simplified setup is this: I have an object, that stores its values  
(say a temperature) in Celcius. I also have an application preference  
that lets the user switch between temperatures in Celcius and  
Fahrenheit for viewing and editing. The view's value binding uses a  
value transformer that converts the value based on the current  
application setting.


When the user changes the preference, the view should update its value  
so it uses the right units. There is no change to the underlying data,  
so there's no change notification that would force the binding to  
refresh the view.


So how can I manually make the view update? It seems so simple but I  
can't figure out how to do this.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Making a bound view re-read its value

2008-08-14 Thread Markus Spoettl

On Aug 14, 2008, at 3:28 PM, Kyle Sluder wrote:

On Thu, Aug 14, 2008 at 6:21 PM, Markus Spoettl
[EMAIL PROTECTED] wrote:
So how can I manually make the view update? It seems so simple but  
I can't

figure out how to do this.


I can think of a couple of ways:
1) When your preference changes, post a notification.  The views
listen for that notificiation, and update themselves accordingly.


OK, but that's exactly what I tried to get down to: How do I make a  
view update when its value is bound to something. If I feed the value  
to the view manually, I can do just that again. But how do I make the  
view update when its value is bound?


Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Making a bound view re-read its value

2008-08-14 Thread Markus Spoettl

On Aug 14, 2008, at 5:07 PM, Ron Lue-Sang wrote:

Here's how I look at your situation.

Your view is bound to some property. It's job is to listen for KVO  
notifications and redraw when it gets the KVO notification. That's  
it. One input. When there's a change on that one input, then redraw.


What you have is 2 inputs and only one notification.  
ValueTransformers are meant to be less stateful than you're  
intending them to be.


You might be tempted to try adding a notification for your celsius/ 
fahrenheit choice and call [self setNeedsDisplay];  But that's not  
what I'd do.


I'd have whatever-controller-my-view-is-bound-to have a property  
that represents the temperature based on the current settings. It  
would receive the userDefault notification and update its temp.  
property.


We've never explicitly defined a do this to make the view refresh  
its bound values. The main reason is that that's  a messy way to  
mentally model the way bindings work.


Sorry if that doesn't answer the question you asked, but hopefully  
this is information you can use to get work done.



Thanks for the response, though it's unfortunate for me I guess.

The problem is that I actually have a lot arrays of lots of objects  
each with a number of different properties that can be displayed in  
more than one way (all dependent on one preference settings). Putting  
these through proxies/proxy arrays so that I can use bindings and KVO  
to make process automatic sounds like a terribly painful way to go -  
plus it defeats the purpose of bindings a little (glue code wise).


I have suspected that my use of ValueTransformers is not quite what  
they were intended for but they actually do this job very well.


Anyway, thanks for the advice.

Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

Re: Making a bound view re-read its value

2008-08-15 Thread Markus Spoettl

On Aug 14, 2008, at 8:20 PM, Ron Lue-Sang wrote:

Hmm yea, that's a bummer.
If I were building the views you're using, I'd publish another  
binding in/from those views. Like dataType or  
ridiculouslyLongGermanStyleNameDescribingWhatTheBindingIsFor.


And then your views would really have two inputs and you'd actually  
draw differently in your drawRect method because you can change your  
view state in response to the KVO notification your view gets from  
the 2 things it's bound to - and the handling of the KVO  
notification can safely do [self setNeedsDisplay] and know that  
that's gonna work.


Interesting idea I'll keep that in mind...


But I bet you're just trying to use plain old textFields. Yea?



Exactly, that's the main problem. My own custom views don't use  
bindings, they use KVO more directly so I can make this work more  
easily.


I think I may have found a way that might be feasible in a more  
automated way, though. When I get a KVO notification for the  
preference change in the (window/view) controller, I can unbind the  
text field and bind it again. Since I can get all binding properties  
using -infoForBinding: I can automatically rebind the whole thing  
without hardcoding (except for the binding name). The only thing that  
I have to do is setting it up correctly but it looks like it works fine:


- (void)rebind:(NSObject *)object binding:(NSString *)binding
{
NSDictionary *bindingInfo = [object infoForBinding:binding];
NSObject *observedObject = [bindingInfo objectForKey:  
NSObservedObjectKey];
NSString *keyPath = [bindingInfo  
objectForKey:NSObservedKeyPathKey];
NSDictionary *bindingOpts = [[[bindingInfo  
objectForKey:NSOptionsKey] retain] autorelease];


[object unbind:binding];
[object bind:binding toObject:observedObject withKeyPath:keyPath  
options:bindingOpts];

}

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object  
change:(NSDictionary *)change context:(void *)context

{
if ([keyPath isEqualToString:@metricUnits]) {
[self rebind:tempField binding:@value];
}
}

This can also be done as a category on NSObject for reuse purposes.  
I'm wondering as to whether this has any side effects that I'm not  
aware of? I certainly can live with that kind of manual work, though  
its not nearly as elegant as your suggestion.


Regards
Markus
--
__
Markus Spoettl



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 [EMAIL PROTECTED]

  1   2   3   4   5   >