render and edit xaml on ipad

2011-01-13 Thread Nethan Bharti
Hi All, Need your help...
In a new project, I have to render and allow editing of xaml packages on
iPad. Can anyone guide me, if there are some existing frameworks to render
xaml on iPad, and which also allow xaml editting. Or any suggestions as to
how can I proceed?

Any help appreciated
ab
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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


Toolbar validation and modal panel

2011-01-13 Thread Bruno Berisso
Hello all.

In my application I use a modal sheet for block the user interface while the 
app is consulting a remote service. The call to the service is executed in 
background and the sheet is show/hide with two  methods defined in the 
application
delegate 'showLoading' and 'hideLoading'. Those are:

- (void)showLoading {
[self performSelectorOnMainThread:@selector(showLoadingPanelAction) 
withObject:nil waitUntilDone:NO];
}

- (void)showLoadingPanelAction {
if (!self.loadingPanel) {
self.loadingPanel = [[LoadingViewController alloc] init];
[self.loadingPanel showInWindow:[NSApp mainWindow]];
}
}

- (void)hideLoading {
[self performSelectorOnMainThread:@selector(hideLoadingPanelAction) 
withObject:nil waitUntilDone:NO];
}

- (void)hideLoadingPanelAction {
if (self.loadingPanel) {
[loadingPanel dismissModal];
[loadingPanel release];
loadingPanel = nil;
}
}


The LoadingViewController : SheetController class:

- (void)showInWindow:(NSWindow *)mainWindow {
sheetWindow = [self window];
[self sheetWillShow];

[NSApp beginSheet:sheetWindow modalForWindow:mainWindow 
modalDelegate:nil didEndSelector:nil contextInfo:nil];
[NSApp runModalForWindow:sheetWindow];
[NSApp endSheet:sheetWindow];
[sheetWindow orderOut:self];
}

- (void)dismissModal {
[sheetWindow close];
[NSApp stopModal];
}

For some reason when the sheet end all the toolbar items are disabled no matter 
what value return the 'validateToolbarItems' method.
If i debug the calls made to 'setEnabled' of my NSToolbarItems the last call 
stack looks like this:

#0  0x10002d3e0 in -[NSToolbarItems(Debug) setEnabled:] at 
ActionsController.m:30
#1  0x7fff87b321a4 in -[NSToolbarItem setEnabled:]
#2  0x7fff88075b77 in -[NSToolbarItem _restoreToolbarItemAfterSheet]
#3  0x7fff81639153 in -[NSArray makeObjectsPerformSelector:]
#4  0x7fff85dc2a66 in _nsnote_callback
#5  0x7fff81621000 in __CFXNotificationPost
#6  0x7fff8160d578 in _CFXNotificationPostNotification
#7  0x7fff85db99ce in -[NSNotificationCenter 
postNotificationName:object:userInfo:]
#8  0x7fff87d191dc in -[NSWindow(NSSheets) _detachSheetWindow]
#9  0x7fff87d18ef5 in -[NSMoveHelper(NSSheets) _closeSheet:andMoveParent:]
#10 0x7fff87d18c75 in -[NSWindow(NSSheets) _orderOutRelativeToWindow:]
#11 0x7fff87acddf6 in -[NSWindow 
_reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:]
#12 0x7fff87acd77a in -[NSWindow orderWindow:relativeTo:]
#13 0x7fff87c7f924 in -[NSWindow _close]
#14 0x100018ac5 in -[SheetController dismissModal] at SheetController:32
#15 0x11c82 in -[TestAppDelegate hideLoadingPanelAction] at 
TestAppDelegate:158
#16 0x7fff85dda44f in __NSThreadPerformPerform
#17 0x7fff816162ad in __CFRunLoopDoSources0
#18 0x7fff816145f9 in __CFRunLoopRun
#19 0x7fff81613dbf in CFRunLoopRunSpecific
#20 0x7fff8693393a in RunCurrentEventLoopInMode
#21 0x7fff8693373f in ReceiveNextEventCommon
#22 0x7fff869335f8 in BlockUntilNextEventMatchingListInMode
#23 0x7fff87ad5e64 in _DPSNextEvent
#24 0x7fff87ad57a9 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
#25 0x7fff87d10c47 in -[NSApplication _realDoModalLoop:peek:]
#26 0x7fff87d0e7d5 in -[NSApplication runModalForWindow:]
#27 0x100018a31 in -[SheetController showInWindow:] at SheetController:26
#28 0x11973 in -[TestAppDelegate showLoadingPanelAction] at 
TestAppDelegate:125
#29 0x7fff85dda44f in __NSThreadPerformPerform
#30 0x7fff81616401 in __CFRunLoopDoSources0
#31 0x7fff816145f9 in __CFRunLoopRun
#32 0x7fff81613dbf in CFRunLoopRunSpecific
#33 0x7fff8693393a in RunCurrentEventLoopInMode
#34 0x7fff8693369d in ReceiveNextEventCommon
#35 0x7fff869335f8 in BlockUntilNextEventMatchingListInMode
#36 0x7fff87ad5e64 in _DPSNextEvent
#37 0x7fff87ad57a9 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:]
#38 0x7fff87a9b48b in -[NSApplication run]
#39 0x7fff87a941a8 in NSApplicationMain
#40 0x11299 in main at main.m:13


