Re: retaining and releasing a Window Controller.

[Negm-Awad Amin]

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

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

Cheers

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




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

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

___

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

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

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

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

Re: Autorelease pool

[Negm-Awad Amin]

Am Do.,08.10.2009 um 16:36 schrieb Michael Süssner:


Hi ,

thanks a lot for your tips. after having read the bible and some  
experiments I have learned how to do it correctly.


Here the conclusion for the rest of the world:
	NSMutableArray *vPolyArray = [[NSMutableArray alloc]  
initWithCapacity:6];


	vPolygon = [[[PolygonShape alloc] initWithNumberOfSides:5  
minimumNumberOfSides:2 maximumNumberOfSides:8] autorelease];
	[vPolyArray addObject:vPolygon]; // now only the Array is the owner  
of the object


...
Hopefully the … contains no exception, no return and no break (if you  
are in a loop).


	[vPolyArray autorelease]; // since I have created the array with  
alloc and init I have to release it or autorelease it


Thanks a lot
g
Michael





On Oct 7, 2009, at 2:53 PM, Michael Süssner wrote:
After my test program has passed successfully the drain method of  
the autorelease buffer is called and "sometimes" I get the  
following error:

Program received signal:  “EXC_BAD_ACCESS”.
sharedlibrary apply-load-rules all


How can I track which object has already been release:


You can enable zombies, which will mark deallocated objects' memory  
with what they used to be, and can also prevent anything from being  
actually deallocated ever, but is a useful way to investigate this  
kind of problem (if you can reach the problem before you run out of  
memory :) )


See NSDebug.h in Foundation.framework for some info on this.


The code is rather simple:
NSArray *vPolyArray = [NSArray arrayWithObjects: ... ];
[vPolyArray release];


You're over-releasing vPolyArray. +arrayWithObjects: returns an  
autoreleased instance, and you're also releasing it explicitly, so  
by the time NSAutoreleasePool gets around to releasing it, it's  
already gone.










___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to negm-a...@cocoading.de


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




___

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

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

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

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

Re: Design pattern for "per-document" settings

[Negm-Awad Amin]

Am Mo,03.08.2009 um 02:18 schrieb Graham Cox:


Hi all,

I'm just thinking through a couple of problems and wondered if  
anyone had anything to say about it...


In my app I have several things that apply on a "per document"  
level, for example, the mapping from Quartz co-ordinate values to  
some other measurement system, such as millimetres. Different  
documents might have different mappings. Other parts of my interface  
will want to work with these settings, for example text fields that  
set geometric properties such as line width. Many of these text  
fields live in floating palettes that respond to different document  
windows becoming main, etc.


So what I'm thinking is that I can write a custom formatter attached  
to the text fields that can pick up the current main document's co- 
ordinate mappings. I'm just not sure what the most efficient and  
most straightforward implementation might look like.


I could get every formatter instance to subscribe to certain  
notifications, but that requires a lot of code to set up and tear  
down as nibs are loaded, etc. Alternatively, I could give the  
formatter some class methods that centralise the notification  
handling and also keep track of all the individual instances.  
Trouble with that is that class methods are global, rather than "per  
document", though since most (but not all) of the formatters are  
also global in the sense that they are in context sensitive  
palettes, that is favourite at the moment.


Or maybe formatters are not a sensible way to deal with this at all?  
Is there a better design pattern I'm overlooking?


--Graham


Never tried, but should work:
1. Make a subclass
2. add a property that holds the information
3. add a binding for that property
4. bind the property through the application to get the "active"  
dorument



___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to negm-a...@cocoading.de


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




___

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

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

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

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

Re: How to show Interface Builder's build warning and messages?

[Negm-Awad Amin]

In many cases this are no warnings but "notices". You can switch them  
off in Xcode, if you want to:

http://www.cocoading.de/webspace/IBC%20Notices.tiff

Cheers

Am Mi,29.10.2008 um 08:39 schrieb Oleg Krupnov:


Recently I was building my project and saw there were some warnings
and messages regarding a XIB file.

For example, there were warnings that some connection outlets were
broken, and there were messages that some views were clipping their
own content.

After I fixed the connection outlets, the warnings were gone, but the
messages were no longer displayed neither, yet I still wanted to fix
the clipping views too. In other words, if there are no warnings but
only messages in a XIB, the latter are not shown in the build results.

How do I re-show these messages again in IB?

I tried to click "Info" for the XIB in IB, but the list is empty.
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Customizing controls: Inheritance bad?

[Negm-Awad Amin]

Am Do,30.10.2008 um 16:51 schrieb Brian Williams:


Hello,



I'm brand new to Cocoa/Obj-C and I'm working on converting an app. to
use Cocoa...



I've heard that, in general, if you are using inheritance in Cocoa,
you're not following the typical standard design pattern.  Is this  
true?







To respond to special keyboard events in an NSTableView, I created a
subclass and provided an implementation for keyDown.

To draw some customized stuff in an NSColorWell, I created a subclass
and provided an implementation for drawRect.

Etc.



In the olden days, this kind of object-oriented approach was perfectly
correct.



But I'm told I should be using delegate methods and firstResponders
somehow.



In general, is there a preferred approach to using actions over
delegates, and delegates over handling Cocoa events?  It seems there  
are

many different ways to handle the same problem and some ways are
preferred over others...
Typically you inherit a class to implement some specialized work. The  
problem you get is called white-boxing, because a subclass gets very  
much information, which should be encapsulated inside the class. So  
inheritance is a little bit "dangerous".


Many cocoa classes gives you the chance to specialize the behaviour of  
their instances by delegating. A delegate is an extern instance. So it  
is black-boxing instead of white-boxing. You still have an API  
contract. This is the better design.


So *if* you can do your work using a delegate, in many cases you  
should prefer this way.
However, some classes are intended for derive them, i. e.  
NSWindowController. There is nothing wrong doing so, if it is  
intended. Read the subclassing notes for the class in the  
documentation. And have a look to the delegate methods.


Cheers






Also, could someone recommend a good intro to FirstResponders as  
this is

a concept I don't understand fully yet?



Thanks,

Brian

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: [MEET] CocoaHeads Mac Developer Meetings

[Negm-Awad Amin]

Am Mi,29.10.2008 um 23:29 schrieb Stephen Zyszkiewicz:


Greetings,

CocoaHeads is an international Mac programmer's group.  We specialize
in Cocoa, but everything Mac programming related is welcome.

Why Should I Attend?
Meeting other Mac OS X developers in person is both fun and immensely
useful. There's no better way to learn Cocoa or get help with problems
than being around other people who are writing Mac software.

We usually have several Cocoa experts hanging around that are happy to
answer whatever questions they can. Bring your laptop and any code
you're working on.

Everyone is Welcome
Meetings are free and open to the public. Feel free to drop in even if
you've never attended or aren't currently using Cocoa. We usually have
a few new faces, so don't worry about being the odd one out.

Upcoming meetings:
Canada
Ottawa/Gatineau- Thursday November 13, 2008 08:00 PM EDT.

Germany
Berlin- Thursday November 13, 2008 07:00 PM CEST.
Bonn- Thursday November 20, 2008 07:00 PM CEST.

I want to add:
Aachen- Thursday October 30, 2008 07:00 PM CEST


Sweden
Stockholm- Monday November 03, 2008 07:30 PM CEST.

United Kingdom
Swindon- Monday November 03, 2008 09:00 PM BST.

United States
Boston- Thursday November 13, 2008 07:00 PM EDT.
Boulder- Tuesday November 11, 2008 08:00 PM MDT.
Colorado Springs- Thursday November 13, 2008 07:00 PM MST.
Des Monies- Thursday November 13, 2008 07:00 PM CST.
Fort Lauderdale- Sunday November 16, 2008 08:00 PM EDT.
Minneapolis- Thursday November 13, 2008 06:00 PM CST.
Philadelphia- Thursday November 13, 2008 07:00 PM EDT.
Provo- Thursday November 13, 2008 07:00 PM MST.
St. Louis- Saturday November 22, 2008 02:00 PM CST.


Please check the web site at  for more
information including last-minute changes. Some chapters may have yet
to post their meeting for this month.


Steve
Silicon Valley CocoaHeads

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: NSCoding protocol

[Negm-Awad Amin]

Am Fr,10.10.2008 um 18:17 schrieb Clark Cox:

On Fri, Oct 10, 2008 at 9:09 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:


Am Fr,03.10.2008 um 21:00 schrieb [EMAIL PROTECTED]:

I want MyClass to conform to the NSCoding protocol. But I'm  
puzzled about

how to implement the initWithCoder: method.

Suppose I have this in MyClass.h:

  NSString *S1, *S2, *S3;


and this in its init function:

  S1 = @"a string";
  S2 = [[NSString alloc] init];
  S3 = [NSString string];

So to conform to the protocol, I'd have something like this in  
MyClass.m

too:


In addition to the replies I want to give a hint to something else:


- (id)initWithCoder:(NSCoder *)decoder {

  self = [super init];


This is only correct, if your base class does not support NSCoding.
Otherwise you have to call -initWithCoder: (super).

Because this depends of the base class, we have a fragile base class
problem. (Adding NSCoding to the base class looks like doing  
everything
correct inside the base class, but will cause MyClass as a subclass  
to a
malfunction.) Keep in mind, that NSCoding can be added through a  
category.

So it looks safer to do:

if( [super respondsToSelector:@selector( initWithCoder: )] {
 self = [super initWIthCoder:decoder];
} else {
 self = [super init];
}


No, this will not work. Unless you've implemented -respondsToSelector:
yourself, [super respondsToSelector:] and [self respondsToSelector:]
will always return the exact same value (because they call the exact
same method).

Yup, you are complelty right. The correct code:

if( [BaseClass  
[EMAIL PROTECTED]( initIWithCoder: )] ) {

…

Sorry for that!

Cheers









I never had this problem in practice, but theoretically … (But  
maybe I got a

paranoia.)

Cheers







  S1 = [decoder decodeObjectForKey:@"S1"];
  S2 = [[decoder decodeObjectForKey:@"S2"] retain];
  S3 = [[decoder decodeObjectForKey:@"S3"] retain];
  return self;
}

(I'm not posting the encodeWithCoder: method.)

So finally, my question: am I right to retain S2 and S3, and not S1?
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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/ 
clarkcox3%40gmail.com


This email sent to [EMAIL PROTECTED]





--
Clark S. Cox III
[EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: NSCoding protocol

[Negm-Awad Amin]

Am Fr,03.10.2008 um 21:00 schrieb [EMAIL PROTECTED]:

I want MyClass to conform to the NSCoding protocol. But I'm puzzled  
about how to implement the initWithCoder: method.


Suppose I have this in MyClass.h:

NSString *S1, *S2, *S3;


and this in its init function:

S1 = @"a string";
S2 = [[NSString alloc] init];
S3 = [NSString string];

So to conform to the protocol, I'd have something like this in  
MyClass.m too:

In addition to the replies I want to give a hint to something else:


- (id)initWithCoder:(NSCoder *)decoder {

self = [super init];
This is only correct, if your base class does not support NSCoding.  
Otherwise you have to call -initWithCoder: (super).


Because this depends of the base class, we have a fragile base class  
problem. (Adding NSCoding to the base class looks like doing  
everything correct inside the base class, but will cause MyClass as a  
subclass to a malfunction.) Keep in mind, that NSCoding can be added  
through a category. So it looks safer to do:


if( [super respondsToSelector:@selector( initWithCoder: )] {
   self = [super initWIthCoder:decoder];
} else {
   self = [super init];
}

I never had this problem in practice, but theoretically … (But maybe I  
got a paranoia.)


Cheers







S1 = [decoder decodeObjectForKey:@"S1"];
S2 = [[decoder decodeObjectForKey:@"S2"] retain];
S3 = [[decoder decodeObjectForKey:@"S3"] retain];
return self;
}

(I'm not posting the encodeWithCoder: method.)

So finally, my question: am I right to retain S2 and S3, and not S1?
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Finder Crashes on File Open

[Negm-Awad Amin]

Am Do,09.10.2008 um 19:47 schrieb Brian Miller:


Hi All,

I have a Cocoa Core Data Document based application.  When files  
created with this application are opened via the Finder (or double  
clicked), the Finder crashes and restarts every time.  Opening files  
from within the application work fine, using Open With works fine.


The Finder crashes before the application is launched.

This happens even on a clean Leopard install.

This only happens on Leopard, works fine in Tiger.

I have changed store types to SQL, etc. problem persists.  I have  
changed extension, etc. and problem persists.


I am including Finder Crash report, I can provide other info as  
needed.  Since my app doesn't launch, I can't figure out what is  
going on.


Any help would be greatly appreciated.

http://www.apple.com/support/downloads/





Thanks,
Brian Miller


Process: Finder [13544]
Path:/System/Library/CoreServices/Finder.app/Contents/ 
MacOS/Finder

Identifier:  com.apple.finder
Version: 10.5.6 (10.5.6)
Build Info:  Finder_FE-6071900~15
Code Type:   X86 (Native)
Parent Process:  launchd [109]

Date/Time:   2008-10-09 00:13:50.397 -0700
OS Version:  Mac OS X 10.5.5 (9F33)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0005
Crashed Thread:  0

Thread 0 Crashed:
0   com.apple.CoreFoundation0x952332d4 CFRetain + 36
1   com.apple.CoreFoundation  	0x95203282 CFDictionaryAddValue +  
530

2   com.apple.CoreFoundation0x95203894 CFDictionaryCreate + 132
3   com.apple.LaunchServices  	0x96fd9cb0  
CFDictionary::CFDictionary(unsigned int, void const**, void const**)  
+ 74
4   com.apple.LaunchServices  	0x96feb395  
_LSFindApplicationsItem + 39

5   com.apple.LaunchServices0x96fd4b30 _LSOpenStuff + 1924
6   com.apple.LaunchServices  	0x96ff5462  
_LSOpenItemsWithRole_Common(FSRef const*, long, unsigned long,  
AEKeyDesc const*, LSApplicationParameters_V1 const*,  
ProcessSerialNumber*, long, FSRef*) + 374

7   com.apple.LaunchServices0x96ff2916 LSOpenFromRefSpec + 708
8   com.apple.finder0x0008f576 0x1000 + 583030
9   com.apple.finder0x0008f145 0x1000 + 581957
10  com.apple.finder0x0008e1e1 0x1000 + 578017
11  com.apple.finder0x00082f9f 0x1000 + 532383
12  com.apple.finder0x000d5a70 0x1000 + 871024
13  com.apple.finder0x000898b6 0x1000 + 559286
14  com.apple.finder0x0002bced 0x1000 + 175341
15  com.apple.finder0x00031a25 0x1000 + 199205
16  com.apple.finder0x00026822 0x1000 + 153634
17  com.apple.finder0x000266a2 0x1000 + 153250
18  com.apple.finder0x0002 0x1000 + 153190
19  com.apple.HIToolbox   	0x92166303  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 1181
20  com.apple.HIToolbox   	0x9216573d  
SendEventToEventTargetInternal(OpaqueEventRef*,  
OpaqueEventTargetRef*, HandlerCallRec*) + 405
21  com.apple.HIToolbox   	0x921655a2  
SendEventToEventTargetWithOptions + 58

22  com.apple.finder0x00080359 0x1000 + 521049
23  com.apple.finder0x00045067 0x1000 + 278631
24  com.apple.finder0x0004483f 0x1000 + 276543
25  com.apple.finder0x00026822 0x1000 + 153634
26  com.apple.finder0x000266a2 0x1000 + 153250
27  com.apple.finder0x0002 0x1000 + 153190
28  com.apple.HIToolbox   	0x92166303  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 1181
29  com.apple.HIToolbox   	0x9216573d  
SendEventToEventTargetInternal(OpaqueEventRef*,  
OpaqueEventTargetRef*, HandlerCallRec*) + 405
30  com.apple.HIToolbox   	0x92182092 SendEventToEventTarget  
+ 52
31  com.apple.HIToolbox   	0x92194268  
ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*,  
OpaqueEventRef*, void*) + 1208
32  com.apple.HIToolbox   	0x921666bc  
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*,  
HandlerCallRec*) + 2134
33  com.apple.HIToolbox   	0x9216573d  
SendEventToEventTargetInternal(OpaqueEventRef*,  
OpaqueEventTargetRef*, HandlerCallRec*) + 405
34  com.apple.HIToolbox   	0x92182092 SendEventToEventTarget  
+ 52
35  com.apple.HIToolbox   	0x921eec60 ToolboxEventDispatcher  
+ 86
36  com.apple.HIToolbox   	0x921eb4ba  
RunApplicationEventLoop + 222

37  com.apple.finder0x00023ab1 0x1000 + 142001
38  com.apple.finder0x000f39cd 0x1000 + 993741
39  com.apple.finder0x9a6e 0x1000 + 35438

Thread 1:
0   libSystem.B.dylib   0x9364b4a6 mach_msg_trap + 10
1   libSystem.B.dylib   0x93652c9c

Re: Newb Question about Delegtes and callbacks

[Negm-Awad Amin]

Am Do,09.10.2008 um 07:26 schrieb Ron Green:

Somehow in my education I missed out on delegates and callbacks. Can  
someone point me to a really good explanation that even a dummy like  
me can understand?
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_4.html#/ 
/apple_ref/doc/uid/TP40002974-CH7-SW18


Cheers

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Just when I thought I understood bindings.

[Negm-Awad Amin]

Am Do,09.10.2008 um 02:46 schrieb Tim Isted:

Did you setup the bindings using Interface Builder or  
programatically? If programatically, they work in only one direction  
so you need to call


[object1 bind:@"value" toObject:object2  
withKeyPath:@"whateverPathForKeyIs" options:nil];   and
[object2 bind:@"value" toObject:object1  
withKeyPath:@"whateverPathForKeyIs" options:nil];


Otherwise, make sure you're content object is KVC/KVO compliant etc.

Because this is not the first "IB magic" mail:

The IB cannot do something else. The IB writes the programmer's  
settings to a file. So he does nothing in your running program.


The nib-loader reads that file and "translates" this into code. Since  
the nib-loader is a "normal piece of code" it can do what you can do.  
And you can do, what the nib-loader can do. (okay, maybe there are  
undocumentated features …)


Cheers




Tim


On 9 Oct 2008, at 01:21, Chris Idou wrote:



I've got an NSObjectController controlling an object. This content  
object's properties are bound to various fields on my screen.


It seems that the bindings are only working in one direction.  
Editing the fields updates the object, but programmatically  
updating the object doesn't update the gui.


I've added observers to my fields, and they are definitely  
notifying of changes correctly.


I haven't made much use of NSObjectController before. Can anybody  
think what I might be doing wrong?

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: In dealloc(): ref @property, Can I use " = nil; " vs "[ release]; " ?

[Negm-Awad Amin]

Am Mi,08.10.2008 um 18:09 schrieb Lee, Frederick:


I've been setting my property thusly:



@property (nonatomic, retain) myVar;



...what about:



@property (nonatomic, copy) myVar; ?
In this case (deallocation) it doesn't matter, because you set nil.  
[nil copy] is nil.


Cheers






Ric.



From: Ron Lue-Sang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 11:06 AM
To: Lee, Frederick
Cc: cocoa-dev@lists.apple.com
Subject: Re: In dealloc(): ref @property, Can I use "object> =

nil; " vs "[ release]; " ?





On Oct 8, 2008, at 8:49 AM, Lee, Frederick wrote:





Assuming the following:



@property(retain) myVar;

...

@synthesize myVar;



...



-(void) dealloc {

 // Can I use:

self.myVar = nil;

// versus:

[myVar release];   //  ?

}





I've seen examples of using [myVar release].   But doesn't setting  
myVar

= nil does the same thing?



Which is the preferred way?



I prefer doing [myVar release]. Mainly because I don't want setMyVar
getting called during dealloc. And by this time there *shouldn't* be  
any

KVO observers for myVar (assuming the property was observed at all
before).



Yea yea - you've done @synthesize here so we know that the setter
doesn't do any custom work. But since we're in dealloc, we are -
obviously - not running under GC. Under refcounting, if you didn't
declare your property nonatomic, you're gonna take a lock during  
dealloc

to do setMyVar:nil.




--

RONZILLA







___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: In dealloc(): ref @property, Can I use " = nil; " vs "[ release]; " ?

[Negm-Awad Amin]

Am Mi,08.10.2008 um 17:49 schrieb Lee, Frederick:


Assuming the following:



@property(retain) myVar;

...

@synthesize myVar;



...



-(void) dealloc {

  // Can I use:

 self.myVar = nil;

// versus:

[myVar release];   //  ?

}





I've seen examples of using [myVar release].   But doesn't setting  
myVar

= nil does the same thing?



Which is the preferred way?

A never-ending story …

I prefer self.prop = nil (self setProp:nil]).

Some ideas:

1. Disadvantage: In a logical sense, you are on to deconstruct the  
object. So you can say, that it is not valid anymore and you are not  
allowed to send $anything to that object. I think, that you are inside  
the class and can handle this.


2. Disadvantage: You have to take care: side-effects! Think of undoing  
inside the setter. You probably do not want to register this operation  
for undoing. (Undo would fail, because the object is deconstructed.)


3. Advantage: Sometimes to care for consistency of your model inside a  
setter. And in this case I want to have this work done on  
deconstruction. If you just release it, maybe this work is never done  
by accident.


In must, most cases, especially when using @synthesize, it does not  
matter …


Cheers






Ric.





___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Conditional mouseDownCanMoveWindow for NSView?

[Negm-Awad Amin]

Am Do,02.10.2008 um 20:15 schrieb Daniel Weber:

I have a single nsview that draws the main content area for my  
application
and a bottom statusbar. This was done instead of using two different  
views
so the user can move objects from the statusbar to the main content  
area,
all with core animation effects. The view is not opaque. The problem  
I'm
having, though, is that I want the user to be able to drag the  
window when
the mouse is down on the statusbar, but not the main content area.  
In other
words, if the mousedown is within the statusbar's rectangle I want  
to return
YES for mouseDownCanMoveWindow. But if the mousedown is within the  
main
content area rectangle, I want to return NO. I have already tried  
setting a

flag in the mouseDown method and then returning that
in mouseDownCanMoveWindow. But it doesn't work. I guess mouseDown is  
not
called before mouseDownCanMoveWindow. Anyway, does anyone have any  
other

suggestions for this?
The only other thing I can think to do is setting a flag on  
mouseEnter and
mouseExit of the statusbar rectangle, but that doesn't seem  
particularly

elegant.

Thanks,


Maybe – I've never tried it, so it is just an idea – you can retrieve  
the mouse location in -mouseDownCanMoveWindow by using -currentEvent  
(NSApplication) and -locationInWindow (NSEvent).


Cheers



Dan
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: CoreData: Fetching object with maximum of property

[Negm-Awad Amin]

Am Mi,08.10.2008 um 05:42 schrieb Bill Dudney:


Hi Frank,

Sorry for not getting back sooner;

http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/Articles/pBNF.html#/ 
/apple_ref/doc/uid/TP40001796-217785


documents the BNF which is very cryptic but tells you everything  
that can be in the expression.


So something like this for the predicate;

@"loanToValueRatio = max(loanToValueRatio)"

Great, I missed this. I'll check it.

Thanks!

Cheers



should work but its been a while since I've messed with it. I did  
have somethign very similar to this working in a project I did last  
year.


I'm running off fallible memory here but I believe that the CD  
SQLite stuff will convert this to the proper SQL.


Good luck!

-bd-
http://bill.dudney.net/roller/objc

On Oct 7, 2008, at 6:04 AM, Frank Illenberger wrote:


Hi Bill,

I tried using predicates for this but did not succeed.
What would a predicate look like which finds the object of an  
entity with the maximum value for a property?


Frank

On Oct 7, 2008, at 1:08 PM, Bill Dudney wrote:


Hi Frank,

That and a whole lot more;

http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/predicates.html#/ 
/apple_ref/doc/uid/TP40001798


Good luck!

-bd-
http://bill.dudney.net/roller/objc

On Oct 7, 2008, at 3:49 AM, Frank Illenberger wrote:


Hi everybody,

does anybody know if CoreData under Leopard offers a way to fetch  
the object of an entity which the maximum of a certain property  
value, but without having to fetch all objects into memory?


Cheers

Frank


___

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

Please do not post 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/bdudney%40mac.com

This email sent to [EMAIL PROTECTED]






___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: CoreData: Fetching object with maximum of property

[Negm-Awad Amin]

Am Di,07.10.2008 um 15:12 schrieb Frank Illenberger:


Hello Negm-Awad,

thanks for helping.

Nicht dafür!

The idea with the fetch limit and the descending order solves my  
problem as I am using a SQLite store.

Sonst hättest du auch nicht das Problem. ;-)

Liebe Grüße
Amin




Cheers

Frank

On Oct 7, 2008, at 2:59 PM, Negm-Awad Amin wrote:


In contrast to Bill I think, that this is not possible with  
predicates. Why?


You want to get the maximum value of an attribute. Obviously this  
task includes the knowledge of all values stored in that attribute.  
So if Core Data should do that, there are two approaches:


a) Reading all attributes and compare it. This is, what you didn't  
want to do.

b) Delegate this task to the SQL store.