The question is, what i'm doing wrong? how can i fix this issue?
Thanks for your time.

___

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

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

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

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


Core Data - NSFetchRequest Issue

2011-01-13 Thread Joshua Lee Tucker
Hello,

I have a small problem with NSFetchRequest. For some reason unknown to me, 
NSFetchRequest is not just returning my selected entity. I'll put this in 
context:

I have two entities, one called Report and the other called Location.

Report has a one-to-many relationship to Location, and I have multiple Location 
objects.

I am attempting to retrieve all of my Report objects, but when I retrieve them, 
my array shows that I have also retrieved Locations objects.

I am using -addLocationsObject: to add Location objects to each individual 
Report location.

I'd appreciate it if anyone could shed any light on this matter.

Thanks,

Joshua Lee Tucker
Lead Engineer - Stunnify
@DarkMalloc
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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


Code Signing and a Background Tool

2011-01-13 Thread Matt Patenaude
Hi there,

I'm having a bit of an issue with one of my applications. The way the 
application works is by spawning a background process at app startup, the 
executable for which is contained within its Resources directory. While 
running, however, running `codesign -v x` on the PID of the background 
process returns:

x: code identity has been invalidated

The signature of the main application validates just fine, and the signature of 
the background executable itself (while not running) is also valid. When 
running, however, it claims that its identity is no longer valid.

A few things to take into account:

a) The background process is a command-line tool (and thus has an inferred 
identity rather than explicit), while the main process is an app bundle.

b) The background process calls NSApplicationLoad() (I don't know if it's 
relevant, but I can see how that could conceivably do something wonky to 
invalidate an identity).

c) The background process loads Cocoa plug-ins (using NSBundle -load) from its 
parent app's PlugIns directory; so, however, does the parent app, and its 
signature does not get invalidated.

Any thoughts on where I should look for problems and what I could do to prevent 
this invalidation would be much appreciated!

-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/archive%40mail-archive.com

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


NSView/NSResponder returns YES

2011-01-13 Thread Leanne Attard
Hi all,

I am having a problem with NSView/NSResponder class.  I need to override the 
NSView method acceptsFirstResponder method as from the documentation i have 
read the NSResponder method returns NO by default.  However with the code i am 
using below i am getting a YES already without overriding.  Just to brief you i 
am creating a java application which creates a JFrame and then i am taking the 
native part of AWT from it which is an NSView instance so i suppose it can be 
considered as NSResponder and so i expect a NO.

NSView* nsview = (dsi_mac->cocoaViewRef);

if ([nsview acceptsFirstResponder]==YES)
printf("Accepted first responder\n");

and the output is

Accepted first responder



Another question is that i need to subclass the NSView and then create an 
instance of this new subclass from the NSView i have from the the AWT, how can 
i do is?  Casting of NSView* to MyNSView* is not working, which i suppose it is 
because i am just casting the pointer and not the object pointed to.


Any hints what is going on please?


  
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSUndoManager retain/release of arguments - ad infinitum

2011-01-13 Thread John Bartleson
Thank you all for your comments. Because I think this is an important  
topic (and because I'm stubborn)

I'm going to continue to beat it to death.

Because there were a number of issues brought up in the comments, let  
me summarize them, with my

responses in line:

** Comment 1 (Graham Cox, January 10, 2011 9:39:06 PM PST) **
"My first thought, before I go further, is that to undo a sort,  
you are doing things way too
complicated. You only need to pass the sort descriptors to the  
undo manager, not a copy of the data."

** Response to Comment 1 **
It appears that I didn't properly explain that the code I  
included in my second post is only
executed if the dataSource method determines that no old  
sortDescriptors exist for the
data array, meaning the array is initially unsorted. If both old  
and new sort descriptors
exist for the data array, which means that the array has been  
previously sorted, my main
tableView:sortDescriptorsDidChange: method sets up an undo with  
swapped old and new descriptors
and then sorts using the new descriptors. Simple, like you said.  
I didn't include this main method
in my post. I call the code in Part 1 and Part 2 of my post only  
if, as Jerry Krinock pointed out
(January 10, 2011 10:35:28 PM PST), "...the objects had been  
manually arranged into some arbitrary
order by the user" and there are no old sort descriptors to use  
for undo. In this case, it seemed
to me that the most efficient way to recover the original  
arbitrary data order was to make a

shallow copy of the entire array.
** Comment 2 (Steven Hooley, January 11, 2011 3:27:47 AM PST) **
"either : a) sort order is a property of the window, not your  
model and shouldn't be undoable at
all OR b) the sort order is inherently part of your model,  
your data is an ordered-set and the

user can arbitrarily order the items as she pleases."
** Response to Comment 2 **
Good point, and one that I hadn't thought of. I had  
simplistically designed my app to use
sort order as b) part of the model, but a) suggests interesting  
design possibilities.