The second one is the solution. But predicates filters the  
attributes. They do not really aggregate them, even there are some  
aggregates available. These aggregates filters the source entity by  
resolving a relationship, but not by aggregating a min or max value.
*If there is a solution using predicates, I'm highly interested in  
it.*


However, there is another solution, that should work:
When you have an entity you can fetch the instances of the entity.  
And you can sort them by using a sort descriptor. And you can set a  
fetch limit. So simply create a fetch request, set the sort  
descriptor's key to the attribute and the sort descriptor's order  
to descending. Set the fetch limit to 1. Executing this fetch will  
lead to the instance with the value for that attribute.


AFAIK this sort descriptors and limits are passed to the sql store.  
So the SQL engine will do that work. (Anyway the SQL engine of  
course has to read every value.)



-bd-
http://bill.dudney.net/roller/objc

On Oct 7, 2008, at 3:49 AM, Frank Illenberger wrote:


Hi everybody,

does anybody know if CoreData under Leopard offers a way to  
fetch the object of an entity which the maximum of a certain  
property value, but without having to fetch all objects into  
memory?


Cheers

Frank


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: CoreData: Fetching object with maximum of property

[Negm-Awad Amin]

Am Di,07.10.2008 um 14:04 schrieb Frank Illenberger:


Hi Bill,

I tried using predicates for this but did not succeed.
What would a predicate look like which finds the object of an entity  
with the maximum value for a property?
In contrast to Bill I think, that this is not possible with  
predicates. Why?


You want to get the maximum value of an attribute. Obviously this task  
includes the knowledge of all values stored in that attribute. So if  
Core Data should do that, there are two approaches:


a) Reading all attributes and compare it. This is, what you didn't  
want to do.

b) Delegate this task to the SQL store.

The second one is the solution. But predicates filters the attributes.  
They do not really aggregate them, even there are some aggregates  
available. These aggregates filters the source entity by resolving a  
relationship, but not by aggregating a min or max value.

*If there is a solution using predicates, I'm highly interested in it.*

However, there is another solution, that should work:
When you have an entity you can fetch the instances of the entity. And  
you can sort them by using a sort descriptor. And you can set a fetch  
limit. So simply create a fetch request, set the sort descriptor's key  
to the attribute and the sort descriptor's order to descending. Set  
the fetch limit to 1. Executing this fetch will lead to the instance  
with the value for that attribute.


AFAIK this sort descriptors and limits are passed to the sql store. So  
the SQL engine will do that work. (Anyway the SQL engine of course has  
to read every value.)



Cheers


Frank

On Oct 7, 2008, at 1:08 PM, Bill Dudney wrote:


Hi Frank,

That and a whole lot more;

http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/predicates.html#/ 
/apple_ref/doc/uid/TP40001798


Good luck!

-bd-
http://bill.dudney.net/roller/objc

On Oct 7, 2008, at 3:49 AM, Frank Illenberger wrote:


Hi everybody,

does anybody know if CoreData under Leopard offers a way to fetch  
the object of an entity which the maximum of a certain property  
value, but without having to fetch all objects into memory?


Cheers

Frank


___

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

Please do not post 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/bdudney%40mac.com

This email sent to [EMAIL PROTECTED]




___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: comparing Strings.

[Negm-Awad Amin]

A littlebit tricky  (probably ugly), but shorter:

NSArray* components = [source componentsSeperatedByCharactersInSet: 
[NSCharacterSet …]];

NSString* result = [components componentsJoinedByString:@""];

;-)


Cheers

Am Di,07.10.2008 um 11:55 schrieb Graham Cox:



On 7 Oct 2008, at 7:46 pm, Gerriet M. Denkmann wrote:



On 7 Oct 2008, at 09:20, cGraham Cox <[EMAIL PROTECTED]> wrote:


On 7 Oct 2008, at 4:22 pm, Sandro Noel wrote:

i'm having a problem comparing some type of strings, for example  
the

one giving me a problem right now.
is let's say in my database i have 4 version of the same string .

"sandro's computer"
"sandro's_computer"
"sandros computer"
"sandros_computer"

I would like them to compare as being equal,
is there a way I can mingle with the comparing routine
to ask it to ignore some characters in the comparison?



First strip out the characters to be ignored:

NSString* tempString = [myString stringByTrimmingCharactersInSet:
[NSCharacterSet characterSetWithCharactersInString:@"'_ "]];

returns "sandroscomputer" given any of the above.


Are you quite sure?
The Tiger documentation says: "Returns a new string made by  
removing from both ends of the receiver characters contained in a  
given character set."


If this is still true, then the internal apostrophs would not get  
removed.


But maybe I am misunderstanding the documentation.
DId not actually test this.


Whoops, I made a mistake.

I thought I'd seen a method for stripping characters in a set from a  
string, and searching for it jumped on the stringByTrimming...  
method. But as you correctly state, that's not right! However, I  
wasn't going entirely mad, as I had seen the method, courtesy of a  
handy NSString category by Alastair Houghton. I hope he won't mind  
my copying it in below.


Apologies for the misleading info.

G.



@implementation NSString (RemovalOfCharsInSet)


/* Remove all characters from the specified set */


- (NSString *)		stringByRemovingCharactersInSet:(NSCharacterSet*)  
charSet options:(unsigned) mask

{
NSRange range;
NSMutableString*newString = [NSMutableString string];
unsignedlen = [self length];

mask &= ~NSBackwardsSearch;
range = NSMakeRange (0, len);
while (range.length)
{
NSRange substringRange;
unsigned pos = range.location;

		range = [self rangeOfCharacterFromSet:charSet options:mask  
range:range];

if (range.location == NSNotFound)
range = NSMakeRange (len, 0);

substringRange = NSMakeRange (pos, range.location - pos);
[newString appendString:[self 
substringWithRange:substringRange]];

range.location += range.length;
range.length = len - range.location;
}

return newString;
}


- (NSString *)		stringByRemovingCharactersInSet:(NSCharacterSet*)  
charSet

{
return [self stringByRemovingCharactersInSet:charSet options:0];
}


- (NSString *)  stringByRemovingCharacter:(unichar) character
{
	NSCharacterSet *charSet = [NSCharacterSet  
characterSetWithRange:NSMakeRange (character, 1)];


return [self stringByRemovingCharactersInSet:charSet];
}

@end

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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 retain counts, chapter 2

[Negm-Awad Amin]

Am Di,07.10.2008 um 04:56 schrieb James Walker:


[…]
How do you know the window isn't being deallocated? Examining  
retain counts is not going to tell you whether it is or not. The  
only way would be to subclass it and log the -dealloc method.


That's exactly what I did.  The dealloc method was not getting  
called before I added the workaround.  Well, the initial symptom  
was that I got an access violation because a custom view was asked  
to draw after the window had been closed and the window controller  
had been destroyed.  In the course of debugging that, I subclassed  
the window.
I'd suggest it would be more fruitful to chase down the actual bug  
rather than one that appears to be related but might be just a red  
herring.
If a view is being asked to draw but its window has gone away, then  
something's very, very off somewhere. Normally views are drawn by  
their windows, so how can such a situation arise? If you can answer  
that question you've probably found the problem. Is some other  
object retaining the view? Why? Are you drawing outside the usual  
update event cycle mechanism? Why?


When I said "the window has gone away", I spoke imprecisely.  I  
meant the window had been closed.  But, as I said, it had not been  
deallocated.

To clarify:
The window is closed (still allocated) and you get a draw request?


[…]


Cheers,
Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Collections can be simple Attributes in Core Data

[Negm-Awad Amin]

Am Do,02.10.2008 um 00:16 schrieb Jerry Krinock:



On 2008 Sep, 30, at 10:58, I. Savant wrote:


The 'correct' approach depends entirely on the model.


Yes, I appreciated Amin's thoughts but didn't have much to add.  An  
important step in modelling is to draw a potato around the part of  
the world that you're going to include.  You have to make a judgment  
of whether or not you include some detail based on how much effort  
it will take vs. the probability that it might be involved in some  
way that you have not yet imagined.
Yes, even modelling sounds like a pretty formal work, it is related to  
imaginations of what change could happen. (Sounds like the election of  
the u.s. president …?). More exactly: What are the changes, I have to  
include in my model?


Cheers,
Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Collections can be simple Attributes in Core Data

[Negm-Awad Amin]

Am Di,30.09.2008 um 19:58 schrieb I. Savant:

On Mon, Sep 29, 2008 at 3:03 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:


But now I find there is an even more natural way, which is to just  
leave
them as a set or array, and store in an attribute of type  
Transformable.
The default transformer en/decodes the collection into/from an  
NSData, and

everything "just works".

I'm surprised that I've never seen this discussed or documented.   
Is this

going to get me into any trouble?


Yes, because you get redundant and inconsistent model.


 If I'm reading this right, Jerry has a simple attribute called "pet
names". Usually this is used as a personally-identifiable unit of
information. Sure, lots of people might have fluffy, but do you really
need to  have a "PetName" entity, checking to see if an instance with
"name" property equal to "Fluffy" exists, creating one if not? In this
case (where we just want to store a short list of very personal things
as an attribute), sure you can archive an array or a set, just like
any other archiveable object.

 Now if the application needs to track people and their pets, I'd
imagine you'd have a whole "Pet" entity with a "name" property, but
that doesn't sound like what Jerry is getting at ...

When I read this:
"[…]Person's pets,[…]"
I assumed, that he has a person entity. Pets are persons, too. So I  
wouldn't create a new pet entity, but using a reflexiv relation to  
person to model the pets.


However, if it i a simple list of names related to nothing, you can  
model this with an simple array (or set) without creating an entity  
and relationship. But anyway, this is dangerous, too: Let's have a  
person (an instance of a person entity)
 "Amin Negm" with the pets "Dieter Müller", "Peter Schmitz" and  
"Michaela Schneider"

and a person
"Jerry Krinock" with the pets "Jo Miller", "Peter Smith" and (the  
same) "Michaela Schneider".
Now imagine, that Michaela marries and her name changes to "Michaela  
Suhrbier" …


The basic problem is, that a pet's name references something (an  
"entity" in its original philosophical meaning) outside the model. And  
the "silent assumption", that one attribute refers something outside  
the model, can fail: The name of a person can change without changing  
the person. (Okay, when Michaele marries, maybe she changes her  
personality. But this has nothing to do with IT, ;-))


In contrast to this, sometimes there is no problem doing so: If there  
would be colour attribute, say the colour of the hair, it is correct  
to model simply a string like "brunette" and so on. Even if Michaela  
changes the colour of her hair, this would be a change of *her* hair.
We would have the problem mentioned above only, if the name of the  
colour would change, say that "black" is called "zusgaasee" in future,  
This won't happen … *pray*






 The 'correct' approach depends entirely on the model.

Of course …




--
I.S.

Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: expanding core data model sheet

[Negm-Awad Amin]

Am Mo,06.10.2008 um 16:48 schrieb Daniel Child:


Hi All,

This strikes me as something that should be absurdly easy to do, but  
I can't seem to find any examples with more than two or three  
entities, and so no one mentions it, and I don't see it in the  
documentation.


How do you expand the Core Data model sheet??? (The part where  
entities are displayed as boxes with lines to show the relations) (I  
don't mean zoom in/out, actually expand to make space for more  
entities.)
Simply drag an entity (the box of the entity) outside the sheet, i. e.  
to the left. A "new one" will appear. Too easy? ;-)


I would think they'd provide some sort of "pages" concept for more  
complex models. Clearly with one sheet you will run out of place  
after 10 - 12 entities. I could collapse them, but still, that's not  
ideal.

If anybody @Appl reads this:

I'd like to have more options for the layout. For example I want to be  
able to "route" the arrows between the relationships. (When I worked  
as hw developer, every program for schematic entry could do this.)


Cheers



Thanks.

Daniel
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Crash with toolbars

[Negm-Awad Amin]

Am Mo,06.10.2008 um 12:24 schrieb Felipe Monteiro de Carvalho:


BOOLs are signed char.


Thanks, the toolbar is working now. Does anyone know where BOOL is
declared?

objc.h


It's a very common word, so it's hard to find ...

Command double click on "BOOL".





--
Felipe Monteiro de Carvalho

Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: window controllers and managed object contexts

[Negm-Awad Amin]

Am Sa,27.09.2008 um 19:01 schrieb Daniel Child:

Hmm, well that seems to be the catch. I can't get the bindings to  
work for the MOC.
First off, to set up the table displayed in the window loaded with a  
separate nib file, I simply dragged in an "entity" object from the  
Librarian. That doesn't set up an MOC binding, but, following an on- 
line tutorial, I told it to bind the MOC parameter to File'sOwner,  
and immediately the setting is managedObjectContext. (Looked  
promising.)


Now, when I init the window, I do pass in a copy of the App's own  
MOC (I don't have multiple MOCs). But now I get the message:


not key-value coding-compliant for the value: managedObjectContext.

Which makes me wonder, just how much code needs to go into setting  
up a separate window controller, and is it worth it (speed-wise) if  
your app only has four or five windows. From a tidiness standpoint,  
it's nice of course to separate the control portion of MVC for each  
window, but is all that copying and key-value coding going to be  
faster than simply loading one big nib?


And, given that Xcode is supposed to automatically set up bindings  
correctly for things like Entity, why does it not work in this case?  
The error message seems to suggest I need to be doing something like:


[myWindow setObject: theMOC forKey: @"managedObjectContext"

but the tutorial online uses plain accessors (with the local copy of  
MOC as an ivar, not a property) ... and works. One difference is  
that their's is a doc-based CoreData app, and mine is not. But I  
don't see why that should matter


So I'm forced to use a property to express MOC in the window  
controller???
You can bind the moc to the application-pbject (using the pop-up) and  
use the key path: delegate.managedObjetContext


Cheers,
Amin




On Sep 26, 2008, at 3:29 PM, Kyle Sluder wrote:


Erm, NSWindowController shouldn't be asking for a MOC.  Perhaps
whatever NSControllers you have in your nibs haven't had their
managedObjectContext bindings fixed?


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: showing window causes EXC_BAD_ACCESS

[Negm-Awad Amin]

Am Sa,27.09.2008 um 22:44 schrieb Uli Kusterer:


On 27.09.2008, at 22:13, Michael Ash wrote:

But suddenly you're back to having to think about the global picture
of who owns objects, which is what Cocoa's memory management system  
is

supposed to avoid.




Retains and releases should be balanced. This doesn't just means that
they should ultimately be equal in number, it also means that the  
same

entity should be doing both. "Release when closed" breaks the
fundamental memory management rules and, as a consequence, makes it
much more complicated to think about how the program works.


You're misunderstanding the purpose of Cocoa's memory management  
system: It's not about not having to care who owns what, it's about  
not having to worry about shared ownership. There are many cases  
(threading and creation of objects come to mind) where ownership is  
handed from one object to the other.


In this case, you specify in the NIB that you want your window to  
release itself, and you haven't written your outlet in a way that it  
retains the window. If you expect your window to not go away when  
closed, you're expecting too much.

Hallo Uli, :-)

I think, that you have to keep in mind, that sometimes you have  
instances in a nib, which have no retain at all. Simply think of a  
stand-alone delegate for an UI-element. It is not retained by the UI- 
element (delegates are not retained to avoid retain cycles as you know).


So loading a nib unfortunatly is not balanced. When you think of  
loading the nib-objects as instance creation, the mm-rules are broken:  
Usually you balance the +alloc with a -retain (some lines later,  
sometimes in -dealloc) or an immediate -autorelease. The nib-loader  
does not do that. So $somebody has to release the instances, when the  
nib is unloaded.


So loading objects through the nib-loader is like a naked +alloc, - 
init*.


You can see eht "nib-exception" of mm-rules, when you handle the top- 
level objects your own. You probably store them in an array, which  
sends a retain to the objects. The first thing you have to do, is to  
send a -release to all top-level objects to balance the nib-loaders  
+alloc.


So, after all: You have to release top-level objects of the nib  
manually, when unloading the nib.


I think, that "release, when closed" is simply a convenient option,  
because in many cases you have only a window in the nib and it is the  
only object, that has to be released. And usually closing a window  
means "unloading the nib" to get the free memory. So in this cases you  
have to do nothing in your code, if you checked that option.


That said, I fully agree on one partial point you raised: 'Release  
when closed' is dangerous and complicates matters.
Yes. Anyway you should always use a window controller or view  
controller to get rid of the problems with nibs and mm.


It should be off by default, and it's very likely that nobody would  
miss it.
In this case, you will get a memory leak everytime you simply do not  
care about the nib loading. You would always need extra release-code.  
Think of a simple about-window. You have an action, let's call it - 
showAboutWindow: and load the nib there. If the user closes this  
window, it is released automatically. You have to do nothing. And you  
do not have to take care about other instances in that nib, because  
there are no other instances: 0 lines of code.


(In reality this is not true, because you have to take care, that the  
nib is not reloaded. So you have to handle the window close for that  
purpose and then can add a -release.)


That said, I don't know what it was originally introduced for. Any  
old NeXTies here who know?
longW told me, that there had not been window controllers prior to  
10.0 to handle the mm of nib-objects. :-)

view controllers are introduced with 10.5.


So the whole nib-loading mechanism looks a littlebit – eh –  
archaeological.


Cheers,




Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de





___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Collections can be simple Attributes in Core Data

[Negm-Awad Amin]

Am Fr,26.09.2008 um 03:08 schrieb Jerry Krinock:

When I first looked at Core Data, I saw that there was no such  
attribute type as "Array" or "Set", and concluded that collections  
must be modelled as relationships.  This would be overkill in many  
cases, for example, in a Person type of application if you wanted to  
list the names of each Person's pets, but had no interest in the  
pets themselves.
If $user changes the name of one person, the names of the pets  
shouldn't be changed, too?


This "overkill" simply avoids redundancy to ensure consistency.

So, one way I worked around this was to store the pet names as an  
attribute petNamesString of type String, using a delimiter  
character, and transforming on the way in and out of the store.

This seems to be "overkill". ;-)

But now I find there is an even more natural way, which is to just  
leave them as a set or array, and store in an attribute of type  
Transformable.  The default transformer en/decodes the collection  
into/from an NSData, and everything "just works".


I'm surprised that I've never seen this discussed or documented.  Is  
this going to get me into any trouble?

Yes, because you get redundant and inconsistent model.

Cheers

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: binding to static text

[Negm-Awad Amin]

Am Do,11.09.2008 um 02:38 schrieb James Walker:

I have a static text item whose value is bound to an  
NSUserDefaultsController.  It correctly shows the value stored as a  
default.  However, if I programmatically change the text (with - 
[NSControl setStringValue:]), the new value does not get saved.   
What am I missing?

--
 James W. Walker, Innoventive Software LLC
 
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]



The bound property (stringValue) of the bound object (instance of  
NSControl) is set automatically, when the observed property (dont'  
know) of the observed object (instance of NSUserDefaultsController)  
changes.


Nothing is done in the opposite direction (changing the bound property  
programmatically)


cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Problems with Key Observing Registration Performance

[Negm-Awad Amin]

Am Mi,10.09.2008 um 03:48 schrieb Markus Spoettl:


On Sep 9, 2008, at 5:28 PM, Markus Spoettl wrote:
These numbers come from a test case with 140 objects, when I double  
the object number, the test never finishes (at least not within 10  
minutes).



OK, I did some more testing and timing and there is a solution -  
which I don't understand:


Testing with 326 objects, adding each of the objects to the array  
like this


  NSMutableArray *kvoArray = [self mutableArrayValueForKey:@"array"];
  for (MyObject *obj in inputData) {
  [kvoArray addObject:newObject];
  }

This takes 580 seconds. Each add causes a chain reaction of events  
that eventually adds a new NSView to the collection view. I've  
experimented with setting the whole array at once using -setArray:  
but that does not make any difference.


However, adding an auto-release pool does make a huge difference:

  NSMutableArray *kvoArray = [self mutableArrayValueForKey:@"array"];
  for (MyObject *obj in inputData) {
  NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

  [kvoArray addObject:newObject];

  [pool release];
  }

The same operation now takes 60 seconds. That's 10% of the original  
time.


What I don't understand is why adding the auto-release pool has such  
a dramatic impact on registering observers on the objects. Anyone  
know why?


When you create an object with +alloc and then release it some lines  
later, it is possible, that in -init or simply using the object causes  
others (helper) objects to be created in the ARP. When you release the  
"front object" you do not handle the "back objects", so they are still  
alive.


If you use your own ARP, these "back objects" will be released, too.

I assume, that you understand german, so I can link to my article on a  
german wiki:
http://wiki.osxentwicklerforum.de/doku.php? 
id 
= 
wiki:speicherverwaltung 
&s[]=speicherverwaltung#problemgross_wachsender_arp


Cheers,
Amin





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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Do I Need Multiple NSArrayControllers For This?

[Negm-Awad Amin]

Am Di,09.09.2008 um 16:11 schrieb Jamie Phelps:

I have a Core Data entity that has a date and relationship. I want  
to create a label like.


"25 Foos (12 New)"

A Foo is active if it its relationship is null and it is new if its  
date is within the startDate and endDate specified by the user.


My intuition is that this does require two NSArrayControllers each  
with a filter predicate binding to get the desired array of Foos,  
but I wanted to see if there was anything I hadn't considered.


Thanks,
Jamie

I do not know, whether I understood your question correct. If so:
You can combine conditions with logical operators

http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html#/ 
/apple_ref/doc/uid/TP40001795-215851


and you can use BETWEEN to check for a (date) range.

http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html#/ 
/apple_ref/doc/uid/TP40001795-215832


Cheers,
Amin



___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Best 'native' formats for NSImage and NSSound?

[Negm-Awad Amin]

Hi,

do you load the image with -imageNamed: and add the suffix? IIRC, this  
forces NSImage to reload the image file. Did you try to refer to the  
image without suffx? In this case NSImage looks for a appropiate image  
in iits image heap and takes this one instead of the file. If it does  
not find a image with this name, it looks inside the bundle for the  
image, accepting all suffixes.


Maybe this helps.


Cheers,
Amin


Am Mo,01.09.2008 um 19:18 schrieb Matt:

I am building an app that uses NSImage to repeatedly draw subrects  
from a
set of large .PNG files. I am also using NSSound to play sound  
effects. I

have been using .WAV files for the NSSound's.

In running Shark on my app recently I noticed that by far, my app  
spent most

of its time in: CGSConvertBGR888toRGBA.

I'm having trouble understanding what this means. It appears that
CoreGraphics is having to convert some of my non-alpha channel  
images to

have an alpha, and perhaps re-order the bytes? But shouldn't these
conversions only occur once, when CG realizes it needs this additional
channel? My app is re-using the same NSImages each frame, simply  
compositing

various sub-rects from the original large images.

This leads me to my question, which is two-part: can I optimize my  
graphics
files or manipulate NSImage into avoiding this  
(CGSConvertBGR888toRGBA)

processing? Or this an unavoidable part of the drawing?

And also, seeing how much work NSImage is having to do, it got me  
wondering,
are there any image/sound file formats which require 'less work' on  
the part
of NSImage and NSSound? In terms of loading the initial data,  
unpacking the

bytes, etc.

I was wondering if switching to .TIFF or .AIFF (or any other  
formats) could

possibly provide a performance boost?

Thank you in advance for any help/advice,
-Matt
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: understanding conversions between CF and NS datatypes

[Negm-Awad Amin]

Am Do,04.09.2008 um 20:20 schrieb Michael Ash:

On Thu, Sep 4, 2008 at 1:40 PM, Negm-Awad Amin [EMAIL PROTECTED]> wrote:


Am Do,04.09.2008 um 18:27 schrieb Michael Ash:

On Thu, Sep 4, 2008 at 10:41 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
>

wrote:


Am Sa,30.08.2008 um 05:22 schrieb Michael Ash:


Ultimately the most important thing to understand about toll-free
bridging (the link between CF and NS data types) is that you don't
have to convert anything. You *can't* convert anything. Because  
they

aren't two different things. An NSArray *is* a CFArray. An
NSMutableArray is a CFMutableArray. They are just two different  
names

for the same type.


I'm not sure, whether this is completly correct. I would prefer  
to say,

that
are two different names of two different types, which are
interchangeable.


No, they are the same type.


But AFAIK in some (rare) cases, CF and NS behaves differently.


Meaningless. You can subclass NSArray and get whatever behavior you
want. The result is still an NSArray (and still a CFArray).


But I wouldn't say, that a subclass of a baseclass is the same type  
as the
baseclass. You can assign a subclass instacne to a baseclass  
pointer and
there is no casting, so indeed the situation is similiar to NSArray  
and

CFArray.


Subclassing is supposed to be an "is a" relationship. In other words,
if I subclass NSMutableArray and call the new class a MyMutableArray,
then a MyMutableArray is an NSMutableArray. An NSMutableArray is in
turn an NSArray, and an NSArray is an NSObject.

Likewise, an NSArray is a CFArray, and a CFArray is an NSArray. They
are just two different names for the same thing. The fact that you can
obtain different behaviors depending on how you create them is not all
that interesting, as that happens *anyway* with many different
classes.
I completly agree, that an instance of a subclass "is a(n)" instance  
of the baseclass. No doubt.
But, if I understood you correct, you said that the subclass and a  
baseclass are the same type (as CFArray and NSArray are). Since type  
is a formal term, I do not agree with this statement.
Of course, with subclassing the term type became more shaded. But I  
think, that there is still a formal meaning of it.






But saying, that assigning proves the type identity (correct word?) …


Not sure what you mean here.

1: You said, that one can pass around CFArrays and NSArrays. I agreed.
2: You said this in relation to its type identity. I did not agree.
I simply wanted to say, that even if statement 1 is true, you cannot  
say, whether statement 2 is true.


Amin




Mike
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: understanding conversions between CF and NS datatypes

[Negm-Awad Amin]

Am Do,04.09.2008 um 18:27 schrieb Michael Ash:

On Thu, Sep 4, 2008 at 10:41 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:


Am Sa,30.08.2008 um 05:22 schrieb Michael Ash:


Ultimately the most important thing to understand about toll-free
bridging (the link between CF and NS data types) is that you don't
have to convert anything. You *can't* convert anything. Because they
aren't two different things. An NSArray *is* a CFArray. An
NSMutableArray is a CFMutableArray. They are just two different  
names

for the same type.


I'm not sure, whether this is completly correct. I would prefer to  
say, that
are two different names of two different types, which are  
interchangeable.


No, they are the same type.


But AFAIK in some (rare) cases, CF and NS behaves differently.


Meaningless. You can subclass NSArray and get whatever behavior you
want. The result is still an NSArray (and still a CFArray).

Mike
But I wouldn't say, that a subclass of a baseclass is the same type as  
the baseclass. You can assign a subclass instacne to a baseclass  
pointer and there is no casting, so indeed the situation is similiar  
to NSArray and CFArray.


But saying, that assigning proves the type identity (correct word?) …

Cheers,
Amin


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: understanding conversions between CF and NS datatypes

[Negm-Awad Amin]

Am Do,04.09.2008 um 16:41 schrieb Negm-Awad Amin:



Am Sa,30.08.2008 um 05:22 schrieb Michael Ash:

On Fri, Aug 29, 2008 at 1:38 PM, Allen Curtis  
<[EMAIL PROTECTED]> wrote:
1. Where can I get a better understanding of the data conversion  
between

these different frameworks?
2. Ultimately the device path names will appear in a ComboBox. Was  
it

necessary to convert the CFMutableArray to a NSMutableArray for the
datasource function?


Ultimately the most important thing to understand about toll-free
bridging (the link between CF and NS data types) is that you don't
have to convert anything. You *can't* convert anything. Because they
aren't two different things. An NSArray *is* a CFArray. An
NSMutableArray is a CFMutableArray. They are just two different names
for the same type.
I'm not sure, whether this is completly correct. I would prefer to  
say, that are two different names of two different types, which are  
interchangeable. But AFAIK in some (rare) cases, CF and NS behaves  
differently. I know this example


CFArrayCreateMutable
Creates a new empty mutable array.

…
capacity
*The maximum number of values that can be contained* by the new  
array. The array starts empty and can grow to this number of values  
(and it can have less). If this parameter is 0, the array’s maximum  
capacity is not limited. The value must not be negative.


…

arrayWithCapacity:
…

numItems


The *initial capacity* of the new array.

…

Discussion
Mutable arrays *expand as needed*; numItems simply establishes the  
object’s initial capacity.





So, if you get an CFMutableArray and cast it to an NSMutableArray  
you will get unintended results on inserting behind the capacity.


Cheers,
Amin
Oh, I tried it (Casting an CFMutableArray to an NSMutablearray and  
send masses of -addObject: to it) and did not get an error?


Can somebody explain that?

Cheers,
Amin






It gets slightly tricky because the compiler doesn't know this  
crucial

fact. So when you have a CFMutableArrayRef and you try to treat it
like it was an NSMutableArray*, the compiler gets complainey. So you
have to do some fancy typecasting to shut it up. But it's very
important to understand that this typecast doesn't do any sort of
conversion or translation or anything of the sort, it just tells the
compiler to look at the exact same pointer to the exact same object  
in

a new light.

Mike
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: understanding conversions between CF and NS datatypes

[Negm-Awad Amin]

Am Sa,30.08.2008 um 05:22 schrieb Michael Ash:

On Fri, Aug 29, 2008 at 1:38 PM, Allen Curtis <[EMAIL PROTECTED]>  
wrote:
1. Where can I get a better understanding of the data conversion  
between

these different frameworks?
2. Ultimately the device path names will appear in a ComboBox. Was it
necessary to convert the CFMutableArray to a NSMutableArray for the
datasource function?


Ultimately the most important thing to understand about toll-free
bridging (the link between CF and NS data types) is that you don't
have to convert anything. You *can't* convert anything. Because they
aren't two different things. An NSArray *is* a CFArray. An
NSMutableArray is a CFMutableArray. They are just two different names
for the same type.
I'm not sure, whether this is completly correct. I would prefer to  
say, that are two different names of two different types, which are  
interchangeable. But AFAIK in some (rare) cases, CF and NS behaves  
differently. I know this example


CFArrayCreateMutable
Creates a new empty mutable array.

…
capacity
*The maximum number of values that can be contained* by the new array.  
The array starts empty and can grow to this number of values (and it  
can have less). If this parameter is 0, the array’s maximum capacity  
is not limited. The value must not be negative.


…

arrayWithCapacity:
…

numItems


The *initial capacity* of the new array.

…

Discussion
Mutable arrays *expand as needed*; numItems simply establishes the  
object’s initial capacity.





So, if you get an CFMutableArray and cast it to an NSMutableArray you  
will get unintended results on inserting behind the capacity.


Cheers,
Amin



It gets slightly tricky because the compiler doesn't know this crucial
fact. So when you have a CFMutableArrayRef and you try to treat it
like it was an NSMutableArray*, the compiler gets complainey. So you
have to do some fancy typecasting to shut it up. But it's very
important to understand that this typecast doesn't do any sort of
conversion or translation or anything of the sort, it just tells the
compiler to look at the exact same pointer to the exact same object in
a new light.

Mike
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Reflexive Many-to-Many in Core Data?

[Negm-Awad Amin]

Am Mo,01.09.2008 um 23:16 schrieb Sam Krishna:


Is a reflexive many-to-many relationship possible in Core Data?

Why not? To try it, simply do:

Create an entity Verse.
Add two to-many relationships to Verse, say, relatedToVerses and  
relatedFromVerses.

Make them the inverse relationship of each other.
Build an user interface with two array controllers and table views.

Cheers,
Amin



Here's what I'm thinking:

I have a table (Verse) and it needs to have a to-many relationship  
back to itself. The relationship name will be crossReferences. Is  
this possible or will I need to come up with some contortion for  
Core Data.


This was fairly doable (just took some mind-bending at the EOModel  
level) back in the hoary old days of EOF.


TIA!

Live Playfully,

Sam

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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 do I use Sort Descriptor binding in IB on my array controller?

[Negm-Awad Amin]

Am Sa,30.08.2008 um 16:58 schrieb <[EMAIL PROTECTED]> <[EMAIL PROTECTED] 
>:


I'm struggling with this very problem, can anyone point me in the  
right

direction?

Many Thanks

Amy
You can do it the way Quincey described, but I think that you do not  
need bindings, because your problem sounds statical and a pop up  
button is usually sorted by one property. (Okay, you can have a  
ascending/descending-change, but this is rare.)


*If* it is statically, there is another solution: Add an outlet to the  
controller object (one of these mentioned by quincey) and connect it  
to the array controller (ctrl-dragging in IB). Then you can set the  
sort desciptors of the array controller in your code using  
setSortDescriptors:. The best place depends on the type of the file's  
owner. Typically you have a window controller or an view controller  
subclass and simply put the code into -awakeFromNib.


Cheers,
Amin





FROM : Rick Mann
DATE : Sun Jun 01 02:52:25 2008



I have an array controller in IB that is used by a popup menu in a
table view column. I would like those menu items to be sorted. Is
there a quick, mostly-IB way to configure that? The presence of a  
sort

descriptor binding for the NSArrayController makes me think it should
be pretty straightforward.



TIA,
--
Rick


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Design Question: Bindings & Custom Views

[Negm-Awad Amin]

Okay, I  – hopefully – understand you now:
You have a view with some (model) objects displayed.
There is another view (potentially or really?) that can display these  
objects, too
The additional attributes are specific for each displayed object and  
each view?

Correct? (There is a german phrase: "The hope dies last")

So you have an n-to-m relationship between between objects and views.  
And you have additional attributes for each of these relationship  
"instances". ( … for every concrete relationship.)


Yes, IMHO it is a good idea to "personalize" (bad translation, I do  
not know a better one) this relationship and represent it with  
instances of a special class.


I did something similiar (if I understood you correct) inside the  
model layer (this does not really matter here)  in a lawfirm  
application. I had the problem, that I had an n-to-m relationship  
between files and clients. On each "instance" of the relationship I  
needed some additional attributes. (Something like the state of the  
client related to this file.) I broke the n-to-m relationship and  
modelled a new entity FileClient that holds the additional attributes.


Of course this was easier to me, because it happens solely inside the  
model layer. I did not have to register and handle observations. But I  
think, that it is the same approach in the core.


Maybe this helps …

Cheers,
Amin


Am Do,28.08.2008 um 11:06 schrieb Oleg Krupnov:


Yes, you are correct. I am looking not to break MVC and also get the
correct implementation of binding in a custom view