** Comment 3 (Graham Cox, January 10, 2011 9:39:06 PM PST) **
"Specifying 'assign' here is probably wrong. It is not retaining  
the assigned array, so you are
stating you don't own it. Yet I suspect that you do want to own  
it. You're relying on the undo

manager retaining it because you have neglected to do so."
** Response to Comment 3 **
You're right - it's sloppy coding on my part. In my post I showed  
the @property in a comment in case
someone would see if this was wrong. I changed the @property from  
'assign' to 'retain', as you
suggested, and there's no crash on Redo. However, there's still a  
problem in that I don't know
if the array I allocated (in Part 1) with mutableCopyWithZone: is  
always being released. I'll

explain again:

The real point of my original plaintive cry, and I'm sorry if it's  
become obfuscated, is that I
had to allocate memory as part of setting up for undo, but I couldn't  
find any *simple* way to
keep track of whether that memory is still in use or not, thus  
threatening a memory leak. This
is not a sorting problem - it appears that it will occur generically  
whenever we write reference-
counted code that allocates memory and then passes that memory,  
usually via -prepareWithInvocationTarget:,

to an undo method.

Graham Cox made an interesting comment earlier:
"...once the undo manager performs the undo, it will release the  
invocation that is retaining

the array, which will dealloc it."

This gave me a glimmer of hope to explain what's going on. If in my  
method I allocate an
object (see the Part 1 code in my 2nd post), save a pointer to the  
object in the local variable
'unsortedArray', pass the pointer to -prepareWithInvocationTarget:,  
then exit the method, my pointer
is gone. If I haven't kept a copy of the pointer (say in an NSDocument  
instance variable)
-prepareWithInvocationTarget: (or the instance of NSUndoManager or  
whatever) is now sole

owner of the pointer.

Because it owns the only pointer, -prepareWithInvocationTarget: (or  
whatever) now owns the object.


Recall that, after I fixed my @property, my code appears to work  
properly. Ignoring the fact that
I don't know any way to verify that the object is actually being  
deallocated at NSDocument dealloc time,
I conclude that NSUndoManager and -prepareWithInvocationTarget: must  
be designed to retain and
release objects passed to them as needed to provide undo  
functionality. As Graham says: "it
follows the rules for ownership of objects, so by and large does the  
'right thing'."


There's appears to be only one problem remaining: this behavior is not  
documented anywhere I can
find. In fact, Apple's 'Undo Architecture' implies just the opposite:  
"An NSUndoManager object does

not retain the targets of undo operations."

Re: NSUndoManager retain/release of arguments - ad infinitum

2011-01-13 Thread Graham Cox

On 13/01/2011, at 7:52 PM, John Bartleson wrote:

> The real point of my original plaintive cry, and I'm sorry if it's become 
> obfuscated, is that I
> had to allocate memory as part of setting up for undo, but I couldn't find 
> any *simple* way to
> keep track of whether that memory is still in use or not, thus threatening a 
> memory leak.


You are not required to keep track of it. You allocate it, pass it on, then 
release it. It's no longer of any interest to you, you're done with it. 
Standard MM rules.

> This
> is not a sorting problem - it appears that it will occur generically whenever 
> we write reference-
> counted code that allocates memory and then passes that memory, usually via 
> -prepareWithInvocationTarget:,
> to an undo method.

Let's make something clear.

-prepareWithInvocationTarget: takes just one argument - the target to call when 
undo or redo is invoked. This method then returns an object - in fact a NSProxy 
in the current implementation, but that's not especially important to this 
discussion.

While you typically write something like this:

[[undoManager prepareWithInvocationTarget:self] 
performSortWithDescriptors:descriptors];

what you're really doing is this:

id proxy = [undoManager prepareWithInvocationTarget:self];
[proxy performSortWithDescriptors:descriptors];

So at no point are you passing objects such as arrays or sort descriptors to 
-prepareWithInvocationTarget:, you are passing the TARGET. By and large this 
will be 'self', the object that is setting up the undo. It is not retained.

On the returned proxy, you call a method, which is a method you know to exist 
in the target (self). The proxy is set up so that, because it knows about the 
target already, it can 'fake' the existence of that method within itself. When 
you call that method, it freezes it and all its arguments into an NSInvocation 
which is stored by the NSUndoManager. The arguments are retained.


> This gave me a glimmer of hope to explain what's going on. If in my method I 
> allocate an
> object (see the Part 1 code in my 2nd post), save a pointer to the object in 
> the local variable
> 'unsortedArray', pass the pointer to -prepareWithInvocationTarget:, then exit 
> the method, my pointer
> is gone. If I haven't kept a copy of the pointer (say in an NSDocument 
> instance variable)
> -prepareWithInvocationTarget: (or the instance of NSUndoManager or whatever) 
> is now sole
> owner of the pointer.

No, you don't pass the pointer to -prepareWithInvocationTarget:, see above. You 
pass the pointer as an argument to a method of the target which is actually 
invoked on the NSProxy.

This isn't as complicated as it sounds. But the distinction is important, 
because the proxy converts the method call to an invocation, and the invocation 
retains the arguments. So yes, that means that the undo manager does take 
ownership of the arguments, because it owns the invocations.