Just an example: I had a graphic application that drawed some  
inserted
shapes. The shape itself is a part of the model, the color of the  
shape,
too. But when the user selects a shape (symbol), the color should  
change. So
the drawing of the shape depends on a view property. I think, this  
is the

core of your problem.


Selection may not be a good example, because it is a "global" property
of the view, among all objects in the view, whereas I am talking about
states *per each" object in the view. Such state properties become
particularly indispensable for drawing, because drawRect message is
called "asynchronously", i.e. in the next event loop, not in direct
response to the binding's KVO message. The other case is when I need,
for performance reasons, to associate some view-specific cached data
with an object in the view, to avoid recreating it each time I need
the data to respond to the binding's KVO message.

In other words, I need a way to associate additional
custom-view-specific properties with model object, without adding them
as transitive properties to the model. What is the best way to do
this? Or maybe your point is that this is a bad idea at all and such
problem should not arise, and I need to include everything in the
model? What is the standard workaround suggested in Cocoa?

I solved it by returning only bezier paths and colors from the  
model. So the

shape itself (model) is still a part of the model, but the drawing
(depending on the view) is done inside the view. (Simply by  
stroking the

paths.)


It is not completely clear how this would help me to resolve the above
problem. It is not a problem for me to store the bezier paths and
colors in the model. But what about some volatile custom-view-specific
states that have nothing to do with the model?



The other completely different design I am also considering is to
create and bind a "subview" object for each model object. By "subview"
I mean just a subclass of NSObject that is bound to its model
counterpart. It could work like this: The custom NSView observes its
NSTreeController and when a new child model object is created, the
custom NSView creates the corresponding subview object (All subview
objects are owned by the custom NSView) and binds it to the model
object programmatically. When the model object is changed or removed,
its subview counterpart responds correspondingly. In this manner I
could hold all the view-specific states and cache data in the subview
object. What do you think?




On Thu, Aug 28, 2008 at 11:35 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:


Am Do,28.08.2008 um 10:15 schrieb Oleg Krupnov:

Parts of your first question remind me of a situation that I had.  
Erik

Buck gave me some great advice and part of it was the following:


If you are worried about adding drawing code to a "Model" object,  
add the
drawing code in a category of * and maintain  
the category

implementation in the "View" subsystem.


*I changed the words he used here because he used the name of my  
specific

class and I wanted to make it more readable in the general case.


This will let you put a category into every view that you want to  
so that

your model objects get handled correctly for each view.


This may be indeed a good idea to use categories for this purpose.  

Re: Design Question: Bindings & Custom Views

[Negm-Awad Amin]

Am Do,28.08.2008 um 10:15 schrieb Oleg Krupnov:

Parts of your first question remind me of a situation that I had.  
Erik Buck gave me some great advice and part of it was the following:


If you are worried about adding drawing code to a "Model" object,  
add the drawing code in a category of * and  
maintain the category implementation in the "View" subsystem.


*I changed the words he used here because he used the name of my  
specific class and I wanted to make it more readable in the general  
case.


This will let you put a category into every view that you want to  
so that your model objects get handled correctly for each view.


This may be indeed a good idea to use categories for this purpose. Is
it what everybody is using?

I have only one problem with this approach: As I mentioned before, I
need to add custom-view specific instance variables (states) to the
model object's category. The Objective-C categories do not allow
adding instance variables, only methods

I am considering to create a dictionary owned by the custom view,
containing state objects keyed by model object unique ID. This is a
kind of surrogate of subclassing the model objects inside the custom
view. I am not sure this is a good idea though. Are there other
approaches?
If I understood you correct, you think, that you fear a voilation of  
the MVC pattern. Correct?


Think about some points:
- sometimes the shape or something like this is a true part of the  
model. Think about predefined shapes and so on. So there is nothing  
wrong in storing that informtion in the model.
- Can you isolate the "shape-part" (model) from the drawing part  
(obviously depending on view states)?


Just an example: I had a graphic application that drawed some inserted  
shapes. The shape itself is a part of the model, the color of the  
shape, too. But when the user selects a shape (symbol), the color  
should change. So the drawing of the shape depends on a view property.  
I think, this is the core of your problem.


I solved it by returning only bezier paths and colors from the model.  
So the shape itself (model) is still a part of the model, but the  
drawing (depending on the view) is done inside the view. (Simply by  
stroking the paths.)


Cheers,
Amin



___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Core Data - use of simple accessors vs. KVC

[Negm-Awad Amin]

Am Do,28.08.2008 um 06:43 schrieb Caleb Strockbine:



On Aug 27, 2008, at 2:43 PM, Negm-Awad Amin and mmalc crawford argued:


You can subclass NSManagedObject and add properties using
@property and @dynamic, which means, that the accessors will be
generated dynamically at run-time. (Without @dynamic you will get
a compiler warning: incomplete implementation blablabla)


There is no need to create a subclass,

"You *can* subclass NSManagedObject

"

you can use a category instead.
There is no need to create a category. You can use a subclass  
instead.



It's not clear what your point is.
There is no need to create a custom class if all you're doing is
declaring accessor methods.  Your reply did not state that.


Perhaps I'm being dense here, but why would you use a category on  
NSManagedObject to declare accessors that only actually apply to a  
single entity? Managed object models typically contain more than one  
entity, and each of those entities necessarily has a different set  
of properties (otherwise, you wouldn't need more than one entity).  
If you use a category on NSManagedObject to add accessors for each  
entity in your model, don't you end up with a situation where all  
your entities have declared accessors for other entities'  
properties? On the other hand, if you subclass NSManagedObject where  
necessary, each subclass' accessors will be specific to it's  
corresponding entity.


Am I missing something?
No, you misssed nothing. Using a category of NSManagedObject is mixing  
machine.


You should never do that.


Cheers,
Amin



-Caleb


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Core Data - use of simple accessors vs. KVC

[Negm-Awad Amin]

Am Mi,27.08.2008 um 19:57 schrieb mmalc crawford:



On Aug 27, 2008, at 10:36 AM, Negm-Awad Amin wrote:



Am Mi,27.08.2008 um 19:19 schrieb mmalc crawford:



On Aug 27, 2008, at 9:48 AM, Negm-Awad Amin wrote:

Am Mi,27.08.2008 um 18:22 schrieb Oleg Krupnov:
Suppose I have a Core Data model object MyObject with property  
myProp

defined in the model editor's schema.
Can I use the simple accessors like this:
[myObj myProp]
[myObj setMyProp]
or am I forced to use the rather clunky valueForKey/ 
setVakyeForKey messages?


<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdUsingMOs.html 
>

Managed objects automatically fake accessors for entities.


No, they don't fake accessors for entities, they dynamically  
generates accessor methods for managed object classes.

I call this fake.

"Fake" is not terminology that is used in this context, and it's at  
best misleading.

It did not mislead him.


The system dynamically generates accessor methods, that's it.



You can subclass NSManagedObject and add properties using  
@property and @dynamic, which means, that the accessors will be  
generated dynamically at run-time. (Without @dynamic you will get  
a compiler warning: incomplete implementation blablabla)



There is no need to create a subclass,

"You *can* subclass NSManagedObject  …"

you can use a category instead.
There is no need to create a category. You can use a subclass  
instead.



It's not clear what your point is.

I said that you *CANÜ* do it this way. Anyway it is the recommended

There is no need to create a custom class if all you're doing is  
declaring accessor methods.  Your reply did not state that.
Oh, I see. Sorry. I thought, that "can" refers to a possibility. I did  
not know, that it refers to a need. I thought, that I have to use  
words like "have to", "must" to describe a need.


Sorry for that




There is documentation about @property and Core-Data esp. in  
relation to retain/copy/assign. (The quintessence: Use retain!)



You may also consider 'copy' if appropriate
"There is documentation about @property and Core-Data esp. in  
relation to retain/copy/assign. (The quintessence: Use retain!)"



You gave no pointer to the actual documentation.
A mentioned the documentation. I did not link it. The TS was able to  
find the documentation.


Beside this, it said "quintessence". Since the documentation recommend  
using -retain and this hint is in italics, I think, that this is the  
quintessence.


It is important to also consider the use of 'copy' since it is  
important in some cases.
"There is documentation about @property and Core-Data esp. in relation  
to retain/copy/assign. (The quintessence: Use





mmalc

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Core Data - use of simple accessors vs. KVC

[Negm-Awad Amin]

Am Mi,27.08.2008 um 19:19 schrieb mmalc crawford:



On Aug 27, 2008, at 9:48 AM, Negm-Awad Amin wrote:

Am Mi,27.08.2008 um 18:22 schrieb Oleg Krupnov:
Suppose I have a Core Data model object MyObject with property  
myProp

defined in the model editor's schema.
Can I use the simple accessors like this:
[myObj myProp]
[myObj setMyProp]
or am I forced to use the rather clunky valueForKey/setVakyeForKey  
messages?


<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdUsingMOs.html 
>





Managed objects automatically fake accessors for entities.

No, they don't fake accessors for entities, they dynamically  
generates accessor methods for managed object classes.

I call this fake.

Anyway the TS understood this.

You can subclass NSManagedObject and add properties using @property  
and @dynamic, which means, that the accessors will be generated  
dynamically at run-time. (Without @dynamic you will get a compiler  
warning: incomplete implementation blablabla)



There is no need to create a subclass,

"You *can* subclass NSManagedObject  …"


you can use a category instead.

There is no need to create a category. You can use a subclass instead.

There is documentation about @property and Core-Data esp. in  
relation to retain/copy/assign. (The quintessence: Use retain!)



You may also consider 'copy' if appropriate
"There is documentation about @property and Core-Data esp. in relation  
to retain/copy/assign. (The quintessence: Use retain!)"






This is all trivially found in <http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdAccessorMethods.html 
>


mmalc

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Core Data - use of simple accessors vs. KVC

[Negm-Awad Amin]

Am Mi,27.08.2008 um 18:22 schrieb Oleg Krupnov:


A simple newbie question:

Suppose I have a Core Data model object MyObject with property myProp
defined in the model editor's schema.

Can I use the simple accessors like this:

[myObj myProp]
[myObj setMyProp]

or am I forced to use the rather clunky valueForKey/setVakyeForKey  
messages?

Managed objects automatically fake accessors for entities.

You can subclass NSManagedObject and add properties using @property  
and @dynamic, which means, that the accessors will be generated  
dynamically at run-time. (Without @dynamic you will get a compiler  
warning: incomplete implementation blablabla)


There is documentation about @property and Core-Data esp. in relation  
to retain/copy/assign. (The quintessence: Use retain!)


Cheers,
Amin




I thought that Core Data kind of auto-generates these standard
accessors for me and I don't have to write any manual code (if I don't
want anything special). However I've just got the compiler warning
that "MyObhect may not respond to '-myProp'"

Was I wrong or am I doing something wrong?
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]





___

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

Please do not post 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: Core Data - use of simple accessors vs. KVC

[Negm-Awad Amin]

Am Mi,27.08.2008 um 18:22 schrieb Oleg Krupnov:


A simple newbie question:

Suppose I have a Core Data model object MyObject with property myProp
defined in the model editor's schema.

Can I use the simple accessors like this:

[myObj myProp]
[myObj setMyProp]

or am I forced to use the rather clunky valueForKey/setVakyeForKey  
messages?

Managed objects automatically fake accessors for entities.

You can subclass NSManagedObject and add properties using @property  
and @dynamic, which means, that the accessors will be generated  
dynamically at run-time. (Without @dynamic you will get a compiler  
warning: incomplete implementation blablabla)


There is documentation about @property and Core-Data esp. in relation  
to retain/copy/assign. (The quintessence: Use retain!)


Cheers,
Amin




I thought that Core Data kind of auto-generates these standard
accessors for me and I don't have to write any manual code (if I don't
want anything special). However I've just got the compiler warning
that "MyObhect may not respond to '-myProp'"

Was I wrong or am I doing something wrong?
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Removing Applications from the Dock Programmatically

[Negm-Awad Amin]

Am Mi,27.08.2008 um 03:20 schrieb Graff:

I forgot to mention that you'll have to force the Dock to re-load  
its preferences after fooling around like this.


I really only know how to do this through the terminal or through  
AppleScript, although I'm sure there are other ways to do it
IIRC, you can send a HUP to the application to make it re-read its  
defaults. I don't know, whether Dock.app automatically updates the dock.



Here's an example of an AppleScript:

	NSString *quitSource = @"tell application \"/System/Library/ 
CoreServices/Dock.app\" to quit";
	NSAppleScript *quitScript = [[NSAppleScript alloc]  
initWithSource:quitSource];

NSDictionary *theError = [[NSDictionary alloc] init];

[quitScript executeAndReturnError:&theError];

- Ken
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: monitoring file system

[Negm-Awad Amin]

Am Mo,25.08.2008 um 16:21 schrieb MAnish Billore:


Hi,
I am developing an image browser in that user can watch photo from  
chosen

directory.
In this application I want to give functionality that whenever user  
add or

delete any photo from storage media application should know it.
Could any buddy give me idea about it .

You can use distributed notifications.

Cheers
Amin







Thanks
Bill Manish
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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 control the order of enumerating on a NSDictionary

[Negm-Awad Amin]

Am Mo,25.08.2008 um 09:40 schrieb Scott Anguish:



On 25-Aug-08, at 2:05 AM, Negm-Awad Amin wrote:


What an *** …

Amin Negm-Awad
[EMAIL PROTECTED]


while I can fully understand your reaction (and I'm guessing you  
meant to send this off list) language like this is inappropriate.
I'm sorry for that, but (maybe because of being an arabian german) I  
become upset, when somebody comes up with fascistic prejudices like  
asians should be nooodle shop owner. What's next? Black programmers  
should better play basketball? Jewi9sh programmers should better found  
a bank?


I'm sorry, but this should be stopped at the *very beginning*.

Cheers,
Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: *** -[NSSavePanel _blocksActionWhenModal:]: message sent to deallocated instance 0x15a05e50

[Negm-Awad Amin]

Am Mo,25.08.2008 um 08:45 schrieb Graham Cox:



On 25 Aug 2008, at 4:24 pm, Graham Cox wrote:



On 25 Aug 2008, at 4:17 pm, Negm-Awad Amin wrote:

Don't care about this. IF it is a singleton, retaining is no  
problem. IF it is NOT, retaining is the right way to handle it.



Sure, no problem for code I'm writing now.

Thing is, I never noticed this "tries to" before and always thought  
this was a singleton. So I have shipped code that doesn't retain  
the panel. It would be good to know if I'm just getting lucky *for  
now* or whether that code is reliable.



The sample code in Apple's docs does NOT retain the save panel. The  
example code for NSAlert similarly does not retain the alert - in  
fact it explicitly autoreleases it which is what I'd expect a  
convenience method to do if an individual instance were returned.


file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/Conceptual/AppFileMgmt/Tasks/UsingASavePanel.html

Since the example is presumed correct and in practice I've never run  
into a problem with this, it appears to be safe... in which case  
some clarification about what "tries to" means would still be good.



Graham

Post a doc dug!

Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: *** -[NSSavePanel _blocksActionWhenModal:]: message sent to deallocated instance 0x15a05e50

[Negm-Awad Amin]

Am Mo,25.08.2008 um 07:50 schrieb Graham Cox:



On 25 Aug 2008, at 11:09 am, Kyle Sluder wrote:


On Sun, Aug 24, 2008 at 6:03 PM, Cate Tony <[EMAIL PROTECTED]> wrote:
If I put a retain on the panel, the error stops, but isn't it now  
leaking?


No.  You took ownership of the NSSavePanel when you created it by
using a convenience constructor.  You must retain it, and release it
when you're done with it.



Except that the NSSavePanel docs state:

"An NSSavePanel object is a singleton: when you request a Save  
panel, NSSavePanel tries to reuse an existing Save panel rather than  
create a new one"


I don't usually retain it and have never seen this crash... but I  
also see it says TRIES to... so maybe it creates new instances  
sometimes depending on the parameters. It would be good to have a  
bit more certainty in the docs on this one - is it a singleton or  
not, and if not, under what circumstances exactly is that?
Don't care about this. IF it is a singleton, retaining is no problem.  
IF it is NOT, retaining is the right way to handle it.


However, as Cate said: You are the owner and you have to take care  
about it. What $somebodyelse is does is not your problem.


@TS
A -retain is no memory leak. A -retain without -release is a memory  
leak.


Cheers,
Amin




cheers, Graham
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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 control the order of enumerating on a NSDictionary

[Negm-Awad Amin]

What an asshole …

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Core data entity creation design

[Negm-Awad Amin]

Am So,24.08.2008 um 18:10 schrieb Quincey Morris:


On Aug 24, 2008, at 03:17, Steven Hamilton wrote:

I have a Core Data model which contains two entities. I have a  
tableview with the standard bindings arrangement and Add/Remove  
buttons handling one of the entities. What I need to achieve is  
that when the Add button is pressed both entity types are created,  
not just the one thats displayed in the table. I notice I can't use  
the button to send two Add: actions so I can't do one  
automatically, and the other in a custom class.


What's the best way to handle this situation? My first thought is  
ditching the bindings and implementing the table datasource  
methods. My next was perhaps subclassing the array controller.


Or send the button's action to First Responder, and implement the  
action in (say) the window controller or document object or  
application delegate. The implementation can create the new objects  
directly in the data model, or send suitable messages to the array  
controller that manages the table view.

Yup, that's the way to do it.

I just want to focus on two problems the TS will maybe confrantated with

- If you use the action -add: of the array controller, the object  
creation will be delayed. So an immediate retrievel of the new  
instance will fail. In this case it is a better solution to create the  
instance on your own and use -addObject: (NSArrayController)


- if the array controller only has a context binding, but no content*  
binding, he will not recognize a new instance for the entity. (if you  
have y content* binding, of course, you have to add the new instance  
to the to-many relationship, the array controller's content is bound  
to.) This is, because there is no possibility to observe the instances  
of an entity. (Do somebopdy know a hack?)


Cheers,
Amin






___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: ObjC 2.0, properties, KVC, special _ hacks etc.

[Negm-Awad Amin]

Am So,24.08.2008 um 16:09 schrieb Thomas Engelmeier:



Am 24.08.2008 um 05:59 schrieb John C. Randolph:



On Aug 21, 2008, at 7:59 PM, Thomas Engelmeier wrote:



Am 22.08.2008 um 00:59 schrieb Dave MacLachlan:

Also, are the _ in front of member variables for Apple only (so  
we don't stomp on each other with member var names) or are they  
using them for the readability reason mentioned above? There is  
documentation where they have claimed _ at the beginning of  
method names as being Apple only, but nothing about method vars,  
and the KVC compliance docs seem to imply that it is fine to do.


Officially it is Apple only, but everybody and his dog uses it -  
in consistency to quite some Apple-provided samples.


Please file bugs when you see a sample that does so.  A single  
leading underscore is an Apple internal coding convention, which  
should not be used for code samples.  I  did what I could to get  
those kinds of things fixed when I was there, but someone's got to  
file a bug for it to get noticed.


In this case I should probably first file feature requests
- for an additional naming convention proposal for ivars which for  
every other framework / platform I've seen (PowerPlant, MacApp, MFC,  
Java et al.) exist. My preference was a _trailing_ underscore which  
is also OK for C++ etc.


- automatic support for KVC for that ivar convention so not only  
Apple gets away with minimum accessor code to write (Jepp, I know  
@synthesize made it far easier)

You have KVC support for the underscore.
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html#/ 
/apple_ref/occ/instm/NSObject/setValue:forKey:

Or did you mean support for another symbol?


Regards,
Tom_E
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: ObjC 2.0, properties, KVC, special _ hacks etc.

[Negm-Awad Amin]

Am Fr,22.08.2008 um 04:59 schrieb Thomas Engelmeier:



Am 22.08.2008 um 00:59 schrieb Dave MacLachlan:

Also, are the _ in front of member variables for Apple only (so we  
don't stomp on each other with member var names) or are they using  
them for the readability reason mentioned above? There is  
documentation where they have claimed _ at the beginning of method  
names as being Apple only, but nothing about method vars, and the  
KVC compliance docs seem to imply that it is fine to do.


Officially it is Apple only, but everybody and his dog uses it - in  
consistency to quite some Apple-provided samples.
Also, in C++ the _ variable prefix is reserved for stdlib- 
implementation.
The reasoning why many people do not consider it as problematic if  
there is a collision with an Apple defined _ prefixed ivar is you  
will see an compiler error once there is a collision.


For methods OTOH, you don't get an warning but potential runtime  
crashes and undefined behavior.
Some people uses the leading underscore for a convention, that  
something is private:



@interface FrameworkClass:… {
   NSNumber* _myPrivateNumber;
}
---
@implementation …
- (void)_myPrivateMethod

Apple says, that underscored names are for apple use only. On the  
first sight it looks like, that this system helps avoiding collisions:  
Framework classes with, custom classs without underscore.


But that's not true. If you use standard accessor naming, the  
collision will be moved from ivars to accessors. Example:


- (void)setMyPrivateNumber:… // I'venever seen set_myPrivateNumber:

When you subclass a framework class and "accidentially" add your own  
ivar "myPrivateNumber", you usually will have a setter:

- (void)setMyPrivateNumber:…

The compiler wouldn't warn, because the ivars have different names.  
The "new" setter to the new ivar looks like overwriting to the  
compiler and he wouldn't warn again. So you have a collision without  
any warning of nobody. The "underscore solution" makes it worse, not  
better …


In former times this was the reason to me, to break with the apple  
convention and use the underscore, too. In this case the compiler will  
warn me because of the double ivar. (There is no ivar overwrtiting in  
Objective-C.) However I stopped doing so, because it is against the  
rule, unusual for most readers and the risk of a conflict is not that  
high, if you choose your ivars with some care about this problem. So  
do not use names like "count" and so on, but  
"countOfPersonsStored" (just an example) and so on.


But IMHO, it would be a good idea, that apples stops with the  
underscore rule, too.


Cheers,
Amin








___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Tabbed preference panels

[Negm-Awad Amin]

Am Fr,22.08.2008 um 18:29 schrieb Sumner Trammell:


Hi, I'm working on a preferences panel. I want to build a compound
panel like the kind seen in most mainstream apps today: a toolbar on
top with "tabbed" view switching. The panel changes its appearance
depending on which 32x32 toolbar icon you have selected.

I'm not sure where to start. Looking for examples, I've looked in
Safari's app bundle resources dir, and I see that Safari uses separate
nibs per preferences tab.  When I open one of these nibs, I see a
window object, and that window object has the preference tab's layout.
Pretty straightforward. Of course, Safari is not open source, so I
can't go any further and see how this design works.

Looking at the source for Transmission, I see they've taken a
different approach, which is to have one PrefsWindow.xib, and in that
xib, a number of View objects, one for each tab. Open the view object
representing a particular preference tab, and you see its layout. I
have not studied the Transmission source yet to see how they make it
all work.

So we have at least 2 accepted ways of doing the tabbed preference
panel thing. But I'd like a better understanding of the hows and why's
overall. Can anyone point me to some Cocoa programming guide docs, or
programming topics docs, on tabbed preference panels? (Are they even
called "tabbed preference panels?")


There are some different problems:

1) The selection bar
You can use a toolbar from IB and put some items there. If you want  
the items to be selected (pressed into the toolbar) you need a  
delegate, which tells the toolbar, which items are selectable. In most  
cases all items are selectable in such a pref-window. So you can do a  
hack by writing a method in the toolbar delegate:

- (NSArray*)toolbarSelectableItemIdentifiers:(NSToolbar*)toolbar;

{

   NSMutableArray* selectables = [NSMutableArray array];

   for( NSToolbarItem* item in [toolbar items] ) {

  [selectables addObject:[item itemIdentifier]];

   }

   return selectables;

}
(Otherwise you get a problem with item identifiers.)



2. Of course you have to connect the items to an action. The action  
should change the content of the window. There are two approaches:


2.1. TabView
Use a tabview with the different selections and simply switch the tab  
view.



2.2. View hierarchy
Get a seperate view for each selection (inside the same nib or one nib  
per view) and exchange the actual view with this view (- 
removeFromSuperview:, -addSubview:). You have to take care about:


- At the beginning you need one view as a placeholder. (You do not  
need it, but it is easier to me to handle it.) In -awakeFromNib you  
can replace that view with the view, which needs to be displayed  
first. So the placeholder view is a simple placeholder, say NSBox. To  
me this is easier to handle in IB (Autosizing and so on).


- Every time you replace the view, because the selection changed, you  
have to calculate the frame of the newly inserted view from the last  
displayed view.


- Memory mangement: It depends a little bit on the way you load/create/ 
refer to the different views. In any case remember: If you replace a  
view, this view isn't retained by its superview  any more and will  
disappear, if you or somebody else do no -retain on it. If it is in a  
nib, the nib will hold the view. If you put each view in an extra nib,  
the extra nib will hold it. (Unloading the nib will unload the view,  
reloading the nib will reload the view.)


This is the basic approach, I use it in this cases. I think there are  
different ways and there is no "Switching Window Documentation". But I  
think you're having now enough keywords for your own search.


Cheers,

Amin



Thanks,
-s
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Displaying time

[Negm-Awad Amin]

Am Fr,22.08.2008 um 16:15 schrieb Graham Cox:



On 23 Aug 2008, at 12:04 am, Negm-Awad Amin wrote:


This is what a analog PLL do, when it loads/unloads a ramp.



Analogue PLL design (Audio to GHz RF) were my bread-and-butter for  
many years, so do be careful not to teach your granny to suck eggs  
here ;-)

:-)

I developed digital PLLs in a former life.

If the system is busy, every timer-based solution will fail,  
because the timer does not guarante nothing of none.


So you're stuffed in any case then, since the only other way is to  
poll for a time change and there's no guarantee your main event loop  
will be run in a timely fashion either.
Yup, as I said: If your system is busy, an application-based solution  
is never very exact. But in the case, that the system is not busy (as  
I said, his TS sounds like this), you get a more precise timer  
(precise in relation to phase shifting, not related to frequency.  
frequency is no problem here), if you reduce the number of events and  
try to get close to the "tick tack".


I gueass, after running the software PLL 4, 5, 6 seconds (times), it  
will burn less cpu performance.


Timers are in the event loop, so it's as broad as it's long... Since  
the OP wants to display time to 1 second resolution *on screen*, you  
are clearly not talking about wanting this to be very precise.  
You'll be capped at 16mS anyway. A timer running at a few hertz is  
simple, if not perfect nor scalable to a real-time OS.
Yes, this is, what I wanted to say: If you really, really need an  
exact timer you should not use an application-bases solution on a OS  
like OS X.


We can think about hundreds, but not about thousands.




Graham


Cheers,
Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Displaying time

[Negm-Awad Amin]

Sorry for sending the responds solely to Graham:

Am Fr,22.08.2008 um 15:53 schrieb Graham Cox:



On 22 Aug 2008, at 11:39 pm, Negm-Awad Amin wrote:

I think, that a higher event-frequency is not neccessary. He should  
use an interval of close to one second (something like 0.99  
seconds). In his timer method he simply waits in a loop for the  
"tick tack" and displays the result. So he will not have a constant  
phase shift (except of the drawing interval).


Why wait in a loop? While it's doing that you're just burning up CPU  
time for no good reason,
If he needs 1/100 precision you would prefer to set-up a timer firing  
100 times in a second. Probably this will burn more performance.


stealing cycles from the rest of the app, and it's more complex.  
Just set the timer rate to the acceptable delay you want.
What is it? If the acceptable delay becomes smaller, incresing the  
event frequency makes your solution worse and worse.


It's a straightforward application of Nyquist's Sampling Theorem -  
sample at twice the fastest event you want to capture, which is 1  
second.
Nyquist's theorem can lead to a phase shift. This is the problem in  
the case of the TS.
Beside this Nyquist's theorem requests an ideal filter. He doesn't  
have any filter.


We have a phase-lock problem.

Thus, go at twice per second, plus a little bit to avoid getting  
locked into a constant delay (or faster still).

Why not going a little bit faster then 1 second?

The CPU will sleep between firings and a few Hz isn't a big deal, so  
this is far simpler and plays nicer.
If you implement a software PLL with some additional engagement, you  
simply measure the gap to the "full second" and recalculate the next  
interval.


This is what a analog PLL do, when it loads/unloads a ramp.



If the system becomes busy (his application doesn't sound like  
that), he maybe misses a second. That is acceptable if the system  
is busy.


Says you, maybe it isn't acceptable to the OP?
If the system is busy, every timer-based solution will fail, because  
the timer does not guarante nothing of none.



Graham




Cheers,
Amin Negm-Awad
___

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

Please do not post 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: Displaying time

[Negm-Awad Amin]

Am Fr,22.08.2008 um 16:00 schrieb Graham Cox:



On 22 Aug 2008, at 11:54 pm, Negm-Awad Amin wrote:


This is not ugly, but the starting point for a software PLL.



Well, there's no "loop" to phase lock here.
This was the reason for me, to write: "starting point". Look to my  
newer answer.


The PLL analogy might hold up if you used your timer to measure the  
interval between changes of the clock, then use that to change the  
timer rate (feedback). Then you could ensure that the timer callback  
always occurred within a certain interval of the clock changing  
(analogous to the phase delay in a PLL). But, it's pretty complex  
for such a simple task, and not necessary. If the clock were running  
much, much faster and you wanted to keep up with sub-millisecond  
changes then yes, you might have a point...





cheers, Graham



Cheers,
Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Displaying time

[Negm-Awad Amin]

Am Fr,22.08.2008 um 15:52 schrieb Thomas Davie:



On 22 Aug 2008, at 15:47, Negm-Awad Amin wrote:



Am Fr,22.08.2008 um 15:45 schrieb Thomas Davie:



Using a timer isn't too bad. Running at two updates per second  
should be acceptable since you're sampling at twice the highest  
"event" frequency. You might want to go a bit faster  and maybe  
at a slightly odd multiple of one second to make sure you don't  
end up with a constant half-second lag.
I think, that a higher event-frequency is not neccessary. He  
should use an interval of close to one second (something like  
0.99 seconds). In his timer method he simply waits in a loop for  
the "tick tack" and displays the result. So he will not have a  
constant phase shift (except of the drawing interval).


If the system becomes busy (his application doesn't sound like  
that), he maybe misses a second. That is acceptable if the system  
is busy.


He would miss a second every 100 seconds, whether the system was  
busy or not, as the timer fires, finds the time hadn't changed,  
and goes back to sleep for another 0.99 seconds.


Bob
»In his timer method he *simply waits in a loop for the "tick  
tack"* and displays the result. So he will not have a constant  
phase shift (except of the drawing interval).«


Oh, sorry, I assumed you weren't suggesting something ugly >.<

Bob

This is not ugly, but the starting point for a software PLL.

Cheers
Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Displaying time

[Negm-Awad Amin]

Am Fr,22.08.2008 um 15:45 schrieb Thomas Davie:



Using a timer isn't too bad. Running at two updates per second  
should be acceptable since you're sampling at twice the highest  
"event" frequency. You might want to go a bit faster  and maybe at  
a slightly odd multiple of one second to make sure you don't end  
up with a constant half-second lag.
I think, that a higher event-frequency is not neccessary. He should  
use an interval of close to one second (something like 0.99  
seconds). In his timer method he simply waits in a loop for the  
"tick tack" and displays the result. So he will not have a constant  
phase shift (except of the drawing interval).


If the system becomes busy (his application doesn't sound like  
that), he maybe misses a second. That is acceptable if the system  
is busy.


He would miss a second every 100 seconds, whether the system was  
busy or not, as the timer fires, finds the time hadn't changed, and  
goes back to sleep for another 0.99 seconds.


Bob
»In his timer method he *simply waits in a loop for the "tick tack"*  
and displays the result. So he will not have a constant phase shift  
(except of the drawing interval).«


Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Displaying time

[Negm-Awad Amin]

Am Fr,22.08.2008 um 15:28 schrieb Graham Cox:



On 22 Aug 2008, at 10:55 pm, Ron Fleckner wrote:

Sorry, my question was very badly put.  I've already apologised to  
two other answerers.  I should have said: Is there a better way -  
other than using an NSTimer - to update the clock?  That is, how  
does the system clock do it?


I think now that this is not strictly a Cocoa question.



Using a timer isn't too bad. Running at two updates per second  
should be acceptable since you're sampling at twice the highest  
"event" frequency. You might want to go a bit faster  and maybe at a  
slightly odd multiple of one second to make sure you don't end up  
with a constant half-second lag.
I think, that a higher event-frequency is not neccessary. He should  
use an interval of close to one second (something like 0.99 seconds).  
In his timer method he simply waits in a loop for the "tick tack" and  
displays the result. So he will not have a constant phase shift  
(except of the drawing interval).


If the system becomes busy (his application doesn't sound like that),  
he maybe misses a second. That is acceptable if the system is busy.


Cheers,
Amin




The timer should compare the previous second with the current second  
and only update the display if it's changed. That way your timer  
isn't wasting cycles redrawing the same thing every time, but only  
when it changes.


hth,

Graham
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 19:54 schrieb Michael Ash:

On Thu, Aug 21, 2008 at 10:40 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:


Am Do,21.08.2008 um 16:15 schrieb Michael Ash:

On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
>

wrote:


Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier:



Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin:


Sometimes you see in source code something like this:
if( booleanVarOrExpression == YES )
(I think, Rentzsch does it that way, IIRC) and Ithink, that  
this is

simply correct.


Oh, that is another discussion.


Yeah, but connected

It is antoher discussion in that way, that we have other types.  
(BOOL vs.

type of logical expression in C)
It is the same discussion in that way, that most programmers make  
some

assumptions about the value (and the casting).

(I bet, that 10 % believe, that the expression inside the if is  
typed

BOOL)


I'd be very surprised at this, given that BOOL is found only in
Objective-C, and if statements are found in C.


IIRC this depends on the concrete standard?


No, it does not. Objective-C does not have a standard, and no C
standard includes BOOL.

Objective-C has a reference. The reference includes BOOL.
BOOL
A Boolean value, either YES or NO.


Doing this is absolutly correct.
BOOL var = …; // Something evaluating to YES or NO
if( var == YES )


It's "correct" in that it is a legal language construct and it has
well-defined results. But it is incorrect as far as doing what most
people would want it to do. Consider this:

BOOL var = 2;


If somebody wants to do this, he does something wrong. 2 is no valid
assignment for a BOOL.


Of course it's valid:

typedef signed char BOOL;
This is an implementation detil. You should see the difference between  
reference and implementation. This is basical.


Beside this, you misunderstood the meaning of types. If somebody  
defines a type, he gives the new type a semantical meaning. Otherwise  
there is no need to define a new type.


When $somebody started to define BOOL, bool, Boolean, boolean … he  
wanted to say, that this a boolean value. Valid boolean values are YES  
ans NO. (or TRUE and FALSE or True and False or true and false - but  
boolean values).



The C standard guarantees that a signed char can hold at least values
in the range of -127 to 127. Depending on the implementation, it may
be abel to hold more. Thus any number in that range is a valid value
for a variable of type BOOL.

There is a conception about types. It is not rolling the dices.


if(var == YES)

That if statement will evaluate to false, even though the value of
"var" is conceptually true.


There is no "conpetionally true". BOOL has the valid values YES and  
NO, not

2, not CONCEPTIONALLYYES.


No, BOOL has the valid values -127 through 127, and possibly more. In
the C language, all non-zero values are "true".
No, it has the valid vlues YES and NO. This is defined by the language  
reference.






("True" in C meaning anything that is not
zero.)


This is not a BOOL. *You* said, that there is no bool in C.


No, I said that there is no BOOL in C.
Of course, when discussion about different languages, it is strange to  
refer to a series of lettrs. Shall I start to write BOOL, Bool bool,  
Boolean, boolean? There is an idea of booleans. This idea is not  
related to programming languages or a specific programming language.  
And it is not the idea of boolean numbers, that there is a pari 0, !0.  
It is the idea, that there is a pair YES and NO (or TRUE and FALSE or  
true and false … The idea does not depend on a specific language)


Thinking about the concept "type" you sould realize, that types are  
not made for a special series of characters to name it, but a  
semantical conception, meaning.



Of course it is also true that
there is no bool in C. And it's true. But C does have the concept of
logical truth and falsehood, it's just not expressed by means of a
boolean type, or boolean values.

Exactly. But in Objective-C it is expressed by a boolean type.

The logical truth in an if-statement bases on the difference betwenn  
== 0 and != 0,


The logical truth of a boolean type in Objective-C is based on YES and  
NO.

BOOL
A Boolean value, either YES or NO.

This is, what I said.

so
if( boolean )

changes the type. It only works, because NO is defined as 0 and YES is  
defined to something else then 0. As I said hours ago, this is  
disclused by the reference, so in Objective-C you can use this  
assumption without danger. But you *need* that, because logical  
expressions and BOOLs are not the same.



An if takes no
BOOL, but the type of an logical expression.


There is no such thing in the C language as "type of an logical
expression".
Typically logical expression is the term for the superset of  
relational expressions and expressions with logical operators. They  
have in co

Re: NSWindowController, owner, "primary window"...

[Negm-Awad Amin]

Am Do,21.08.2008 um 19:24 schrieb j o a r:



On Aug 21, 2008, at 10:12 AM, Negm-Awad Amin wrote:

Probably because the GoF prefers combination over (?) subclassing.  
Subclassing always discloses parts of the implementation of a  
class. ("white-boxing") So generally it is a good idea, to look for  
alternatives for subclassing, esp. delegates.



You are right in that Cocoa programmers often look to other design  
patterns before choosing to subclass one of the framework provided  
classes. That said, NSWindowController is one of the classes in  
Cocoa designed and intended to be subclassed, so that's not a  
consideration in this particular case.


j o a r



Yup, this was the reason for me to write:
"But, of course, sometimes a subclass is simply the right thing."

Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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, owner, "primary window"...

[Negm-Awad Amin]

Am Do,21.08.2008 um 06:10 schrieb Graham Cox:



On 21 Aug 2008, at 5:13 am, Gerd Knops wrote:

That'd work, but I'd have to subclass NSWindowController for that  
so I can add that property. Seemed to me that the above would not  
be an uncommon pattern and there ought to be a more elegant way  
that I might have missed.



Yep, that's the usual approach. What's the problem with subclassing?  
An unsubclassed NSWindowController isn't really all that useful. Why  
is subclassing so often referred to as "inelegant"?
Probably because the GoF prefers combination over (?) subclassing.  
Subclassing always discloses parts of the implementation of a class.  
("white-boxing") So generally it is a good idea, to look for  
alternatives for subclassing, esp. delegates.


But, of course, sometimes a subclass is simply the right thing.


That's what OOP is for.
Not all OOP languages use classes. I. e. look at SELF, a prototype- 
based language.


But Objective-C is a class-based language, yup.


Cheers,
Amin






Graham
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Design Question: Pro & Cons of KVC/KVO

[Negm-Awad Amin]

Am Do,21.08.2008 um 17:03 schrieb Oleg Krupnov:


Amin,

It is true that I am new to Cocoa, and although I find the
documentation really great and engaging, I have sort of difficulty
figuring out what technology is newer/more powerful/built on top of/
other technology.

In particular, would you explain me, in just two words, what are the
relations between and intended/typical applications of

(in the context of implementing the MVC pattern)

1) KVC/KVO
KVC is a very old (10.0?) technique to set properties of an entity. In  
comparison with setters you can choose (change) the property at run- 
time without changing your code:


Entity* instance = …; // imagine this is set
[instance setProperty:value]; // you know that

You cannot change the name of the property without recompiling. This  
can be done with KVC:


NSString* key;
Entity* instance = …; // imagine this is set
key= @"property";
[instance setValue:value forKey:key];
key= @"another";
[instance setValue:value forKey:key];

Since key is a NSString constructed at run-time, you can change the  
property at run-time.