By the way, while none of this is especially transparent in NSUndoManager, you 
can follow the code in my GCUndoManager, which uses different structures but 
works similarly.

> Recall that, after I fixed my @property, my code appears to work properly. 
> Ignoring the fact that
> I don't know any way to verify that the object is actually being deallocated 
> at NSDocument dealloc time,
> I conclude that NSUndoManager and -prepareWithInvocationTarget: must be 
> designed to retain and
> release objects passed to them as needed to provide undo functionality. As 
> Graham says: "it
> follows the rules for ownership of objects, so by and large does the 'right 
> thing'."

You are not required to verify it. (Though you may do so using the memory 
tracing tools). You only need to follow the rules, and understand that the undo 
manager also follows the rules. When everyone follows the rules, the need to 
verify and check ownership disappears - you can take it as read that correct 
memory management is performed. In other words you only need to concentrate on 
ensuring YOUR code follows the rules - the frameworks can be assumed to.

> There's appears to be only one problem remaining: this behavior is not 
> documented anywhere I can
> find. In fact, Apple's 'Undo Architecture' implies just the opposite: "An 
> NSUndoManager object does
> not retain the targets of undo operations."


That's because you are confusing the target of the undo operation (not 
retained) with the arguments to the undo invocation (retained).

The documentation is not required to state that any particular class follows 
the MM rules - all classes can be assumed to. Only exceptions to the standard 
rules need to be documented.

--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/archiv

Re: Core Data - NSFetchRequest Issue

2011-01-13 Thread Jerry Krinock

On 2011 Jan 10, at 10:54, Joshua Lee Tucker wrote:

> I am attempting to retrieve all of my Report objects, but when I retrieve 
> them, my array shows that I have also retrieved Locations objects.

See -[NSFetchRequest setEntity:].  But if I recall correctly a fetch request 
will raise an exception if you execute it without setting an entity, so I'm 
confused.  You should post some code.

___

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

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

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

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


How to use inline functions

2011-01-13 Thread Oleg Krupnov
Hi,

I realize that my question has no relation to Cocoa, but it's still
the place where I can get the fastest answer :)

In several places in my app I check if the user has a valid license
for my app. I'd like to make cracking the app somewhat more difficult
and rather than calling -[license isValid], I want to call
isLicenseValid(), and inline this function, so that the entire code of
this function is duplicated in the binary in each place where I make
the call to isLicenseValid().

How should I declare the function in this case?

I have made an h-file and put the body of the function there:

(LicenseValidation.h)

inline bool isLicenseValid()
{
   ...
   return isValid;
}

But when I #include this h-file into an m-file where I need it, the
compiler says "Symbol not found, _isLicenseValid referenced from ..."

So I added "static" to the declaration :

static inline bool isLicenseValid()
{
   ...
   return isValid;
}

No more errors, but I am not sure if in this case the compiler will
produce as many instances of the code as there are calls to the
function. Will it?

Thanks!

P.S. I am using a GCC compiler
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Code Signing and a Background Tool

2011-01-13 Thread Jerry Krinock
First of all, you're on the wrong email list for this topic.  Search the 
archives of Apple CDSA  for an answer to your 
question, and re-post over there if you still have trouble.

Signing background tools in app packages can be tricky.  Here is a comment from 
a script that I wrote to ship my products:

# The 'codesign' tool will make up its own code signing "identitifer" based on 
a couple of different inputs, but I don't like the idea of leaving such an 
important parameter up to a somewhat indeterminate algorithm.  Also, usually 
you want all executables in the package to be signed with the same identity, 
and to do that the identity must be passed to codesign explicitly.  Note that I 
said same identi*ty*, not identi*fier*.  Code signing identifiers should be 
unique.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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 use inline functions

2011-01-13 Thread James Bucanek
Oleg Krupnov  wrote (Thursday, 
January 13, 2011 8:21 AM +0200):



I realize that my question has no relation to Cocoa, but it's still
the place where I can get the fastest answer :)


Oleg,

Here are my thoughts:

1) I'm certainly no compiler expert, but I believe that 'static' 
will defeat 'inline', and make the function's symbol local to 
the module to boot.


2) 'inline' is just a hint and the compiler can be very picky. 
If the function is too complex (i.e. more than just a few 
statements) the compiler is well within its rights to compile it 
as a normal function and ignore in the inline directive.


3) I think #define is only the solution guaranteed to accomplish 
what you want.


4) I seriously doubt that you're going to accomplish anything 
beyond slowing crackers down for a few minutes. In fact, I'm 
guessing that you'll spend more time working on this than the 
crackers will.


--
James Bucanek

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: render and edit xaml on ipad

2011-01-13 Thread Kyle Sluder
On Jan 9, 2011, at 9:23 PM, Nethan Bharti  wrote:

> Hi All, Need your help...
> In a new project, I have to render and allow editing of xaml packages on
> iPad. Can anyone guide me, if there are some existing frameworks to render
> xaml on iPad, and which also allow xaml editting. Or any suggestions as to
> how can I proceed?

A better idea is to use a native interface and abstract it from your business 
logic as much as possible.