KVO is newer, I think 10.3 IIRC and something totally different: The  
core: You get a mesage, if you registered for a property of an  
instance, that changes. It's quite close to your code. There are  
differences between automatic and manual KVO, but this is the essence.




2) Bindings
Bindings use KVO to get synchronized and KVC for reading/writing data.  
You can imagine a binding a command to an object, to observe the given  
key of the given instance. So, hmmm, usually an object starts a KVO,  
when it becomes bound. Conceptionally:


- bind:(NSString*)boundPropertyKey toObject:(id)observed forKeyPath: 
(NSString*)observedProperty

   // start KVO
   [observed addObserver:self forKeyPath:observedProperty];

There are more features through binding options I omitted to clarify.

KVO, KVC, and Bindings are placed "between" the MVC-layers. They  
typically synchronize a controller to the model and a view to the  
controller. (Inside a layer you typically do not need KVO, KVC,  
because the objects inside the same layer know each other. But of  
course you can use KVO, KVC)



3) Core Data
Core data is not neccessarily related to KV*. It is simply a  
technology for your model to ease the boring work of defining entites,  
writing accessors, supporting serialization….


But core data is KVC- and KVO-compliant, that means, that you can set/ 
read properties to/from an core data entity and you're able to observe  
the properties. Short: You *can* use KV technologies with core data.


Using core data or not and using KV* or not is orthogonal.



4) Anything else I may have overlooked?

If Core Data is really that cool, why don't one always use it instead
of KVC/KVO or maybe Bindings?

See above. You do not use core data or KV*, but core data and KV*


BTW I didn't say I thought Core Data was a database, I said it may be
intended rather for database apps.

Okay :-)

The usage is quite simple (if I'm allowed to simplify that)

Without core data
In your model you have classes for entities, let's say Person,  
Department, Company, Account … These classes are typically subclsses  
of NSObject. So you have to define the ivars, write accessors (okay,  
Objctive-C 2 …), maybe support undoing, support serialization with  
NSCoding …


With core data
In many cases you do not need any subclass, but simply use  
NSManagedObject. The definition of the model can be done in the  
modeller very easy. Undoing, Coding and so on will work.


Cheers

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Design Question: Pro & Cons of KVC/KVO

[Negm-Awad Amin]

Am Do,21.08.2008 um 16:41 schrieb Oleg Krupnov:


Thanks Amin for responding.

You are correct that there's no need to reinvent the wheel, and that's
exactly what I'd like to avoid, that's why I am now re-reading about
KVC/KVO and reconsidering it.

So, does everybody really always use KVC/KVO for implementing MVC, in
all projects?
There are some situation, where glue code is neccessary. Imagine a  
outline view that has a items lib and some groups, where you can place  
items from the lib and see them in the outline view by opening the  
isclosure. Or you have items from different entities there.


But even in this case it helps to use KVO on the parts to get  
synchronized.




Is this the recommended best practice?

BTW does anyone use Core Data?

You're joking?


I've watched the video tutorial and it
looks like too much magic. I would never guess how to make Core Data
work for a drawing application like the Sketch. Is Core Data rather
for database+forms apps?

1. Core data is not a database.
2. I think, that you are new to cocoa and a little bit afraid of the  
"magic" things. Hey, dive into it, read documentation, try a little  
bit coding and so on. There is no magic. It's just new land for you.






Thanks.


Cheers,
Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 16:15 schrieb Michael Ash:

On Thu, Aug 21, 2008 at 6:47 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:


Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier:



Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin:


Sometimes you see in source code something like this:
if( booleanVarOrExpression == YES )
(I think, Rentzsch does it that way, IIRC) and Ithink, that this is
simply correct.


Oh, that is another discussion.


Yeah, but connected

It is antoher discussion in that way, that we have other types.  
(BOOL vs.

type of logical expression in C)
It is the same discussion in that way, that most programmers make  
some

assumptions about the value (and the casting).

(I bet, that 10 % believe, that the expression inside the if is  
typed BOOL)


I'd be very surprised at this, given that BOOL is found only in
Objective-C, and if statements are found in C.

IIRC this depends on the concrete standard?


Doing this is absolutly correct.
BOOL var = …; // Something evaluating to YES or NO
if( var == YES )


It's "correct" in that it is a legal language construct and it has
well-defined results. But it is incorrect as far as doing what most
people would want it to do. Consider this:

BOOL var = 2;
If somebody wants to do this, he does something wrong. 2 is no valid  
assignment for a BOOL.




if(var == YES)

That if statement will evaluate to false, even though the value of
"var" is conceptually true.
There is no "conpetionally true". BOOL has the valid values YES and  
NO, not 2, not CONCEPTIONALLYYES.



("True" in C meaning anything that is not
zero.)
This is not a BOOL. *You* said, that there is no bool in C. An if  
takes no BOOL, but the type of an logical expression.



For this reason, I recommend never comparing with YES.
You should recommend, to assign never something else then YES or NO to  
a BOOL. *This* is wrong.



If you
are mentally unable to simply write "if(var)",

I'm not mentally unable to write that and I said, that I do that.
"However I use the simple condition (without == YES), too – for  
convenience."



then I recommend using
"if(var != NO)". I consider any code that compares against YES as you
wrote to have a bug.

No,
BOOL var = 2;
has a bug.


a simple

BOOL var = …; // Something evaluating to YES or NO
if( var )

is a very good hidden implicit cast from BOOL to logical expression.


There is no "hidden implicit cast". The if statement simply checks its
contents for truth or falseness,

No, it checks for == 0 or != 0.
BOOLs contain YES and NO.


which is to say that it checks it for
zero or non-zero.

Yup, and *not* for YES or NO

However I use the simple condition (without == YES), too – for  
convenience.

Your code then has a bug, in my opinion, and this is likely to
manifest in ways extremely annoying and difficult to diagnose.

No, your code has a bug:
BOOL var = 2;


BTW: This is an implicit cast, too:

BOOL var = a && b;

because the result of the right expression types to logical  
expression, not

to BOOL.

No, the right side of the expression is typed *int*.
There is no such
C type as "logical expression".
You cannot use it explicitly, but it is a construction of the  
language. The check of if is on == 0 or != 0. This is less then an int  
(or whatever you use) and something else than a BOOL.



I recommend you learn more about the C language before you continue
any further, because you have a lot of misconceptions and many of them
are going to cause you to write bad code.
I do not think so. But *I* would never assing 2 to a BOOL. And I'm  
sure doing so is a misconception.


Cheers,
Amin




Mike
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Design Question: Pro & Cons of KVC/KVO

[Negm-Awad Amin]

Am Do,21.08.2008 um 15:22 schrieb Oleg Krupnov:


I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,


This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:


Then how is it better than manual "glue code"?

1. You do not have to manage a list of observes. this is done by cocoa.
2. cocoas implementation is faster than everything you would program.
3. Less Coding for you
4. Compliance with cocoa concepts

Enough?

I think, you want to say, that if one changes a property, he sends  
a message
to a central MVC server, which distributes update messages.  
Correct? Why?



No. Actually, the alternative approach that I kept in mind was that
each model object maintains an array of observers (like delegates or
just objects with a declared protocol) to all of which the
corresponding message is sent each time a property of the model object
changes.

Sounds like KVO.



For example,

id observer;
MyModelObject* myModelObject;
// subscribe observer
[myModelObject addObserver: observer];
// set some prop
[myModelObject setSomeProp:someValue];

@interface MyModelObject
{
 NSMutableArray* m_observers;
 id m_someProp;
}
@end

@implementation MyModelObject
- (void)addObserver:(id) observer
{
   [m_observers addObject:observer];
}

- (void)setSomeProp:(id)newValue
{
   // save new value
   m_someProp = newValue;
   // notify observers
   id observer = nil;
   for (observer in m_observers)
   {
   [observer somePropChanged];
   }
}
@end

Looks like a bad implementation oif KVO.

What is the advantage of reprogramming KVO?

Beside this: Do you want to use core data? What about core data  
properties?



Is there something terribly wrong with this approach?
There is nothing wrong in programming a new string class. But why  
don't you use NSString?



The dependencies
are encapsulated. In addition, it seems that this approach gives me
more flexibility, say, if newValue is invalid, it can be rejected.

Key value valdidation


Or,
for instance, when the entire MyModelObject gets removed from its
parent model object - in this case there is no property actually
modified, instead, a mutator message is received by the model, but the
observers still need to be notified. Can KVC/KVO monitor the contents
of an array of model objects?

Of course. Look at the array controller.


And so on. Even though KVC/KVO may
handle these cases too, my intuition tells me there can be cases when
the flexibility of KVC/KVO may run short compared to the manual code.
My intuition is, that you don't want to get deeper with KVO und KVC  
and are searching for reasons to reject it.



Anyway, even if I assume that KVC/KVO is at least not worse than
manual code, I don't see any real benefit so far. Except that it
allows me to get the scripting support "for free" (but I'd rather like
the scripting to be separate thing and not get in the way of the model
objects).

Could someone please try to explain me the rationale behind KVC/KVO
once again? :) Thanks

In five minutes?

You want to hold an oberserver list for every property and every  
object. This is done by KVO. And ist is done for KVC with Core Data.  
And it works with bindings. And it is implemented very good through  
isa-swizzling. And And And …


There is nothing wrong in writing a Cocoa II.

But: Why?


Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 12:25 schrieb Thomas Engelmeier:



Am 21.08.2008 um 11:04 schrieb Negm-Awad Amin:


Sometimes you see in source code something like this:
if( booleanVarOrExpression == YES )
(I think, Rentzsch does it that way, IIRC) and Ithink, that this is  
simply correct.


Oh, that is another discussion.

Yeah, but connected

It is antoher discussion in that way, that we have other types. (BOOL  
vs. type of logical expression in C)
It is the same discussion in that way, that most programmers make some  
assumptions about the value (and the casting).


(I bet, that 10 % believe, that the expression inside the if is typed  
BOOL)


Doing this is absolutly correct.
BOOL var = …; // Something evaluating to YES or NO
if( var == YES )

a simple

BOOL var = …; // Something evaluating to YES or NO
if( var )

is a very good hidden implicit cast from BOOL to logical expression.

However I use the simple condition (without == YES), too – for  
convenience.


BTW: This is an implicit cast, too:

BOOL var = a && b;

because the result of the right expression types to logical  
expression, not to BOOL.




Bool != Boolean != bool, and sometimes that can introduce subtle  
errors if it's not only used to evaluate logical statements but by  
comparing values, especially to "YES", true and "TRUE".

Yes, and some people do calculations with it

andExpression = a * b, // of course in a more subtle context
orExpression  = a + b; // argh …

In an large C++ Cross-Platform project I spotted some subtle  
problems, IIRC from assignment of an bool to an Boolean for an API  
that evaluated the values by comparison to "TRUE" or some code  
assigned it to ints, giving different values for true (1 vs. 0xFF  
vs. 0x). I don't know any more, fixed it, was glad my own  
coding practices don't leave room for that problems, moved on ;-)...

:-)




Regards,
Tom_E


LG

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 10:47 schrieb Thomas Engelmeier:



Am 21.08.2008 um 05:03 schrieb Michael Ash:

There was a common perception that NULL is not really the same as  
nil. But

seems like in the end it really is (void*)0.


They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.


This is true conceptually but not as far as their actual definition.
NULL can be either 0 or (void *)0.


Let's be a little bit more precise, I'll try to paraphrase correctly  
from my memory:


a.)
(int) NULL  is NOT required or guaranteed  0x0 by the standard. This  
is why one should never use

  if( anPtr == (void *) 0 );
instead of
  if( anPtr == NULL );
On modern machines, it usually is.

b.) At least the C++ standard mandates for type conversion of an  
pointer to an boolean, that e.g. ( !anPtr )  is equivalent  to ( ! 
(anPtr == NULL )). I didn't read the C99 spec but I'm sure there is  
something similar specified.


This implementation detail does probably not matter on most  
platforms today as even microcontrollers have AFAIK linear address  
spaces.
When I was writing my first C app on a DOS machine, there were  
segmented addresses. That meant  it could happen that


((somePtr + offset) - offset) == somePtr

evaluated to false - (somePtr + offset) changed the segment,  
anotherPtr - offset did not. Big debug surprise for poor little  
68020 fanboy ;-)



First: Thanks a lot! I wanted to write somthing like this, but …

I always say, that theoretically it is dangerous to relay on NO = 0  
and nil = 0 (The assumption YES = 1 is simply wrong on some machines).  
In practice of course this always works.


But in the documentation of  Objective-C 2 from Apple, the definitions  
of NO and nil are diclosed. So I think, now it is for (and only for)  
Objective-C 2 "official" that NO and nil equals to 0.


Sometimes you see in source code something like this:
if( booleanVarOrExpression == YES )
(I think, Rentzsch does it that way, IIRC) and Ithink, that this is  
simply correct.


Cheers,
Amin


Regards,
Tom_E
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: IB displays a non-outlet (Bug or feature?)

[Negm-Awad Amin]

Am Do,21.08.2008 um 10:51 schrieb Jon Hess:


Hey Amin -

It's a compatibility feature that, I believe, dates from before the  
existence of IBOutlet. All id typed ivars without a leading  
underscore are available as outlets. There are similar rules for  
actions. I
For example, IB will treat any method with a single id typed  
argument named 'sender' as an action.


From my phone -
Jon Hess
Incredible! I'm developing with IB for more than five years and have  
never realized that. Probably the reason is, that I hate id-typed  
ivars and use them very rarely.


Thanks!
Amin




On Aug 21, 2008, at 12:01 AM, Negm-Awad Amin [EMAIL PROTECTED]> wrote:



Hi

before I report this, I want to check, whether I misunderstood  
something.


I've a window controller subclass with three outlets. Additional  
the class owns to ivars, one of them typed id. These ivars are not  
marked as outlet.


@interface GroupsWC : NSWindowController {
 IBOutlet NSArrayController* personsController;
 IBOutlet NSArrayController* groupsController;
 IBOutlet NSOutlineView* sidebarView;

 NSIndexSet* selectionIndexes;
 id selectedGroup;
}

In the IB3 I see the ivar typed id and can connect it. Is this the  
intended behaviour? (I accidentally connected this "outlet" to a  
view.)

http://www.cocoading.de/webspace/id_outlet.tiff

Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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/jhess%40apple.com

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: !foo vs foo == nil

[Negm-Awad Amin]

Am Do,21.08.2008 um 09:54 schrieb Jules Colding:



On 21/08/2008, at 09.21, Thomas Davie wrote:



On 21 Aug 2008, at 09:06, Jules Colding wrote:



On 21/08/2008, at 01.56, John C. Randolph wrote:



On Aug 20, 2008, at 4:15 PM, Torsten Curdt wrote:


There was a common perception that NULL is not really the same  
as nil. But seems like in the end it really is (void*)0.



They differ in type, not in value.

"NULL" is (void *) 0.
"nil" is (id) 0.
"Nil" is (Class) 0.

Personally, I prefer "if (!foo)" over "if (foo == nil)", because  
the latter has the hazard of a typo that compiles.  You can lose  
a fair bit of time staring at "if (foo = nil)" before you spot  
the mistake.


Which is why you should always write "if (nil == foo)".


Just to add my 2 cents to this discussion, I think there's  
something which hasn't been brought up (and I guess isn't often  
brought up by C programmers).


One of the two options doesn't make sense here.
Because of C's weak type system ! works on almost anything you  
throw at it.  However, it is a *boolean* operator.  Boolean  
negating a pointer is a hack that by happy coincidence works.  On  
the other hand, nil == foo is type safe, and makes semantic sense.


For that simple reason, I'd go for nil == foo every time.


Yes, and in general you should always do "if (CONSTANT == foo)" to  
catch the potential "if (CONSTANT = foo)" error.

You should always compile with -Wall to catch potential
if( value1 = value2 )
even if value1 is no constant.

Cheers,
Amin




Best regards,
 jules

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Design Question: Pro & Cons of KVC/KVO

[Negm-Awad Amin]

Am Do,21.08.2008 um 08:58 schrieb Oleg Krupnov:


I need to make the design decision regarding how the model and the
views will be kept in sync with each other. Namely:

- I can use key-value coding and observing (KVC and KVO)
- I can use bindings (not sure if it's really different from the KVC/ 
KVO)
At least it isn't, since a binding registers KVO and uses KVC for data  
retrievel.




- I can write the "glue code" myself

The concept of KVC/KVO is new to me. I have been looking at the Sketch
sample (a kind of application I am building myself too), which is
based on KVC/KVO, and I have found that the use of KVC/KVO makes the
program very unreadable and clumsy (like C++ COM code in Windows, you
know), because of the generic messages and hidden dependencies.
There is no "magic". IMHO, it makes the code more readable, beause the  
dependencies are not central, but encapsulated.



I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,

This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:

I think, you want to say, that if one changes a property, he sends a  
message to a central MVC server, which distributes update messages.  
Correct? Why?


if you want to have one method per synchronized property, use a  
NSString instance as context and simply do that:


// Typed in mail.app, simple example
- observeValueForKeyPath:(NSString*)keyPath ofObject: 
(id)observedObject change:(NSDictionary*)change context:(void*)context

{
  NSString* updateMethode = [NSString stringWithFormat.@"update%@",  
context]; // I didn't care about upper case to keep it simple for  
demonstration

  SEL selector = NSSelectorFromString( updateMethod );
  if( [self respondsToSelector:selector] ) {
 [self performSelector:selector];
  }
}

This will call a method with the name updateSize, if you set @"size"  
as the context at registration.


But: Why?

Cheers,

Amin



than try to fit into the over-generalized
model of KVC/KVO for the sake of skipping a few lines of code. And I
still have to subscribe objects to objects with KVC/KVO, don't I?

Does anyone actually use KVC/KVO? What is your experience? Any
pros/cons, opinions and best practices would be appreciated.

Thanks
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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]

IB displays a non-outlet (Bug or feature?)

[Negm-Awad Amin]

Hi

before I report this, I want to check, whether I misunderstood  
something.


I've a window controller subclass with three outlets. Additional the  
class owns to ivars, one of them typed id. These ivars are not marked  
as outlet.


@interface GroupsWC : NSWindowController {
   IBOutlet NSArrayController* personsController;
   IBOutlet NSArrayController* groupsController;
   IBOutlet NSOutlineView* sidebarView;

   NSIndexSet* selectionIndexes;
   id selectedGroup;
}

In the IB3 I see the ivar typed id and can connect it. Is this the  
intended behaviour? (I accidentally connected this "outlet" to a view.)

http://www.cocoading.de/webspace/id_outlet.tiff

Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: NSView confusion

[Negm-Awad Amin]

Am Mi,20.08.2008 um 16:25 schrieb Charlie Dickman:

Nobody has anything to offer other than a nebulous "try changing the  
declarations"?


I have tried everything I can think of and have tried the  
documentation I can find and I still can not figure out what is  
going on or what to do about it.


I have an app that contains multiple NSView's which are all visible  
at the same time. They are all sub-classes of NSView but not of any  
of the others. Each has its initialize, initWithRect and drawRect  
methods invoked as it should.