--Kyle Sluder___

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

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

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

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


data over USB to iPhone

2011-01-13 Thread Georg Seifert
Hi,

Do I have any chance to transmit data from a mac to iPhone over USB? I have it 
running over wifi but the app would be used for a longer time next to the mac, 
so you need to plug it in anyways.

thanks
Georg___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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 use inline functions

2011-01-13 Thread Nick Zitzmann

On Jan 13, 2011, at 8:21 AM, Oleg Krupnov wrote:

> I realize that my question has no relation to Cocoa, but it's still
> the place where I can get the fastest answer :)
> 
> In several places in my app I check if the user has a valid license
> for my app. I'd like to make cracking the app somewhat more difficult
> and rather than calling -[license isValid], I want to call
> isLicenseValid(), and inline this function, so that the entire code of
> this function is duplicated in the binary in each place where I make
> the call to isLicenseValid().
> 
> How should I declare the function in this case?

Consider using the CF_INLINE or FOUNDATION_STATIC_INLINE macros. See the 
definition of NSMakeRect() for an example.

Nick Zitzmann


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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


QuickLook returning small image

2011-01-13 Thread aglee

I'm requesting a QuickLook preview for an OmniGraffle file.  The size I'm 
asking for is 500x300.  The image I get back is much smaller, at 122x77, which 
looks terrible when I display it in my application.  When I use QuickLook to 
preview the same file in the Finder, it looks great.

Why would I get such a small image back?

Here's the code I'm using (courtesy of Matt Gemmell's handy extension on 
NSImage):

    NSDictionary *dict = 
[NSDictionary dictionaryWithObject:[NSNumbernumberWithBool:icon] 
                                                     
forKey:(NSString*)kQLThumbnailOptionIconModeKey];
    CGImageRef ref = QLThumbnailImageCreate(kCFAllocatorDefault, 
                                            (CFURLRef)fileURL, 
                                            CGSizeMake(size.width, size.height),
                                            (CFDictionaryRef)dict);
    NSLog(@"ref [%d, %d]", CGImageGetWidth(ref), CGImageGetHeight(ref));

The size passed to QLThumbnailImageCreate is documented as an upper bound.  I 
assume that means there's no promise the returned image will actually be that 
size.  But again, the Finder is able to get previews at any size I want.

--Andy


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: data over USB to iPhone

2011-01-13 Thread Kyle Sluder
On Thu, Jan 13, 2011 at 4:16 AM, Georg Seifert  wrote:
> Hi,
>
> Do I have any chance to transmit data from a mac to iPhone over USB? I have 
> it running over wifi but the app would be used for a longer time next to the 
> mac, so you need to plug it in anyways.

No.

File an enhancement request at http://bugreport.apple.com.

--Kyle Sluder
___

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

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

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

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


Re: QuickLook returning small image

2011-01-13 Thread Kyle Sluder
On Thu, Jan 13, 2011 at 9:43 AM, aglee  wrote:
> I'm requesting a QuickLook preview for an OmniGraffle file.  The size I'm
> asking for is 500x300.  The image I get back is much smaller, at 122x77,
> which looks terrible when I display it in my application.  When I use
> QuickLook to preview the same file in the Finder, it looks great.
>
> Why would I get such a small image back?
>
> Here's the code I'm using (courtesy of Matt Gemmell's handy extension on
> NSImage):
>
>     NSDictionary *dict =
> [NSDictionary dictionaryWithObject:[NSNumbernumberWithBool:icon]
>
>   forKey:(NSString*)kQLThumbnailOptionIconModeKey];
>     CGImageRef ref = QLThumbnailImageCreate(kCFAllocatorDefault,
>                                             (CFURLRef)fileURL,
>                                             CGSizeMake(size.width,
> size.height),
>                                             (CFDictionaryRef)dict);
>     NSLog(@"ref [%d, %d]", CGImageGetWidth(ref), CGImageGetHeight(ref));

Taking a while stab here: icon==YES?

--Kyle Sluder
___

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

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

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

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


Re: QuickLook returning small image

2011-01-13 Thread Kyle Sluder
On Thu, Jan 13, 2011 at 10:06 AM, Kyle Sluder  wrote:
> Taking a while stab here: icon==YES?

*Wild* stab.

Coffee is good.

--Kyle Sluder
___

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

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

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

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


Re: QuickLook returning small image

2011-01-13 Thread aglee

On Jan 13, 2011, at 01:06 PM, Kyle Sluder  wrote:
Taking a while stab here: icon==YES?

I get the same result (size-wise) whether icon is YES or NO.

Joar pointed out off-list that Finder might be asking for a *preview* rather 
than a *thumbnail*.  I totally missed that distinction and I bet it's the 
explanation.

Thanks,
--Andy

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: QuickLook returning small image

2011-01-13 Thread aglee

On Jan 13, 2011, at 01:07 PM, Kyle Sluder  wrote:

On Thu, Jan 13, 2011 at 10:06 AM, Kyle Sluder  wrote:

Taking a while stab here: icon==YES?


*Wild* stab.

Coffee is good.
 

I was going to say, in this case it's more of an "if" stab than a "while" stab.

--Andy

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: sending a message from an initializer method

2011-01-13 Thread Uli Kusterer
On Jan 13, 2011, at 1:27 AM, Erik Buck wrote:
> Class or instance method makes no difference in this case with regard to 
> polymorphism.

 It does. He's only passing the two instance variables to the class method. 
And, being a class method, "self" is the class, not the half-initialized 
instance.

 So what using a class method does, is it makes it possible for subclasses to 
change the computation by overriding the method (assuming he's using [[self 
class] compute:...] to call the class method, and doesn't hardcode the class 
name). However, since it's a class method, subclasses can't accidentally mess 
with the half-initialized object.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: data over USB to iPhone

2011-01-13 Thread Reaves, Timothy
That's not correct.  There are Apple approved cables to allow you to do
exactly that (there is a serial cable too).  But my understanding is the
cable itself is not certified by Apple, but the actual usage of the cable.
You you can get one of the existing cables and see if you can use it for
your purpose, or contact the cable manufacturer, and see what they would
charge to provide cables to you that are certified by Apple.



On Thu, Jan 13, 2011 at 1:05 PM, Kyle Sluder  wrote:

> On Thu, Jan 13, 2011 at 4:16 AM, Georg Seifert 
> wrote:
> > Hi,
> >
> > Do I have any chance to transmit data from a mac to iPhone over USB? I
> have it running over wifi but the app would be used for a longer time next
> to the mac, so you need to plug it in anyways.
>
> No.
>
> File an enhancement request at http://bugreport.apple.com.
>
> --Kyle Sluder
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> http://lists.apple.com/mailman/options/cocoa-dev/treaves%40silverfieldstech.com
>
> This email sent to trea...@silverfieldstech.com
>
___

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

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

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

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


Re: data over USB to iPhone

2011-01-13 Thread Kyle Sluder
On Thu, Jan 13, 2011 at 11:12 AM, Reaves, Timothy
 wrote:
> That's not correct.  There are Apple approved cables to allow you to do
> exactly that (there is a serial cable too).  But my understanding is the
> cable itself is not certified by Apple, but the actual usage of the cable.
> You you can get one of the existing cables and see if you can use it for
> your purpose, or contact the cable manufacturer, and see what they would
> charge to provide cables to you that are certified by Apple.

Are these cables part of the Made for iPhone program?

Aside from USB audio and keyboards, there's no out-of-the-box support
for communicating over USB with the iOS SDK.

--Kyle Sulder
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: sending a message from an initializer method

2011-01-13 Thread Erik Buck
Fair enough.

On Jan 13, 2011, at 1:19 PM, Uli Kusterer wrote:

> On Jan 13, 2011, at 1:27 AM, Erik Buck wrote:
>> Class or instance method makes no difference in this case with regard to 
>> polymorphism.
> 
> It does. He's only passing the two instance variables to the class method. 
> And, being a class method, "self" is the class, not the half-initialized 
> instance.
> 
> So what using a class method does, is it makes it possible for subclasses to 
> change the computation by overriding the method (assuming he's using [[self 
> class] compute:...] to call the class method, and doesn't hardcode the class 
> name). However, since it's a class method, subclasses can't accidentally mess 
> with the half-initialized object.
> 
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> 
> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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


Maintaining NSCursor outside of app window

2011-01-13 Thread Markus Spoettl
Hello,

  I have a drag-n-drop UI where I use the [NSCursor disappearingItemCursor] to 
indicate that if you drop now, you're going to remove the item being dragged. I 
do this by setting the cursor when my dragging destination receives a 
-draggingExited: message (the dragging destination and source are the same, an 
NSView subclass).

It works well inside the application but when the cursor leaves the application 
window, things break down. When this happens the cursor is reset to the default 
arrow cursor. What's worse is that it doesn't return to -disappearingItemCursor 
when the cursor re-enters my window - not view - without releasing the mouse. 

What I'd like to get to is a behavior like that of Finder. When you drag a 
"Places" item out of the source list Finder somehow manages to maintain the 
cursor, even if the app behind the cursor is something else.

My drag starts with a call to NSView's 
-dragImage:at:offset:event:pasteboard:source:slideBack:

I'd rather not implement the whole dragging UI (transparent foreground window 
occupying the entire screen, painting the drag image myself - at least I think 
that's how it could work) if I can avoid it because I fear there are countless 
little traps to hit on the way.

Is there a way not to get the cursor reset by AppKit behind my back?

Regards
Markus
--
__
Markus Spoettl

___

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

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

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

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


Re: sending a message from an initializer method

2011-01-13 Thread Richard Somers

On Jan 12, 2011, at 4:41 AM, Luc Van Bogaert wrote:

I would like to implement that algorithm in a seperate method,  
instead of writing it directly in the initializer. Is that OK, and  
could I then message "self" in the initializer like:


- (id) init
{
self = [super init];
if (self) {
var1 = ...;
var2 = ...;
var3 = [self computerVar3With:var1:var2];
}
return self;
}



I often will do something like this.