With the exception of the 1st one I defined, the workhorse view, no  
methods implemented in any of the others and declared in the  
respective .h files are visible to any of the other views at compile  
time. I import the appropriate .h files and invoke the method via  
[view method... and the compiler reports that no such method can be  
found. Yet if I invoke the method via [view performSelector:... at  
execution time it works just fine.
This is a possibility, but you should think about a protocol. However  
you should check this at run-time:


if( [aView respondsToSelector:@selector( method  )] ) {
…
}

If you are *really* expecting a specific class (you import a class!)  
not a specific ability (protocols are closer related to abilities),  
than you can check for a class, which clarifies your code:


if( [aView isKindOfClass:[MySpecialView class]] ) {
   MySpecialView* specialView = (MySpecialView*)aView;
   [specialView method];
}

But: Checking for a class is worse than checking for an ability. So  
you only should do this, if you really expect a class, not an ability.






I have no idea why the compile time recognition fails. Can someone  
explain to me what is going on and what I can do about it? Should  
there be a view hierarchy? If so, how structured?

View class hierarchy?

The compiler checks for known methods and put them into relation to  
the found classes. If you try to send a method to baseview, the  
compiler checks, whether this method exists (is implemented) for that  
class. So you cannot send a method message to baseview, if it is  
implemented in derivedview.


When you use -performSelector the compiler does exactly the same: He  
checks, whether the method – in this case performSelcotr – is  
implemented in the receiver's class. -perfromSelector: is implemented  
for every class. So there is no problem for the compiler.


But then he was to solve the @selector. Doing so, he needs *any* (i.g.  
in any class) prototype for this method. Since you mentioned this  
method in a class, you have to import this class. You can put this  
method to a protocol, to a totally different class, $somewhere – that  
does not matter. The compiler simply needs any knowledge about it.





Also, how does one synchronize events with the update of the various  
views? I can instruct each view what to draw and it draws it just  
fine (I use lockFocus, etc. when drawing is external to drawRect)

??

and the updated view is seen _eventually_ but I can not synchronize  
subsequent activity to happen after the appropriate display is seen.  
How can I accomplish this synchronization? And how can I force a  
view to update? Invoking [view display] has no effect on forcing the  
display toshow the latest update.
-display (NSView) immediatly draws the view – bad design. You should  
use something like -setNeedsDisplay:.


Beside this, if there is no update, you have a problem elsewhere.

Cheers,
Amin




Thanks for any help you can provide.

Charlie Dickman
[EMAIL PROTECTED]



___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Right place to unobserve notifications in a document

[Negm-Awad Amin]

Am Mi,20.08.2008 um 16:58 schrieb Joan Lluch (casa):



Joan Lluch

El 20/08/2008, a las 16:05, Negm-Awad Amin escribió:



Am Mi,20.08.2008 um 15:37 schrieb Joan Lluch (casa):




I've been reading this thread and I don't understand it in the  
case of GC. Why don't you still have to remove the observer from  
the notification center when you are not longer using it. Even if  
it is held as a weak reference, it will still remain registered  
for receiving notifications, so what when the observer is  
eventually collected, won't the notification center continue  
sending messages to the observer as long as it remains registered  
to receive them?, Please clarify.
First I want to say, that I'm happy to have a thread on this list,  
which is not related to a concrete problem, but discusses a design.  
I like that. :-)


Second: As you read, *I* would prefer to unregister the observer  
explicitly. You can do this in -finalize, but I do not have to  
repeat the design problems with finalization. *I* wanted a delegate  
method or a defined method to be overwritten in a subclass (I  
mentioned -close) to do it explicitly, *before* destroying the  
object. You ask the wrong person …


Third, to your question: Weak references in GC – they have nothing  
to do with "retainless" weak references using RC – are nullified  
automatically. If you use GC the weak collection should be modified  
appropiate by the collector itself. So this might be no problem. (I  
didn't test it, because it is not my idea.)


I understand what is your preferred approach, which it is also what  
I would do. I can add to it that I even thought that you *have to*  
*always* unregister the observers when you have done with them. This  
is obviously true in RC environment, but this is apparently not true  
in the case of GC. This is the part I don't get. I would appreciate  
if someone would clarify it for me.
Apple can clarify. Of course I do not know, which collection they use,  
but as a prototype:

http://developer.apple.com/documentation/Cocoa/Reference/NSMapTable_class/Reference/NSMapTable.html
It can hold weak references to its keys and/or values.
Keys and/or values held "weakly" in a manner that entries are removed  
when one of the objects is collected under garbage collection.


If you are not using garbage collection, you must explicitly remove  
entries as you would from a dictionary. In addition to being held  
weakly, keys or values may be copied on input or may use pointer  
identity for equality and hashing.




As I said: Weak collections are modified automatically, if a member is  
collected.
If the notification center handles the notification observers in a  
collection (probably they will do), the observer is automatically  
removed when collected.


Cheers,
Amin



Joan Lluch




Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Best Way to Handle Properties?

[Negm-Awad Amin]

Am Mi,20.08.2008 um 15:59 schrieb Dave:



On 20 Aug 2008, at 13:30, Ken Thomases wrote:


On Aug 20, 2008, at 6:05 AM, Dave wrote:


[…]



Firstly in the real code there is a "PersonDataValid" flag so I  
can tell if it's a good "Person" or not, secondly, unless I put a  
whole load of logic in the "PersonDetails" object and/or have it  
know about all the reader objects, it can't initialize a "salient"  
object. Or do you mean something else?


I mean the initializer method should take as arguments all of the  
pieces of information required for a Person (or PersonDetails)  
object to be valid.  Generally, if an object exists (is  
successfully allocated and initialized), it should be valid.  If it  
can't be made valid, then the initializer should fail (return  
nil).  If there are different possible combinations of information  
that could make a valid Person, then that suggests you want to have  
several different initializers, each taking different sets of  
arguments.  If you do, please make sure you understand the notion  
of designated initializer and how all of your other initializers  
should funnel through that one.


The problem with that there are a *LOT* of properties which is why  
the data was being passed in a structure and now being stored in an  
object. The initializer would have about 56 arguments, which in my  
book is horrible. This is a chicken and egg situation, I need to  
read around 56 pieces of information and store them in a "Common"  
format. I could use a C Structure but then I'd still have the  
problem of de-allocating/freeing/releasing all the NSStrings.


So, I allocate and initialize a "NULL" object and then populate it  
when I've read the data (from whatever source).

Maybe this is a misunderstanding:

Your initializer has to take as many arguments as you need to produce  
a valid instance. Sometimes you have properties, that have to be set  
at construction time to get  a consistent state. You should always  
have an initalizer, that takes these arguments.


You can have a complete initializer, that takes an argument for each  
(public) property. This is polite, because in many cases the user of  
your class wants to set a number of properties immediatly after  
construction. But there is no must to do so.


There is definetly no rule, that you have to have more than an -init,  
if you are able to construct a valid object. If there would be such a  
rule, array controllers wouldn't work …



[…]


Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Right place to unobserve notifications in a document

[Negm-Awad Amin]

Am Mi,20.08.2008 um 15:37 schrieb Joan Lluch (casa):





Am Mo,18.08.2008 um 20:14 schrieb Andy Lee:




Since the observed object (maybe notification center) will still  
hold a reference to the observing object, there is a problem. The  
*observer* will not be freed, if the observed is still living.  
Obviously you have a problem using GC,  for example if you have an  
observing window and an observed model instance. The model probably  
lives longer than the window. (Think of info windows …)


This seems to be the reason for the weak reference using GC.


I've been reading this thread and I don't understand it in the case  
of GC. Why don't you still have to remove the observer from the  
notification center when you are not longer using it. Even if it is  
held as a weak reference, it will still remain registered for  
receiving notifications, so what when the observer is eventually  
collected, won't the notification center continue sending messages  
to the observer as long as it remains registered to receive them?,  
Please clarify.
First I want to say, that I'm happy to have a thread on this list,  
which is not related to a concrete problem, but discusses a design. I  
like that. :-)


Second: As you read, *I* would prefer to unregister the observer  
explicitly. You can do this in -finalize, but I do not have to repeat  
the design problems with finalization. *I* wanted a delegate method or  
a defined method to be overwritten in a subclass (I mentioned -close)  
to do it explicitly, *before* destroying the object. You ask the wrong  
person …


Third, to your question: Weak references in GC – they have nothing to  
do with "retainless" weak references using RC – are nullified  
automatically. If you use GC the weak collection should be modified  
appropiate by the collector itself. So this might be no problem. (I  
didn't test it, because it is not my idea.)


Anyway, as said: *I do not* want to handle the unregister this way. I  
want to handle it explicitly, but found no -willClose method or  
something like this. (You cannot relay on -close, as I said in the OP.)


Cheers,
Amin




Joan Lluch




Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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 reference a NSDocument from a NSView?

[Negm-Awad Amin]

Am Di,19.08.2008 um 20:46 schrieb Scott Anguish:



On 19-Aug-08, at 12:52 PM, Jeff Mesnil wrote:

On Tue, Aug 19, 2008 at 1:37 PM, Jeff Mesnil <[EMAIL PROTECTED]>  
wrote:

The application is behaving as expected, the model (the ovals) are
kept in MyDocument and the DrawView just draws them.
But I was wondering if that was the "right" Cocoa way to do so, to  
use

an IBOutlet to connect a NSView to a NSDocument.
Is there another way to have a reference to the document from one  
view

of the application?


Answering my own question, my use case is similar to the Sketch
example bundled with XCode.

In Sketch, they use KVC to observe an NSArrayController.
I did the same by calling bind:toObject:withKeyPath:options:  in
MyDocument windowControllerDidLoadNib: method and it works.

To sum up, I've seen 3 different ways to write this code:
- use an IBOutlet to reference the NSDocument from a NSView
- use [[[self window] windowController] document] from a NSView
(thanks Chaitanya!)
- forget about the NSDocument and use KVC to directly observe the  
ovals


Using the KVC seems the most natural way to do that in Cocoa.



I think all three are actually very valid.
Yes, but the first and second approach is IMHO the worst, because the  
view expects a typing (some accessores) to get the data.


There is a 4th possibility: Implementing a data source.
Cheers,
Amin




although everywhere you've said KVC above needs to e replaced with  
KVO. :-)




___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: best way to determine if portion of window is visible?

[Negm-Awad Amin]

Am Di,19.08.2008 um 18:13 schrieb Jason Bobier:


Hi Amin,

Unless I am misunderstanding, this would tell me if it was onscreen,  
but not if the window was exposed (not hidden by other windows).

Ah, probably I misunderstood you.

Cheers,
Amin




Jason

On Aug 15, 2008, at 5:03 PM, [EMAIL PROTECTED] wrote:


Hey folks,

I'd like to fade my window out if any portion of it is visible to  
the
user, otherwise I simply want to close it for speed. Is there an  
easy

way to determine if some portion of the window is visible?
I do not know, whether this is a "dirty" hack (are there clean  
hacks?), but you can read the frames of the screens
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSScreen_Class/Reference/Reference.html#/ 
/apple_ref/occ/clm/NSScreen/screens


http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSScreen_Class/Reference/Reference.html#/ 
/apple_ref/occ/instm/NSScreen/frame


and clip it with you window frame.

http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#/ 
/apple_ref/occ/instm/NSWindow/frame


That probably works.

Cheers,

Amin



Thanks!

Jason
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Hex representation of NSString

[Negm-Awad Amin]

Am Mo,18.08.2008 um 19:15 schrieb Charles Srstka:


On Aug 18, 2008, at 6:18 AM, Robert Černý wrote:

Actually,I'm trying to debug some weird problems with clipboard. My  
problem
is that data copied into clipboard from legacy java application  
doesn't

match data pasted into Cocoa application. I've got data with accented
characters which gets converted through MacOS Roman encoding even  
the visual

representation in java is correct.


It sounds like you don't really want to use NSString at all. Have  
you tried just using -[NSPasteboard dataForType:] instead of - 
[NSPasteboard stringForType:] to get the raw pasteboard data as it's  
coming from the Java application?
Yes, I think, that the other answer tries to solve the problem "too  
late". He should look insinde the pasteboard before a string instance  
is even in mind.





Charles

Cheers,
Amin

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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 respondsToSelector

[Negm-Awad Amin]

Am Mo,18.08.2008 um 20:17 schrieb Carmen Cerino Jr.:

Does the id type have enough information for the respondsToSelector  
method to work. I have a class with an ivar of type id, and when I  
invoke the respondsToSelector method it fails when it should  
succeed. I am assuming it should work fine, because if I skip  
checking with the respondsToSelector method and just make the call,  
it executes the method. Can someone please tell me what I am doing  
wrong?
Since the whole dispatch is done by and only by the runtime  
(exception: messages to super) the rte holds the information. (The  
compiler only throws warnings, because he can proceed with his work.  
This is, because he does nothing else than checking!)


As others said:
a) We need a piece of code
b) Typo?

Cheers,
Amin




Thanks,
Carmen
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Right place to unobserve notifications in a document

[Negm-Awad Amin]

Am Mo,18.08.2008 um 20:14 schrieb Andy Lee:


On Aug 18, 2008, at 12:49 PM, Negm-Awad Amin wrote:

Am Mo,18.08.2008 um 18:18 schrieb Andy Lee:
-- but in this case I think -dealloc is not only okay, but  
sometimes the only correct place to unregister a notification.   
Suppose an invariant of your design is that an object should  
receive notifications as long as, and only as long as, the object  
exists.  If you unregister too soon, you may have an "alive"  
object that fails to get a notification.
This is little bit a circular argumentation: I need it the whole  
lifetime, so i manage it the whole lifetime. Why do you need it  
until the instance becomes deconstructed?


It's only circular in that I specifically selected a class of  
situations where it makes the most sense. :)



I think this is the right pattern:
1. Construct and init the object
2. Let them work (register observations, handling threads,  
$whatever … )

3. Stop them
4. Deconstruct them

So there are 4 steps, not 2.


This pattern is fine and necessary in many cases, but there are also  
plenty of cases where it is not viable. For example, it may not be  
clear when the object can "stop" listening for notifications.  It  
may literally be when all other objects are done with it, i.e., when  
its retain count goes to zero, and in a dynamic system you may have  
no way of knowing which will be the last object to release your  
object.


IMO imposing a start-stop paradigm on every class that wants to  
register interest in notifications -- and engineering every class so  
that your object can't possibly be released until it is "stopped" --  
is just as much a design error as putting functional work in - 
dealloc.  I would encourage you to reconsider.
As I said, in the past I used this pattern very often. And indeed the  
reason was, that if somebody A is retaining somebody B, A uses B. So I  
can mix up functional work and memory management. This seems to be  
convient.


If you put it together, you have no possibility of stopping somebody  
without releasing it. And since you can not be sure, that somebody  
else holds it, you have to reinstantiate B for a new start. I think in  
practice a "2-step-pattern" makes sharing of the functionality harder!


In the cases where you do have a start-stop paradigm, you should put  
a "stop" in -dealloc anyway, as Michael argued.
You should throw an exception or at least log something, as oberserved  
objects actually do ("dealloc while observation in place" or something  
like this).



I think it's okay to unregister in -dealloc because conceptually  
it's related to releasing your ivars.  You're explicitly  
dissolving a relationship between the object being dealloced and  
some other object -- a relationship you have to manually manage in  
the absence of garbage collection.
In this case it seems to be ok. Maybe this is the reason for the  
weak reference.
The weak reference is to avoid retain cycles (the same reason why  
delegates are not retained).
We talked about GC. The need for a weak reference using RC is quite  
clear.


With GC turned on, retain cycles are not a problem so you don't have  
to worry about weak references to self, just as you don't have to  
bother releasing strong references to ivars.
Since the observed object (maybe notification center) will still hold  
a reference to the observing object, there is a problem. The  
*observer* will not be freed, if the observed is still living.  
Obviously you have a problem using GC,  for example if you have an  
observing window and an observed model instance. The model probably  
lives longer than the window. (Think of info windows …)


This seems to be the reason for the weak reference using GC.

In the absence of GC, you have to break connections manually, and  
that's all this is.  In fact, you should also break delegate  
connections to self in the same place, for the same reason.  (Hm,  
I'm not sure whether I'm doing this in my own code -- I'd better  
check.)


You mentioned KVO in another reply.  I haven't used KVO, so I'd be  
interested if anyone has a response to your counterexample.


Still waiting … ;--)

Cheers,
Amin




--Andy




Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Right place to unobserve notifications in a document

[Negm-Awad Amin]

Am Mo,18.08.2008 um 18:57 schrieb Michael Ash:

On Mon, Aug 18, 2008 at 11:51 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:
But anyway I do not think, that doing something else then memory  
management
in -dealloc is good design. Normally I unregister observation in  
delegate

methods like -applicationWillTerminate:.


I think you may be a little too strict about this.
As I said, it is for teching. So Strictness (correct noun?) is a good  
approach.



First, this really is memory management, it's just not so obvious.
You're removing another object's weak reference to your own object.
The logical place to do this is right before your own object is
deallocated.

Second, it's fine, even good, to clean up arbitrary resources in
-dealloc. There are two things to watch out for, though:

1) You shouldn't clean up *scarce* resources *only* in dealloc. For
example, file descriptors. It's fine to close fds in dealloc. In fact,
you really should do this. But you should *also* provide an explicit
"close" method and use it. The close in dealloc will just function as
a failsafe. This is because your object's lifetime may be much longer
than you want it to be due to things like autorelease pools, so you
want scarce resources to be under explicit control. This is much more
important in a GC environment than in the manual environment, however.
Yes, I saw, that observations of notifications can be understood as a  
kind of memory management. But you can generalize this argumentation –  
and then it becomes definetly wrong.


In this sense KVO is "a kind of memory management", too. Today I would  
never deregister a KVO-observer in -dealloc as I did it some years ago.



2) You shouldn't clean up *external* resources *only* in dealloc. For
example, if you have an object that keeps a temporary file around,
then only deleting it in dealloc is a bad idea. This is because, as
you're probably aware, there's no guarantee that your objects get
deallocated before your application terminates. But again, it's fine
to do this kind of cleanup in dealloc as a failsafe, just don't have
it be the *only* place it happens.

What you don't want to do is make dealloc part of an RAII (Resources
Acquisition is Initialization) pattern,
Yes, that's it. In the past I handled – internal! – ressources very  
often this way. I stopped doing so. GC was just the initial thinking:  
"Hey, you are doing something in a method for memory managemt, which  
has no relation to memory management."


As I said, I never have had problems with this approach in woking  
code. But I do not like it anymore for design reasons.



or do long running
computations there,

No, there is no performance issue in my mind. It's simply design.


or things like that. But cleaning up external
references to your object before you disappear is a good thing to do
there.

I'll continue thinking about this …

Cheers,
Amin




Mike
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Right place to unobserve notifications in a document

[Negm-Awad Amin]

Am Mo,18.08.2008 um 18:18 schrieb Andy Lee:


On Aug 18, 2008, at 11:51 AM, Negm-Awad Amin wrote:
But anyway I do not think, that doing something else then memory  
management in -dealloc is good design. Normally I unregister  
observation in delegate methods like -applicationWillTerminate:.


I understand your concern -- you meant "functional overhead" in the  
sense of a design taboo, not a performance cost

Oh, yes, sorry for the ambigious statement.

I'm a fan of Knuths phrase, so I talk about performance very rarely.

-- but in this case I think -dealloc is not only okay, but sometimes  
the only correct place to unregister a notification.  Suppose an  
invariant of your design is that an object should receive  
notifications as long as, and only as long as, the object exists.   
If you unregister too soon, you may have an "alive" object that  
fails to get a notification.
This is little bit a circular argumentation: I need it the whole  
lifetime, so i manage it the whole lifetime. Why do you need it until  
the instance becomes deconstructed?


I think this is the right pattern:
1. Construct and init the object
2. Let them work (register observations, handling threads, $whatever … )
3. Stop them
4. Deconstruct them

So there are 4 steps, not 2.

In former times I often finished functional work in -dealloc. This  
ofen works, no problem. But it is a poor design. Sure, you shouldn't  
develop for garbage collection and reference counting in the same  
code. But thinking about this can sometimes focus a problem with  
design. No design should depend on the memory management model accept  
of the memory managing itself, should it?


 If unregister too late, the notification center will send the  
notification to a dangling pointer and your app will crash.
Of course you have to stop functional work before decnstrcuting the  
instance.


I think it's okay to unregister in -dealloc because conceptually  
it's related to releasing your ivars.  You're explicitly dissolving  
a relationship between the object being dealloced and some other  
object -- a relationship you have to manually manage in the absence  
of garbage collection.
In this case it seems to be ok. Maybe this is the reason for the weak  
reference.


Thanks for your thoughts.

Cheers,
Amin




--Andy




Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Right place to unobserve notifications in a document

[Negm-Awad Amin]

Am Mo,18.08.2008 um 17:37 schrieb Michael Ash:

On Mon, Aug 18, 2008 at 5:59 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:

Hi,

for some teaching reasons I have a document class, which observes a
notification. Of course I have to unobserve this notification, when  
the
document is closed. Doing this in -dealloc is no good design  
(fuunctional

overhead in -dealloc, garbage collection …).


There's nothing wrong with doing it in -dealloc, and in fact this is
the standard way to do it. Overhead is not a problem. That code has to
run *sometime*, and -dealloc is not in anybody's critical path the way
-finalize is. Garbage collection is not a problem, because
notification observers are held with weak references in a GC

Argh, yes, I forgot this.


environment, so you don't need to manually unobserve at all. Also note
that it's pretty rare and undesirable to write dual-mode code. If
you're running under GC, just forget about unobserving. If you're not,
then forget about problems with GC.

Thanks a lot!

With the fact above, -dealloc seems to be a nice place, because it is  
*not* executed running garbage collection.



But anyway I do not think, that doing something else then memory  
management in -dealloc is good design. Normally I unregister  
observation in delegate methods like -applicationWillTerminate:.






Mike
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Changing NSTextFieldCells' editing appearance?

[Negm-Awad Amin]

Am Mo,18.08.2008 um 17:00 schrieb Tim Andersson:



18 aug 2008 kl. 10.15 skrev Negm-Awad Amin:



No, I speak english badly enough to misunderstand this. :-)


I'm sorry if I made it sound like a "insult" - That wasn't my  
intention.

No, my fault.



The behaviour of an NSTextField depends on the behaviour of an  
NSTextFieldCell. Most of the behaviour of an NSTextField is done by  
an NSTextFieldCell. So it is a little bit strange to ask, whether a  
cell should behave as its control.


Probably you can clearify this:
- Do you use an NSTextFieldCell without its NSTextField?
- Which specific behaviour the control did fail using the cell?

Cheers,

Amin



I'm using the NSTextFieldCell in a NSTableView.

When using a NSTextField without a border and focus ring, the only  
thing that happens when you start editing the field is that the text  
is highlighted.
When I  edit my NSTextFieldCell (Without border and focus ring) in  
my NSTableView, the background goes black and a white border is  
shown around it, as the following picture shows: http://img143.imageshack.us/img143/5513/bild2su2.png


I hope that clarifies what I'm trying to do. :)

Cheers,

Tim Andersson


Yes, it did. Probably the table view will set some attributes from its  
own state instead of respecting your cell. For example a table view  
has a background and the cell has.


I never had that problem, but to solve this, you maybe should  
overwrite -editColumn:row:withEvent:select: (NSTableView) and debug,  
what is going on. Maybe you can set some attributes before the editing  
starts.


Cheers,

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Hex representation of NSString

[Negm-Awad Amin]

Am Mo,18.08.2008 um 13:18 schrieb Robert Černý:


Actually,
I'm trying to debug some weird problems with clipboard. My problem  
is that data copied into clipboard from legacy java application  
doesn't match data pasted into Cocoa application. I've got data with  
accented characters which gets converted through MacOS Roman  
encoding even the visual representation in java is correct.

Ah, for debugging purpose only.

I think, that it is difficult to get the NSString backend, since it is  
a abstract baseclass to a class cluster.


But there is a clipboard viewer app in the examples, which lets you  
inspect the raw data. Maybe this helps to find the problem.


Cheers,
Amin



Robert

2008/8/18 Negm-Awad Amin <[EMAIL PROTECTED]>

Am Mo,18.08.2008 um 12:40 schrieb Robert Černý:



I don't like it because the string will be converted. I'm  
interested in exact values


Oh, may I ask why? The string class encapsulates its representation.

Anyway, if you want to look "inside" the instance, you probably have  
to subclass it or doing some undocumentated stuff.


Cheers,

Amin



and even allowLossyConversion:NO doesn't guarantee it. Or am I wrong?

Robert

2008/8/18 Negm-Awad Amin <[EMAIL PROTECTED]>

Am Mo,18.08.2008 um 12:21 schrieb Robert Černý:


Hi,I'm trying to find a way how to get hex representation of  
NSString. I
know I can convert NSString to NSData but I would like to rather  
not to do

it. Or am I missing  anything obvious?
Maybe: Do it this way.

Why don't you like it?

Cheers,
Amin

BTW: This isn't the hex representation, but the binary, serialized  
representation. Hex, octal and so on are terms used in relation to  
display something.




Thanks
Robert
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]

Amin Negm-Awad
[EMAIL PROTECTED]








Amin Negm-Awad
[EMAIL PROTECTED]







Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Hex representation of NSString

[Negm-Awad Amin]

Am Mo,18.08.2008 um 12:40 schrieb Robert Černý:



I don't like it because the string will be converted. I'm interested  
in exact values

Oh, may I ask why? The string class encapsulates its representation.

Anyway, if you want to look "inside" the instance, you probably have  
to subclass it or doing some undocumentated stuff.


Cheers,

Amin



and even allowLossyConversion:NO doesn't guarantee it. Or am I wrong?

Robert

2008/8/18 Negm-Awad Amin <[EMAIL PROTECTED]>

Am Mo,18.08.2008 um 12:21 schrieb Robert Černý:


Hi,I'm trying to find a way how to get hex representation of  
NSString. I
know I can convert NSString to NSData but I would like to rather not  
to do

it. Or am I missing  anything obvious?
Maybe: Do it this way.

Why don't you like it?

Cheers,
Amin

BTW: This isn't the hex representation, but the binary, serialized  
representation. Hex, octal and so on are terms used in relation to  
display something.




Thanks
Robert
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]

Amin Negm-Awad
[EMAIL PROTECTED]







Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Hex representation of NSString

[Negm-Awad Amin]

Am Mo,18.08.2008 um 12:21 schrieb Robert Černý:

Hi,I'm trying to find a way how to get hex representation of  
NSString. I
know I can convert NSString to NSData but I would like to rather not  
to do

it. Or am I missing  anything obvious?

Maybe: Do it this way.

Why don't you like it?

Cheers,
Amin

BTW: This isn't the hex representation, but the binary, serialized  
representation. Hex, octal and so on are terms used in relation to  
display something.





Thanks
Robert
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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]

Right place to unobserve notifications in a document

[Negm-Awad Amin]

Hi,

for some teaching reasons I have a document class, which observes a  
notification. Of course I have to unobserve this notification, when  
the document is closed. Doing this in -dealloc is no good design  
(fuunctional overhead in -dealloc, garbage collection …).


But I read in the documentation, that -close (myDocument) wouldn't be  
called in some situations. Is there a save place to unobserve  
notifications? (Or providing other clean-up.) I couldn't find a hint  
in the documentation!?


Cheers

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: NSUInteger hash

[Negm-Awad Amin]

Hi Steve,

Am So,17.08.2008 um 18:43 schrieb Steve Wart:


Hi Aaron,

That's always a good question to ask.

I'm porting a Smalltalk/OpenGL maze application I wrote a few years  
ago to

Cocoa.

The maze is initialized by creating a 2D matrix of Room objects  
which are
separated by Wall objects. Every room has an ordered collection of  
walls
which I've put into an NSMutableArray. Every wall has a start point  
and an
end point and exists in exactly one room. So the common wall  
separating a

pair of rooms is actually represented by two walls.
I think, that this is the root of the problem. Two rooms are seperated  
by one wall. This is the (virtual) reality. Modelling this in a  
different way (rooms are seperated by two "surfaces") will cause  
problems in many ways.


What about remodelling this struture? If you need "double attributes"  
for a wall like color, hasWallPaper …, which are different on each  
surface, yo should model it this way: One wall entity with two surface  
entities.


Actually you divide one thing (wall) into two things (surfaces) and  
get problems, to glue it together again.


Cheers,
Amin




I go through the rooms in random order, pick a wall at random, and  
knock it

down (also being careful to knock down the corresponding wall in any
adjacent rooms). By knocking down a wall, two rooms become merged  
into one.

When I have only one room left, it means that the maze is complete.

I depend on isEqualTo: to compare the walls. They are both created  
from the

same set of points but they are different objects, so I can't use an
identity comparison. The Smalltalk code is reasonably clean but it's
bloating unpleasantly in Objective C so I will probably need to take a
higher-level look at what I'm trying to accomplish. The original maze
algorithm was cribbed from C so it shouldn't be too hard to make it  
work :-)


Steve

On Sun, Aug 17, 2008 at 12:10 AM, Aaron Lees <[EMAIL PROTECTED]>  
wrote:


What are you trying to do? It's usually a bad idea to compare  
floating
point values for equality since you will run into subtle bugs to do  
with
rounding. If you want to use your objects as dictionary keys it's  
often
better to use a pointer equality rule instead of semantic equality.  
You can

do this with NSMapTable without any overrides in your class.

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Changing NSTextFieldCells' editing appearance?

[Negm-Awad Amin]

Am Fr,15.08.2008 um 19:41 schrieb [EMAIL PROTECTED]:



-setBackgroundColor: didn't work?



Nope, it didn't. But even if it would've, the background would have  
been

visible at all times. I'm sorry if I didn't write clearly enough,

No, I speak english badly enough to misunderstand this. :-)


but it's
only when the cell is being edited that the background becomes black
(Instead of white like it usually does). When I'm not editing the  
cell,

the cell doesn't have a background.


Did you read the documentation about the relationship between cells
and views?



Is that in the Control and Cell programming topics for Cocoa? All I  
could
find is that NSTextField uses NSTextFieldCell, but I'm not really  
sure if

that's what you meant?
The behaviour of an NSTextField depends on the behaviour of an  
NSTextFieldCell. Most of the behaviour of an NSTextField is done by an  
NSTextFieldCell. So it is a little bit strange to ask, whether a cell  
should behave as its control.


Probably you can clearify this:
- Do you use an NSTextFieldCell without its NSTextField?
- Which specific behaviour the control did fail using the cell?

Cheers,

Amin




Thanks for you help,
Tim Andersson



Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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

[Negm-Awad Amin]

Hi,

do you want to display all three items (triangle, icon, text) in one  
column? Than you need an ImageAndTextCell. Browse your examples folder  
to get it.


Amin

Am Mo,18.08.2008 um 08:38 schrieb [EMAIL PROTECTED]:


Hi all
I'm new to cocoa. I want to display the outline view item by a  
disclosure
triangle, then one checkbox, then text field to display the name of  
the

nodes.
I didn't find any documentation regarding this. How can I do this ?

Thanks in advance.

___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Binding NSButton state to an NSMutableArray inside an NSMutableArray

[Negm-Awad Amin]

Hi

you did a part of the work. Using a second array controller is  
correct, because you have a second array.


What you need is a UI, that depends on the number and content of the  
items contained in the second array. There are two views, that provide  
this: NSTableView and – I think this is the correct one for your UI –  
NSMatrix.


So try using an instance of NSMatrix.

Cheers
Amin
Am Fr,15.08.2008 um 20:10 schrieb TouchCab Developer:


Hi list.

I'm new to the list and fairly new to cocoa, although many years of  
programming assembler, C and C++ helps a lot. I'm getting the hang  
of Objective-C and enjoying it very much.


In my App Delegate file I keep an NSMutableArray of "base" objects  
which is my application's data core.
I need an arbitrary number of Windows/Panels to access this array,  
and show/manipulate the contents of one of the base objects,  
selectable by a designated key in my object using an NSTableView in  
the window. This works nicely for most objects inside the base  
objects, binding an NSArrayController to the array.


Each base object, however, holds an NSMutableArray of NSNumbers. I  
want the boolean value of these NSNumbers to represent the state of  
an equal number of buttons in the window, so that if one of the  
NSNumbers changes its value, the state of the corresponding NSButton  
changes as well.


The message flow is:
1) Click button -> IBAction: send message to network device and  
reset button to its former state (to show nothing happened yet).
2) Receive reply from network device -> update the NSNumber, thereby  
updating the state of the button to show the user that something  
happened out there


The reason for doing it this way is I want to show the user that the  
change actually took place in the network device, and not just the  
button changing state, assuming everything went well. I use an on/ 
off button, since momentary buttons don't show their state.
The reply from the network device holds information about the index  
in the array, and I can get as far as setting the NSNumbers in the  
nested array using replaceObjectAtIndex from the input stream  
handler, but I can't bind that array to the button states.


I have tried a second NSArrayController (well, I've tried a lot of  
things), and I can bind to the nested array, but I can't for the  
life of me figure out how I bind the NSNumbers in the nested array  
to my button states. Perhaps I need to place the buttons in an array  
and bind the contents of the array in the base object to the  
contents of the array in the NSWindowController?
For now, I have scrapped the nested array altogether and have a  
bunch of internal variables with getters and setters in both ends.  
In the input stream handler, I build a selector to the setter  
functions from the index information. It works, but it seems very un- 
cocoa-ish, and it's certainly not pretty.


Does anyone know how to do this?

Regards, and thanks in advance,
Jens






___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Changing NSTextFieldCells' editing appearance?

[Negm-Awad Amin]

Am Fr,15.08.2008 um 18:02 schrieb Tim Andersson:


Hi there,

I have a few questions about changing the way my NSTextFieldCells  
look while they are being edited.
First off, when editing my cell, the cell's background-color changes  
to black (As such: http://img170.imageshack.us/img170/4610/bild1zq3.png) 
. Is there any way of changing it to white instead? I've tried  
setBackgroundStyle:NSBackgroundStyleLight without succes.

-setBackgroundColor: didn't work?




I'm also wondering if there's any chance of making the  
NSTextFieldCell behave like a NSTextField without border and focus  
ring?
Did you read the documentation about the relationship between cells  
and views?


So that the only thing that happens when I double-click to edit my  
cell is that the text is highlighted. I've tried setBordered:NO and  
setFocusRing:NSFocusRingTypeNone , but I still get a white border  
(And a black background) around it when I edit it.


All help is appreciated,
Tim Andersson


Cheers

Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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

[Negm-Awad Amin]

Hi,

Am Fr,15.08.2008 um 00:21 schrieb 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.

Do you know that view and the binding to be updated?

Try this, it simply simulates a model change

NSView* view = … // I assume, that you know that
NSDictionary* binding = [view infoForBinding:/*Probably @"value" … 
*/]; // I assume, that you know that


id object= [binding objectForKey:NSObservedObjectKey];
NSString* keyPath= [binding objectForKey:NSObservedKeyPathKey];
[object willChangeValueForKeyPath:keyPath];
[object didChangeValueForKeyPath:keyPath];

But probably I misunderstood you.

Cheers,
Amin




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/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: CoreData, Object/Array Controllers and KVO

[Negm-Awad Amin]

Am Do,14.08.2008 um 07:46 schrieb Jeff Hellman:


Hi Folks-

Hi

as already said, KVO is not the right place to do that.

If this is a real important property, you should think about a model  
user interface (update button, sheet) to handle it. You can use  
notifications or maybe "bindings through through a controller".


But first you have to think aboout the semantics of an undo. Is this a  
new change or should the update value go back to the last change  
before the undone opertation? Maybe a "real" change history would help  
yoou.


Cheers,

Amin



I've got a document based CoreData application.

When I open a file and add some of my NSManagedObject subclass objects
to either an NSArrayController (bound to an entity in my NIB) or
NSObjectController (-setContent) the

- (void)willChangeValueForKey:(NSString *)key

is called.  So is

- (void)didChangeValueForKey:(NSString *)key

Why is this?  I'm not actually changing the object values, am I?

Thanks-
Jeff




--
Jeff Hellman
[EMAIL PROTECTED]
___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Should I retain a variable returned from this accessor?

[Negm-Awad Amin]

Am Di,12.08.2008 um 21:36 schrieb Shawn Erickson:

On Tue, Aug 12, 2008 at 2:12 AM, Negm-Awad Amin <[EMAIL PROTECTED] 
> wrote:


BTW: You can do the same inside a getter to get rid of thread  
problems.


Nope it does nothing to solve threading issues ([[blah retain]
autorelease] isn't an atomic operation) you need to protect it with an
critical section of some type. Additionally adding locking at the
level of accessor is often far to granular to be useful to clients of
a class.

-Shawn
Of course you have to do locking additionally. I did not want to say,  
that this solves all problems of threading.


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Accessing memory of another application?

[Negm-Awad Amin]

Am Di,12.08.2008 um 19:33 schrieb Jean-Daniel Dupas:



In practice, it's perfectly possible to access other processes  
memory using public functions (it require some privileges since 10.4  
intel).
But to do it you have to use the low-level mach API and that's off  
topic here.

This is exactly what I wrote:
here are techniques to get acccess to another application memory under  
some circumstances. None of them is related to Cocoa …






And no, code injection is not used only by virus. (see http://rentzsch.com/mach_star/ 
 )

I know the red shed.

Amin





Le 12 août 08 à 19:18, Negm-Awad Amin a écrit :



Am Di,12.08.2008 um 19:01 schrieb Mike Abdullah:

You can't do this. Each application runs in its own protected  
memory.

Sometimes you can do this:
http://en.wikipedia.org/wiki/Computer_virus
;-)

Serious: There are techniques to get acccess to another application  
memory under some circumstances. None of them is related to Cocoa  
since there is no class named NSVirus.


Amin





On 12 Aug 2008, at 17:04, Josh wrote:


All,

I'm trying to get started w/viewing/editing/interacting with the  
memory of
another running application but I'm not where to get started.   
You could
think of this as being a simple "game trainer" - which basically  
allows you

to view and edit values in memory.

Can anyone point me to where I should get started?  Function  
names/examples
would be a GREAT help - I haven't had experience with hooking  
into another

application's memory.

Thanks
___

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

Please do not post 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/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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/devlists%40shadowlab.org

This email sent to [EMAIL PROTECTED]





Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Accessing memory of another application?

[Negm-Awad Amin]

Am Di,12.08.2008 um 19:01 schrieb Mike Abdullah:


You can't do this. Each application runs in its own protected memory.

Sometimes you can do this:
http://en.wikipedia.org/wiki/Computer_virus
;-)

Serious: There are techniques to get acccess to another application  
memory under some circumstances. None of them is related to Cocoa  
since there is no class named NSVirus.


Amin





On 12 Aug 2008, at 17:04, Josh wrote:


All,

I'm trying to get started w/viewing/editing/interacting with the  
memory of
another running application but I'm not where to get started.  You  
could
think of this as being a simple "game trainer" - which basically  
allows you

to view and edit values in memory.

Can anyone point me to where I should get started?  Function names/ 
examples
would be a GREAT help - I haven't had experience with hooking into  
another

application's memory.

Thanks
___

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

Please do not post 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/cocoadev%40mikeabdullah.net

This email sent to [EMAIL PROTECTED]


___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/negm-awad%40cocoading.de

This email sent to [EMAIL PROTECTED]


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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: Should I retain a variable returned from this accessor?

[Negm-Awad Amin]

Am Di,12.08.2008 um 14:37 schrieb Sean DeNigris:

Hi, how do I handle memory management for todoUid below?  Do I  
have to

retain or autorelease it?

[...snip...]

 // Get uid to return
 NSString* todoUid = [newTodo uid];

[...snip...]

 return todoUid;
}


you could do:

NSString* todoUid = [[[newTodo uid] retain] autorelease];

YES! Many, many of memory managemt problems are solved with this  
technique. BTW: You can do the same inside a getter to get rid of  
thread problems.


Is the performance hit of keeping objects around until the next pool  
drain (instead of releasing them when you're done with them)  
insignificant?
In most cases: Yes. You can recognize the other cases after checking  
it. (Insert quotation of Donald Knuth here).


More: As I wrote, releasing the allocated object let this object  
disappear. It does not free any object that had been allocated in the  
autorelease pool, when the released object was constructed. The  
isolated -release is a king of prying.


So the solution is not to send some release-messages to anything  
aorund, trying to hit one or another object, but using a custom ARP.


 In other words, should it be a practice to always autorelease with  
alloc and init (except for loops as previously mentioned)?


Amin Negm-Awad
[EMAIL PROTECTED]




___

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

Please do not post 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]