- (id)init
{
 self = [super init];
 if (self) {
 [self prepare...];
 [self prepare...];
 [self prepare...];
 // etc...
 }
 return self;
}

The methods 'prepare...' are all private methods. The preparation code  
for one of my classes is over 300 lines with five individual prepare  
methods. Breaking it up like this keeps it organized, understandable,  
and aids in debugging and refactoring. It works very well.


--Richard Somers

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Maintaining NSCursor outside of app window

2011-01-13 Thread Corbin Dunn
Hi Markus,

Use:

- (void)draggedImage:(NSImage *)draggedImage movedTo:(NSPoint)screenPoint

Then do something like this (after converting the screen point to window 
coords):

NSPoint windowPoint = [[view window] mouseLocationOutsideOfEventStream];
NSPoint localPoint = [view convertPoint:windowPoint fromView:nil];
if (![view mouse:localPoint inRect:[view visibleRect]]) {
[[NSCursor disappearingItemCursor] set];
}

corbin


On Jan 13, 2011, at 4:11 PM, Markus Spoettl wrote:

> Hello,
> 
>  I have a drag-n-drop UI where I use the [NSCursor disappearingItemCursor] to 
> indicate that if you drop now, you're going to remove the item being dragged. 
> I do this by setting the cursor when my dragging destination receives a 
> -draggingExited: message (the dragging destination and source are the same, 
> an NSView subclass).
> 
> It works well inside the application but when the cursor leaves the 
> application window, things break down. When this happens the cursor is reset 
> to the default arrow cursor. What's worse is that it doesn't return to 
> -disappearingItemCursor when the cursor re-enters my window - not view - 
> without releasing the mouse. 
> 
> What I'd like to get to is a behavior like that of Finder. When you drag a 
> "Places" item out of the source list Finder somehow manages to maintain the 
> cursor, even if the app behind the cursor is something else.
> 
> My drag starts with a call to NSView's 
> -dragImage:at:offset:event:pasteboard:source:slideBack:
> 
> I'd rather not implement the whole dragging UI (transparent foreground window 
> occupying the entire screen, painting the drag image myself - at least I 
> think that's how it could work) if I can avoid it because I fear there are 
> countless little traps to hit on the way.
> 
> Is there a way not to get the cursor reset by AppKit behind my back?
> 
> 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/corbind%40apple.com
> 
> This email sent to corb...@apple.com

___

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

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

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

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


Re: Maintaining NSCursor outside of app window

2011-01-13 Thread Markus Spoettl
On Jan 13, 2011, at 7:37 PM, Corbin Dunn wrote:
> - (void)draggedImage:(NSImage *)draggedImage movedTo:(NSPoint)screenPoint
> 
> Then do something like this (after converting the screen point to window 
> coords):
> 
> NSPoint windowPoint = [[view window] mouseLocationOutsideOfEventStream];
> NSPoint localPoint = [view convertPoint:windowPoint fromView:nil];
> if (![view mouse:localPoint inRect:[view visibleRect]]) {
> [[NSCursor disappearingItemCursor] set];
> }

Fantastic, thanks so much Corbin!

Regards
Markus
--
__
Markus Spoettl

___

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

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

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

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


Re: Maintaining NSCursor outside of app window

2011-01-13 Thread Quincey Morris
On Jan 13, 2011, at 16:48, Markus Spoettl wrote:

> On Jan 13, 2011, at 7:37 PM, Corbin Dunn wrote:
>> - (void)draggedImage:(NSImage *)draggedImage movedTo:(NSPoint)screenPoint
>> 
>> Then do something like this (after converting the screen point to window 
>> coords):
>> 
>>NSPoint windowPoint = [[view window] mouseLocationOutsideOfEventStream];
>>NSPoint localPoint = [view convertPoint:windowPoint fromView:nil];
>>if (![view mouse:localPoint inRect:[view visibleRect]]) {
>>[[NSCursor disappearingItemCursor] set];
>>}
> 
> Fantastic, thanks so much Corbin!

It may be problem fully solved in regard to your original question, but ...

1. In the past, in trying to debug why the cursor changes back to an arrow 
unexpectedly (in the sorts of scenario you described) I found that scroll views 
tend to change the cursor when the pointer passes over parts of the scroll view 
that aren't showing the document view itself -- scroll bars, borders, etc. That 
can be annoying when you're trying to manage the cursor very carefully yourself.

2. I don't know how big a problem it is, but there's a doubtful aspect of using 
'mouseLocationOutsideOfEventStream' like this. At the time such code is 
executed, the position of whatever is being dragged (the transparent image in 
this case) may well be synchronized with the event stream. It's possible for 
the unsynchronized position to be quite different, which means that the image 
position and the cursor shape would end up being puzzlingly mismatched.

Whether this would afflict the above code, I really don't know, but it's worth 
spending a bit of time testing (with fast pointer movements and busy 
processors, perhaps).


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSUndoManager retain/release of arguments - ad infinitum

2011-01-13 Thread John Bartleson
Graham: thanks for your comment and thanks for being patient with a  
relative n00b. Hopefully we can

nail this topic down in a post or two.

You are not required to verify it. (Though you may do so using the  
memory tracing tools). You only need to follow the rules, and  
understand that the undo manager also follows the rules. When  
everyone follows the rules, the need to verify and check ownership  
disappears - you can take it as read that correct memory management  
is performed. In other words you only need to concentrate on  
ensuring YOUR code follows the rules - the frameworks can be assumed  
to.


I'm sure you'd agree that when we're learning a new environment,  
references and documentation are only
part of the process. If we can't figure out the docs, and lacking an  
expert in the next cubicle to ask,
then writing a test app will usually quickly answer our question. This  
is where a legitimate need to

verify and check object ownership comes from.

You mentioned memory tracing tools. I'm familiar with Instruments, but  
I wasn't aware you could use it

to trace individual variables. Did you have a particular tool in mind?

So yes, that means that the undo manager does take ownership of the  
arguments, because it owns the invocations.


I'm glad to see this, because it's really the answer to my original  
question. Poking around a little, one finds
NSInvocation's retainArguments method, which is probably what  
NSUndoManager uses.


You've stated that I "only need to follow the rules." This left me to  
wonder which memory management rules
I had missed that would predict the above result. My day-to-day MM  
rules include the ususal: "If you create it
(alloc, new, copy, etc.) you own it," "You can take ownership with  
retain," "When you're finished with something

you own, you must release it," etc.

In addition we also learn special MM rules for useful framework  
classes, e.g. a collection will retain objects
passed to it. I don't, however, know any special rules pertaining to  
NSUndoManager and NSInvocation. So I re-read
Apple's "Memory Management Programming Guide." I honestly can't find  
anything in there that would be an obvious

rule pertaining to the current topic. Which rules are relevant here?


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: NSUndoManager retain/release of arguments - ad infinitum

2011-01-13 Thread Graham Cox

On 14/01/2011, at 5:58 PM, John Bartleson wrote:

> I'm glad to see this, because it's really the answer to my original question. 
> Poking around a little, one finds
> NSInvocation's retainArguments method, which is probably what NSUndoManager 
> uses.
> 
> You've stated that I "only need to follow the rules." This left me to wonder 
> which memory management rules
> I had missed that would predict the above result. My day-to-day MM rules 
> include the ususal: "If you create it
> (alloc, new, copy, etc.) you own it," "You can take ownership with retain," 
> "When you're finished with something
> you own, you must release it," etc.
> 
> In addition we also learn special MM rules for useful framework classes, e.g. 
> a collection will retain objects
> passed to it. I don't, however, know any special rules pertaining to 
> NSUndoManager and NSInvocation. So I re-read
> Apple's "Memory Management Programming Guide." I honestly can't find anything 
> in there that would be an obvious
> rule pertaining to the current topic. Which rules are relevant here?
> 


The standard rules.

There are no special rules pertaining to NSUndoManager and NSInvocation (though 
with invocations, there are certain cases where not retaining the arguments 
might be apropos, which is why there is a -retainArguments method on 
NSInvocation - NSInvocations are used in places other than undo).

I wouldn't say that  "e.g. a collection will retain objects passed to it" is a 
special rule. It necessarily follows that since collections own their contents, 
they will retain them. Most objects that store objects either singly or 
multiply use collection classes internally to do so, so in general whenever any 
object is passed to another, and is expected to live longer than a moment more, 
it will be retained.

However, I think you're focusing too much on what (framework) objects do with 
objects you pass them from 'outside' - actually, it doesn't matter. Those 
objects will do as they see fit with respect to object ownership, according to 
the rules. You need only focus on what your code does, to see that it follows 
the rules.

e.g., take this hypothetical set up for undo, based on your code:

NSArray* descriptorsCopy = [[myTableView descriptors] copy];// you now own 
'descriptorsCopy'

[[myUndoManager prepareWithInvocationTarget:self] 
sortWithDescriptors:descriptorsCopy]; // you still own 'descriptorsCopy'. Does 
the undo manager? Who knows nor cares?

// do you have any further use for the descriptorsCopy? No, so you're done with 
it. It's now your responsibility to release it as you no longer own it

[descriptorsCopy release];


In the middle step, why should YOU worry about whether the undo manager has 
retained 'descriptorsCopy'? It's not your responsibility how that object works. 
It might have retained the object, copied it, turned it into something 
completely different, or buried it in soft peat for three months. Not your 
concern. All you know is, following that line, you have no further interest in 
the object, so you release it.

It's when you try to second-guess the behaviour of other objects where you will 
run into trouble. In other words, if you attempt to compensate for a release or 
retain elsewhere in your code (or even worse, in code you're using that isn't 
yours, like a framework class). That's not following the rules. In such a case, 
the code analyser will flag a potential memory management error. That's a great 
tool for learning how to write correct code in this respect.

> You mentioned memory tracing tools. I'm familiar with Instruments, but I 
> wasn't aware you could use it
> to trace individual variables. Did you have a particular tool in mind?


I believe the 'allocation' tool can do this, though I rarely use it so my 
memory may be faulty. Or it might be the 'leaks' tool.

--Graham


___

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

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

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

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