Does NSPrintOperation retain the NSWindow passed in runOperationModalForWindow

2009-08-13 Thread Renzil D'Souza
Hi,

I'm using an NSPrintOperation to print an image which I display in a
temporary window. I also use setCanSpawnSeparateThread as YES, so my
NSPrintOperation is running in a separate thread. The issue is, I've
allocated a temp. window before calling runOperationModalForWindow and I
don't know when should I release it. If NSPrintOperation retains this
window, then I should be able to free my window in my main thread and I hope
NSPrintOperation releases it. On the other hand, if NSPrintOperation doesn't
retain it, perhaps I can release this window in the 'didRunSelector' method.
Could you let me know what exactly does
NSPrintOperation:runOperationModalForWindow do with the window?

Also, is there a way to keep track of memory management while developing in
Objective-C? Most of the time, I'm very confused if I should release
something, or if it will be autoreleased. Maybe you could suggest a good
read that could clarify the usage.

Thanks,
Renzil D'Souza
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Cocoa-dev Digest, Vol 6, Issue 1146

2009-08-13 Thread Steve



Sent from my iPod

On 12 Aug 2009, at 20:04, cocoa-dev-requ...@lists.apple.com wrote:


Send Cocoa-dev mailing list submissions to
   cocoa-dev@lists.apple.com

To subscribe or unsubscribe via the World Wide Web, visit
   http://lists.apple.com/mailman/listinfo/cocoa-dev
or, via email, send a message with subject or body 'help' to
   cocoa-dev-requ...@lists.apple.com

You can reach the person managing the list at
   cocoa-dev-ow...@lists.apple.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cocoa-dev digest..."


Today's Topics:

  1. Releasing ivars in -didTurnIntoFault.  Should set to nil?
 (Jerry Krinock)
  2. Re: Adding more and more key/value observers is much too slow
 -workaround needed. (Chris Kane)
  3. Re: Adding more and more key/value observers is much too slow
 -workaround needed. (Chris Kane)
  4. Creating new managed object on 10.4 problem (Colin Cornaby)


--

Message: 1
Date: Wed, 12 Aug 2009 11:41:05 -0700
From: Jerry Krinock 
Subject: Releasing ivars in -didTurnIntoFault.  Should set to nil?
To: Cocoa Developers 
Message-ID: <71b5d880-88f4-4764-be99-a896a160c...@ieee.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

I release a "regular" instance variable in my managed object's -
didTurnIntoFault, and discovered that this was causing a crash
sometime after an undo.  In searching code on the internet I see that
others have reported such crashes.  I solved the problem by setting
the instance variable to nil:

- (void)didTurnIntoFault {
[childrenTemp release] ; childrenTemp = nil ;

[super didTurnIntoFault] ;
}

Now I understand that if nilling an instance variable after releasing
it is done in -dealloc, it is papering over other memory management
problems and is therefore bad programming practice.  But I believe
that this practice is OK in -didTurnIntoFault because, particularly
when Undo is involved, -didTurnIntoFault may be invoked more than once
on an object.  Therefore nilling after releasing in -didTurnIntoFault
is recommended.

Does anyone disagree?

Sincerely,

Jerry Krinock




--

Message: 2
Date: Wed, 12 Aug 2009 11:44:52 -0700
From: Chris Kane 
Subject: Re: Adding more and more key/value observers is much too slow
   -workaround needed.
To: Andy Lee 
Cc: "Cocoa-Dev \(Apple\)" 
Message-ID: 
Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes

On Aug 12, 2009, at 11:15 AM, Andy Lee wrote:


On Aug 12, 2009, at 11:37 AM, Christopher Kane wrote:

Don't pass the observer as the context: argument; pretty much
anything else is better.


Out of curiosity -- why would this affect performance and why is
this a bad idea (other than performance)?  Isn't the context:
treated as an opaque pointer by KVO?

--Andy



Well, as anyone can see from sampling the test program, a lot of time
is being spent in hash table management, and as I can tell through
experience, there are a lot of probe collisions happening.  You are
adding many observers into the KVO subsystem, and perhaps KVO is
keeping hash tables of these registrations.

   [modelObject addObserver:observer
 forKeyPath:@"title"
options:NSKeyValueObservingOptionNew |
NSKeyValueObservingOptionOld
context:observer];

Now here is where we enter the realm of the hypothetical.  Suppose
that the hashing is based on some combination of the observer, key
path, options, and context, which would be reasonable.  Suppose (and I
checked and this isn't the case, but this is easy to understand), that
the hash code computation goes something like this:

NSUInteger computeHash(...args...) {
return (NSUInteger)((uintptr_t)observer - (uintptr_t)context +
[keyPath hash] - (uintptr_t)options);
}

Now, the keyPath and the options are the same for every registration,
so they aren't contributing anything [in the test program] to make the
hash codes for each registration different.  If the observer and
context are the same, obviously in my contrived example, they are
cancelling each other out.  Thus my -hash would always return the same
value for all the registrations, which is terrible for hash table
performance.

Now I can see that what is going on is not actually full degenerate
linear probing, so the interaction between observer and context must
be more subtle in the computation of any hash code.  How did I know
that context being the observer was the issue?  Try it!  Just changing
it to NULL makes an enormous difference.  So there must be some sort
of interaction there.  In this contrived example, the observers and
modelObjects are likely to be fairly linearly allocated from out of
the heap, and probably all pretty close together, which might be one
effect, and so the bit pattern of the "contexts", which can only be
used as a raw pointer/integer value in any hash code computation,
wo

Re: Releasing ivars in -didTurnIntoFault. Should set to nil?

2009-08-13 Thread Georg C. Brückmann

Quincey –

In practice, the delegate is often -- independently of its role as  
delegate -- the *owner* of the referencing object (e.g. a window  
controller that is a delegate of a table view loaded from a nib file  
is the owner of the nib file's contents, including, directly or  
indirectly, the table view). However, in that case, there's no  
reason why the owner would relinquish ownership of the owned object  
during a delegate method.


Yes, those are the cases I was referring to.


Unless I'm missing something obvious.



Consider NSURLConnection’s -connectionDidFinishLoading: delegate method:

- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
// Do stuff
[myReferenceToTheConnection release];
myReferenceToTheConnection = nil;
}

Now, in the case of NSURLConnection there’s no need to ensure the  
connection object remains valid until the current autorelease pool  
gets drained (aka at the end of the current run loop cycle). But one  
doesn’t always know how a specific class is implemented, and in that  
case autoreleasing can help you prevent malloc errors.


I admit these are probably edge cases, but I’ve stumpled upon them. So  
while you may consider this overly cautious, writing such a macro  
takes about ten seconds – time that is easily saved when using the  
macro as it saves you one line of code each time you use it.


– 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


NSArrayController - compound values vs Select Inserted Objects

2009-08-13 Thread Jonathan del Strother
Heya,
I'm struggling a bit with an NSArrayController with content bound to
NSUserDefaultsController.

The NSArrayController manages dictionaries, and so it appears that I
need to select 'Handles Content as Compound Value'.  Without this,
changes made to the array through an NSTableView don't seem to persist
(for reasons slightly beyond me).

However, I'd like it to auto-select newly added items.  I've ticked
'Select Inserted Objects', but it has no effect.  When I untick the
Compound Value checkbox, 'Select Inserted Objects' starts working
again.

Is this a bug, or am I misunderstanding something somewhere?

-Jonathan
___

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

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

2009-08-13 Thread glenn andreas


On Aug 12, 2009, at 9:15 PM, DKJ wrote:

I've got a UITableView where the colour of the row text can change  
depending on its place in the table. For example, a row may change  
colour if it's moved from the bottom to the top of the table; and  
sometimes its colour may change if another row is deleted or inserted.


The problem is that the text colour is not updated until the table  
reloads its data. So (e.g.) if I move a row from the bottom to the  
top, its colour doesn't change immediately.


I'd like the text colours to be updated when the table leaves edit  
mode. But according to the docs, I can't call reloadData in the  
tableview controller's commitEditingStyle or moveRowAtIndexPath  
methods. (I tried doing it anyway, and got into trouble.)


Is there any way I can get the table to update as soon as the user  
presses the Done button? Or even better, as soon as the row deletion  
or move is completed?




You're using a sledge hammer (reloadData) when you need a small  
screwdriver.


When you are told of the row moving, you can access the cell used to  
draw that row (cellForIndexPath:) and then just adjust the color  
accordingly.  If you need to adjust other cells in that section, you  
can just loop through them, calling cellForIndexPath: for each one you  
want to adjust - if it is offscreen, it will return nil, so you can  
skip it.


This is also a good way to handle things like having a check mark  
selection... (change the accessoryType of the selected row, go through  
and remove the check mark from the previous one).



Glenn Andreas  gandr...@gandreas.com
  wicked fun!
quadrium2 | build, mutate, evolve, animate  | images, textures,  
fractals, art



___

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

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

2009-08-13 Thread Brian Slick


On Aug 13, 2009, at 8:31 AM, glenn andreas wrote:

You're using a sledge hammer (reloadData) when you need a small  
screwdriver.


From UITableView.h:

- (void)reloadData; // reloads everything from  
scratch. redisplays visible rows. --> because we only keep info about  
visible rows, this is cheap.<-- will adjust offset if table shrinks


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

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


Re: UITableView updating problem

2009-08-13 Thread glenn andreas


On Aug 13, 2009, at 8:44 AM, Brian Slick wrote:



On Aug 13, 2009, at 8:31 AM, glenn andreas wrote:

You're using a sledge hammer (reloadData) when you need a small  
screwdriver.


From UITableView.h:

- (void)reloadData; // reloads everything from  
scratch. redisplays visible rows. --> because we only keep info  
about visible rows, this is cheap.<-- will adjust offset if table  
shrinks



Watch this year's WWDC session on UITableViews - that's where the  
"sledgehammer" comment actually comes from.


reloadData is cheap, but it is still a sledgehammer approach (since it  
tears everything down and rebuilds everything).  Tweaking a setting of  
an existing view is far more surgical.





Glenn Andreas  gandr...@gandreas.com
  wicked fun!
Mad, Bad, and Dangerous to Know

___

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

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


Trouble with NSColor

2009-08-13 Thread Daniel Furrer
I'm trying to get the RGB components of a system color. Here's what I've
been trying:

NSColor* foo = [[NSColor controlColor] colorUsingColorSpaceName:
@"NSCalibratedRGBColorSpace"];
NSLog(@"%f, %f, %f", [foo redComponent], [foo blueComponent], [foo
greenComponent]);

but all I ever get is 0.0, 0.0, 0.0
Also [foo numberOfComponents] seems to be 0. (For [NSColor blueColor] it's
working fine however).
What am I doing wrong?

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

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


Re: Trouble with NSColor

2009-08-13 Thread Alastair Houghton

On 13 Aug 2009, at 17:24, Daniel Furrer wrote:

I'm trying to get the RGB components of a system color. Here's what  
I've

been trying:

   NSColor* foo = [[NSColor controlColor] colorUsingColorSpaceName:
@"NSCalibratedRGBColorSpace"];
   NSLog(@"%f, %f, %f", [foo redComponent], [foo blueComponent], [foo
greenComponent]);

but all I ever get is 0.0, 0.0, 0.0
Also [foo numberOfComponents] seems to be 0. (For [NSColor  
blueColor] it's

working fine however).
What am I doing wrong?


Is "foo" itself nil?

Kind regards,

Alastair.

--
http://alastairs-place.net



___

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

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

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

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


Re: [iPhone 3.0] -- UIImage imageFromContentsOfFile and animations

2009-08-13 Thread David Duncan

On Aug 12, 2009, at 11:03 PM, John Michael Zorko wrote:

However, though replacing imageNamed with imageFromContentsOfFile  
works wherever I set a UIImageView's image property, doing so to  
load the PNG images into my animation array results in the animation  
being invisible on the device, though it works in the simulator.   
Here's my code:


Try lengthening your animation time. I would bet that your  
encountering a bug where the animation starts before all of the images  
are ready and thus it skips some part of the animation. If your  
animation is particular short, you just get completely skipped.


I've tried various combinations of the inDirectory parameter, to no  
avail -- it plays on the sim, not on the device.  However, using  
UIImage imageNamed works on the device, but uses up a lot of memory  
that causes my glitch.



The memory usage is the same in both cases, the only difference is  
that +imageNamed: has already decompressed the image before it  
returns. The image still must be decompressed in either case for the  
animation to actually occur. When you use +imageNamed: your animation  
likes works because the images are already ready.


But if your getting memory glitches, it sounds like your images are  
awfully large...

--
David Duncan
Apple DTS Animation and Printing

___

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

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

2009-08-13 Thread David Duncan

On Aug 13, 2009, at 9:24 AM, Daniel Furrer wrote:


I'm trying to get the RGB components of a system color.



Which system color? Many system colors are patterns and thus do not  
have real RGB values.

--
David Duncan
Apple DTS Animation and Printing

___

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

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

2009-08-13 Thread Randall Meadows

On Aug 13, 2009, at 10:33 AM, Daniel Furrer wrote:


You are right. (But why?)


When/where are you trying to do this?  I tried running this in main.m,  
before calling NSApplicationMain(), and got nil returned from  
+controlColor.


I moved it into an -awakeFromNib call, and +controlColor returned a  
valid object.  That leads me to believe that some connection needs to  
be hooked up for this to work, and at the time you're calling it (as I  
did in main.m) that this connection is not configured yet.  I'll leave  
it to smarter gurus here to describe what that "connection" is.   
WindowServer?  AppKit?


On Thu, Aug 13, 2009 at 6:29 PM, Randall Meadows pc.com> wrote:

On Aug 13, 2009, at 10:24 AM, Daniel Furrer wrote:

I'm trying to get the RGB components of a system color. Here's what  
I've

been trying:

  NSColor* foo = [[NSColor controlColor] colorUsingColorSpaceName:
@"NSCalibratedRGBColorSpace"];
  NSLog(@"%f, %f, %f", [foo redComponent], [foo blueComponent], [foo
greenComponent]);

but all I ever get is 0.0, 0.0, 0.0
Also [foo numberOfComponents] seems to be 0. (For [NSColor  
blueColor] it's

working fine however).
What am I doing wrong?

Sounds like foo is nil.  Have you verified that it is a bona fide  
object in the debugger?





--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?




___

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

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

2009-08-13 Thread Greg Reichow

Long time lurker, first time to post.

I have a iPhone 3.0 application that is using core data in an  
NSOperation to perform some updates.  It is using it's own  
NSManagedObjectContext connected to a common (with the main thread)  
persistent store coordinator.  Everything works great until the  
NSOperation ends and is releasing the managed object context.  I get  
an EXC_BAD_ACCESS on the operation thread.  Here is the trace:


#0  0x91a3c688 in objc_msgSend
#1	0x0036c854 in -[_PFManagedObjectReferenceQueue  
_processReferenceQueue:]
#2	0x003a7c40 in -[NSManagedObjectContext(_NSInternalAdditions)  
_dispose:]

#3  0x0040c92d in _deallocateContextBackgroundThread
#4  0x0035f41c in minion_duties2
#5  0x96777155 in _pthread_start
#6  0x96777012 in thread_start

At first I had assumed a simple memory management problem.  The MOC is  
alloc'd by method call from the main method and released in the  
dealloc method of the operation.  New objects are being inserted into  
this MOC & saved (and the main thread MOC being merged) before the  
dealloc.  One clue is that if no new objects are added, it does not  
cause the crash above.  So, my guess is that something bad is  
happening to the managed objects and they are being over-released?   
During the creation of managed objects, at certain intervals a local  
autorelease pool is created, then objects saved, then the pool is  
drained.  Yet, even if the managed objects are released, it does not  
seem that the context should crash on it's own release?


I have spent some time searching on google and found another case of  
this occurring.  Yet, the solution was to set the MOC to retain the  
managed objects.  This did not work in my case.  I have also tried  
forcing the MOC to processPendingChanges and also reseting prior to  
the release to see if that would help, no luck.  Of course,  
eliminating the release of the MOC in the dealloc method did keep it  
from crashing (and everything works great), but this then becomes a  
leak.


Anyone have a similar problem or an idea on how to further figure this  
out?


Here is a cut of the code showing the relevant sections.

.h

#import 
@interface GRUpdateDatabaseOperation : NSOperation
{
id  delegate;
NSManagedObjectContext  *managedObjectContext;
NSPersistentStoreCoordinator
*persistentStoreCoordinator;
}

@property (nonatomic, assign) id delegate;
@property (nonatomic, readonly) NSManagedObjectContext  
*managedObjectContext;
@property (nonatomic, retain) NSPersistentStoreCoordinator  
*persistentStoreCoordinator;


- (id)initWithDelegate:(id)aDelegate persistentStoreCoordinator: 
(NSPersistentStoreCoordinator *)aPersistentStoreCoordinator;


@end

.m
#import "GRUpdateDatabaseOperation.h"
@implementation GRUpdateDatabaseOperation

@synthesize delegate;
@synthesize persistentStoreCoordinator;

- (id)initWithDelegate:(id)aDelegate persistentStoreCoordinator: 
(NSPersistentStoreCoordinator *)aPersistentStoreCoordinator

{
if (!(self = [super init])) {
return nil;
}
self.delegate:aDelegate;
self.persistentStoreCoordinator = aPersistentStoreCoordinator;
return self;
}

- (void) dealloc
{
[managedObjectContext release]; // problem with crash is here!
[persistentStoreCoordinator release];
[super dealloc];
}

#pragma mark Core Data Stuff

- (NSManagedObjectContext *) managedObjectContext {

if (managedObjectContext != nil) {
return managedObjectContext;
}

NSPersistentStoreCoordinator *coordinator =  
self.persistentStoreCoordinator;

if (coordinator != nil) {
managedObjectContext = [[NSManagedObjectContext alloc] init];
[managedObjectContext setPersistentStoreCoordinator:  
coordinator];
		[managedObjectContext setUndoManager:nil]; // speeds up performance  
for no undo

}

return managedObjectContext;
}

- (void)saveAction:(id)sender {

NSError *error;
if (![[self managedObjectContext] save:&error]) {
// Handle error
NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
exit(-1);  // Fail
}
}

-(void) contextDidSave:(NSNotification *)notification
{   
if ([self.delegate respondsToSelector:@selector(mergeChanges:)]) {
DLog(@"Sending off mergeChanges to main thread");
		[self.delegate performSelectorOnMainThread:@selector(mergeChanges:)  
withObject:notification waitUntilDone:YES];

}
}

#pragma mark Main

- (void)main
{   
	[[NSNotificationCenter defaultCenter] addObserver:self  
selector:@selector(contextDidSave:)  
name:NSManagedObjectContextDidSaveNotification  
object:self.managedObjectContext];


 BUNCH OF CODE HERE TO CREATE CREATE AND INSERT NEW OBJECTS INTO  
MOC ...


[self 

Re: Trouble with NSColor

2009-08-13 Thread Sean McBride
On 8/13/09 6:24 PM, Daniel Furrer said:

>I'm trying to get the RGB components of a system color. Here's what I've
>been trying:
>
>NSColor* foo = [[NSColor controlColor] colorUsingColorSpaceName:
>@"NSCalibratedRGBColorSpace"];
>NSLog(@"%f, %f, %f", [foo redComponent], [foo blueComponent], [foo
>greenComponent]);
>
>but all I ever get is 0.0, 0.0, 0.0
>Also [foo numberOfComponents] seems to be 0. (For [NSColor blueColor] it's
>working fine however).
>What am I doing wrong?

Did you read the docs for 'redComponent'?

"This method works only with objects representing colors in the
NSCalibratedRGBColorSpace or NSDeviceRGBColorSpace color space"

Use colorUsingColorSpaceName:NSCalibratedRGBColorSpace to convert.

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

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


Re: Core Data Crash on MOC Release

2009-08-13 Thread Volker in Lists

Hi,

do you have any observers or such on objects inside the moc (speak on  
entities)? I had a hard to trace down crash similar to yours and in my  
case I just needed some cleanup work on -didTurnToFault for the  
entity. Are there relationships established and not "destroyed" again  
completely. Again -didTurnToFault may be a good place to clean up some  
stuff.


As a side note:

Why don't you call
self.persistentStoreCoordinator = nil;
instead of releasing the persistentStoreCoordinator ?

self.delegate = nil; could also be useful - I had bad experiences by  
the delegate retaining my object... and setting it to nil helped there  
as well.


Cheers,
Volker

Am 13.08.2009 um 16:51 schrieb Greg Reichow:


Long time lurker, first time to post.

I have a iPhone 3.0 application that is using core data in an  
NSOperation to perform some updates.  It is using it's own  
NSManagedObjectContext connected to a common (with the main thread)  
persistent store coordinator.  Everything works great until the  
NSOperation ends and is releasing the managed object context.  I get  
an EXC_BAD_ACCESS on the operation thread.  Here is the trace:


#0  0x91a3c688 in objc_msgSend
#1	0x0036c854 in -[_PFManagedObjectReferenceQueue  
_processReferenceQueue:]
#2	0x003a7c40 in -[NSManagedObjectContext(_NSInternalAdditions)  
_dispose:]

#3  0x0040c92d in _deallocateContextBackgroundThread
#4  0x0035f41c in minion_duties2
#5  0x96777155 in _pthread_start
#6  0x96777012 in thread_start

At first I had assumed a simple memory management problem.  The MOC  
is alloc'd by method call from the main method and released in the  
dealloc method of the operation.  New objects are being inserted  
into this MOC & saved (and the main thread MOC being merged) before  
the dealloc.  One clue is that if no new objects are added, it does  
not cause the crash above.  So, my guess is that something bad is  
happening to the managed objects and they are being over-released?   
During the creation of managed objects, at certain intervals a local  
autorelease pool is created, then objects saved, then the pool is  
drained.  Yet, even if the managed objects are released, it does not  
seem that the context should crash on it's own release?


I have spent some time searching on google and found another case of  
this occurring.  Yet, the solution was to set the MOC to retain the  
managed objects.  This did not work in my case.  I have also tried  
forcing the MOC to processPendingChanges and also reseting prior to  
the release to see if that would help, no luck.  Of course,  
eliminating the release of the MOC in the dealloc method did keep it  
from crashing (and everything works great), but this then becomes a  
leak.


Anyone have a similar problem or an idea on how to further figure  
this out?


Here is a cut of the code showing the relevant sections.

.h

#import 
@interface GRUpdateDatabaseOperation : NSOperation
{
id  delegate;
NSManagedObjectContext  *managedObjectContext;
NSPersistentStoreCoordinator
*persistentStoreCoordinator;
}

@property (nonatomic, assign) id delegate;
@property (nonatomic, readonly) NSManagedObjectContext  
*managedObjectContext;
@property (nonatomic, retain) NSPersistentStoreCoordinator  
*persistentStoreCoordinator;


- (id)initWithDelegate:(id)aDelegate persistentStoreCoordinator: 
(NSPersistentStoreCoordinator *)aPersistentStoreCoordinator;


@end

.m
#import "GRUpdateDatabaseOperation.h"
@implementation GRUpdateDatabaseOperation

@synthesize delegate;
@synthesize persistentStoreCoordinator;

- (id)initWithDelegate:(id)aDelegate persistentStoreCoordinator: 
(NSPersistentStoreCoordinator *)aPersistentStoreCoordinator

{
if (!(self = [super init])) {
return nil;
}
self.delegate:aDelegate;
self.persistentStoreCoordinator = aPersistentStoreCoordinator;
return self;
}

- (void) dealloc
{
[managedObjectContext release]; // problem with crash is here!
[persistentStoreCoordinator release];
[super dealloc];
}

#pragma mark Core Data Stuff

- (NSManagedObjectContext *) managedObjectContext {

   if (managedObjectContext != nil) {
   return managedObjectContext;
   }

   NSPersistentStoreCoordinator *coordinator =  
self.persistentStoreCoordinator;

   if (coordinator != nil) {
   managedObjectContext = [[NSManagedObjectContext alloc] init];
   [managedObjectContext setPersistentStoreCoordinator:  
coordinator];
		[managedObjectContext setUndoManager:nil]; // speeds up  
performance for no undo

   }

   return managedObjectContext;
}

- (void)saveAction:(id)sender {

   NSError *error;
   if (![[self managedObjectContext] save:&error]) {
// Handle error
NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
 

Re: Releasing ivars in -didTurnIntoFault. Should set to nil?

2009-08-13 Thread Quincey Morris

On Aug 13, 2009, at 03:45, Georg C. Brückmann wrote:

Consider NSURLConnection’s -connectionDidFinishLoading: delegate  
method:


- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
// Do stuff
[myReferenceToTheConnection release];
myReferenceToTheConnection = nil;
}

Now, in the case of NSURLConnection there’s no need to ensure the  
connection object remains valid until the current autorelease pool  
gets drained (aka at the end of the current run loop cycle). But one  
doesn’t always know how a specific class is implemented, and in that  
case autoreleasing can help you prevent malloc errors.


I admit these are probably edge cases, but I’ve stumpled upon them.  
So while you may consider this overly cautious, writing such a macro  
takes about ten seconds – time that is easily saved when using the  
macro as it saves you one line of code each time you use it.


Pragmatically, autoreleasing 'myReferenceToTheConnection' might be a  
reasonable solution to a (potential) problem.


In fact, relinquishing ownership of the connection during this method  
is simply a bug. If you're its owner, you're responsible for  
preventing it from being deallocated while it's still alive -- and  
it's still alive.


In this case, you're pretty sure that autoreleasing it keeps it from  
being deallocated long enough for its lifetime to end, but that's not  
a safe general assumption. What if the object you're releasing has a  
pending error message it's going to display after a timer expires  
(i.e. after the autorelease pool has been drained)?


So, in such cases, you have an object lifetime issue that must be  
solved on a case by case basis. Sometimes -- maybe most times --  
autoreleasing might be an answer, but I don't think that recommending  
the use of 'autorelease' over 'release' *as a routine safety  
precaution* is a viable position to take.



___

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

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

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

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


Re: Core Data Crash on MOC Release

2009-08-13 Thread Kyle Sluder
On Thu, Aug 13, 2009 at 10:03 AM, Volker in Lists wrote:
> Why don't you call
> self.persistentStoreCoordinator = nil;
> instead of releasing the persistentStoreCoordinator ?

-dealloc should always access instance variables directly; it should
not call accessor methods.  Currently this is impossible to do with
synthesized instance variables, but that is considered a bug.

--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: Trouble with NSColor

2009-08-13 Thread Daniel Furrer
> When/where are you trying to do this?  I tried running this in main.m,
> before calling NSApplicationMain(), and got nil returned from +controlColor.
>
> I moved it into an -awakeFromNib call, and +controlColor returned a valid
> object.  That leads me to believe that some connection needs to be hooked up
> for this to work, and at the time you're calling it (as I did in main.m)
> that this connection is not configured yet.  I'll leave it to smarter gurus
> here to describe what that "connection" is.  WindowServer?  AppKit?
>

I was thinking about this, too since I actually roll my own main and event
loop (don''t ask why :)) but my [NSColor controlColor] seems to return a
sensible value!
___

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

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

2009-08-13 Thread Daniel Furrer
> Is "foo" itself nil?
>

No, foo is fine! =)
___

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

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

2009-08-13 Thread Daniel Furrer
> Which system color? Many system colors are patterns and thus do not have
> real RGB values.
>

In this case I tried it with [NSColor controlColor]. It appears to be a
regular color in the color panel.
___

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

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

2009-08-13 Thread Daniel Furrer
On Thu, Aug 13, 2009 at 6:51 PM, Sean McBride wrote:

> Did you read the docs for 'redComponent'?
>
> "This method works only with objects representing colors in the
> NSCalibratedRGBColorSpace or NSDeviceRGBColorSpace color space"
>
> Use colorUsingColorSpaceName:NSCalibratedRGBColorSpace to convert.


I believe that's what I'm doing in my first line of code, no?
___

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

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

2009-08-13 Thread Sean McBride
On 8/13/09 7:29 PM, Daniel Furrer said:

>> Did you read the docs for 'redComponent'?
>>
>> "This method works only with objects representing colors in the
>> NSCalibratedRGBColorSpace or NSDeviceRGBColorSpace color space"
>>
>> Use colorUsingColorSpaceName:NSCalibratedRGBColorSpace to convert.
>
>
>I believe that's what I'm doing in my first line of code, no?

Ack!  I need an eye replacement apparently. :)

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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


Arbitrary length ints from NSData

2009-08-13 Thread Chase Meadors

Hi All,

I'm having a problem reading numbers from some raw data I need to  
read. The data encodes numbers in little-endian format. I am defining  
a category on NSData to accomplish this.


- (NSNumber *)interpretAsSingleNumber {

NSMutableString *hexString = [NSMutableString string];

unsigned char *bytes = [self bytes];

for (int i = [self length] - 1;  i > -1;  i --) {

[hexString appendFormat:@"%02X", bytes[i]];

}

[hexString insertString:@"0x" atIndex:0];

unsigned int result;
[[NSScanner scannerWithString:hexString] scanHexInt:&result];

return [NSNumber numberWithInt:result];

}

The problem here is that NSScanner can only scan 32-bit integers. The  
numbers in the data I'm trying to read can be either 8 or 16 bits. I'm  
given the information as to exactly what range in the data represents  
a certain number, so I could see whether it is one or two bytes long,  
but how can I accomplish getting an int from this data that IS the  
length of the data.


In other words, I might read one piece of data that is one byte: .  
I would want this to be read as -2. However, the current method would  
make the string "0xFE", then scan it to 0x00FE, which is  
completely different.


I might then read a piece of data that is two bytes: <01 80> (little  
endian). This needs to be read as -32,767. However, the current method  
gives 0x8001.


Any hints as to how I might accomplish this? 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/archive%40mail-archive.com

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


Re: Trouble with NSColor

2009-08-13 Thread Sherm Pendley
On Thu, Aug 13, 2009 at 1:29 PM, Daniel Furrer wrote:
> On Thu, Aug 13, 2009 at 6:51 PM, Sean McBride wrote:
>
>> Did you read the docs for 'redComponent'?
>>
>> "This method works only with objects representing colors in the
>> NSCalibratedRGBColorSpace or NSDeviceRGBColorSpace color space"
>>
>> Use colorUsingColorSpaceName:NSCalibratedRGBColorSpace to convert.
>
> I believe that's what I'm doing in my first line of code, no?

Not quite - in your code, you're using NSCalibratedRGBColorSpace as a
literal string value, not as the name of a global variable.

sherm--

-- 
Cocoa programming in Perl: http://camelbones.sourceforge.net
___

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

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

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

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


re: Core Data Crash on MOC Release

2009-08-13 Thread Ben Trumbull

I have a iPhone 3.0 application that is using core data in an
NSOperation to perform some updates.  It is using it's own
NSManagedObjectContext connected to a common (with the main thread)
persistent store coordinator.  Everything works great until the
NSOperation ends and is releasing the managed object context.  I get
an EXC_BAD_ACCESS on the operation thread.  Here is the trace:

#0  0x91a3c688 in objc_msgSend
#1  0x0036c854 in -[_PFManagedObjectReferenceQueue
_processReferenceQueue:]
#2  0x003a7c40 in -[NSManagedObjectContext(_NSInternalAdditions)
_dispose:]
#3  0x0040c92d in _deallocateContextBackgroundThread
#4  0x0035f41c in minion_duties2
#5  0x96777155 in _pthread_start
#6  0x96777012 in thread_start


I've seen this happen for two reasons.  First, the MOC was created on  
a different thread and passed off to an operation to run on another  
thread without any locking.  This can catch people, since  
NSOperation's init method runs on the originating thread that  
allocates it, but main runs on the actual NSOperation thread.  MOCs  
created on the main thread are assumed to be special, with additional  
integration into the application's main event loop.  It's important  
not to pass main thread MOCs to background threads.  We discourage  
that generally (MOCs should be used by the thread that creates them),  
but it is possible for the background thread to call -lock to assume  
ownership.


The second more prosaic issue is simply an overreleased  
NSManagedObject.  Instruments ObjectAlloc tool should be able to help  
you.


- Ben

___

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

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

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

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


Re: Trouble with NSColor

2009-08-13 Thread Andy Lee

On Aug 13, 2009, at 1:27 PM, Daniel Furrer wrote:

Is "foo" itself nil?



No, foo is fine! =)


Are you sure?  I stuck your code in a button's action method and when  
I click the button foo is nil.  I tried both your exact code and the  
correction Sherm pointed out.


I think David Duncan has the answer:

On Aug 13, 2009, at 12:41 PM, David Duncan wrote:

On Aug 13, 2009, at 9:24 AM, Daniel Furrer wrote:


I'm trying to get the RGB components of a system color.



Which system color? Many system colors are patterns and thus do not  
have real RGB values.


The doc for +controlColor says:
The system color used for the flat surfaces of a control. By  
default, the control color is a pattern color that will draw the  
ruled lines for the window background, which is the same as returned  
by windowBackgroundColor.


If you use controlColor assuming that it is a solid, you may have an  
incorrect appearance. You should use lightGrayColor in its place.





--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: Arbitrary length ints from NSData

2009-08-13 Thread Quincey Morris

On Aug 13, 2009, at 10:34, Chase Meadors wrote:

In other words, I might read one piece of data that is one byte:  
. I would want this to be read as -2. However, the current  
method would make the string "0xFE", then scan it to 0x00FE,  
which is completely different.


I might then read a piece of data that is two bytes: <01 80> (little  
endian). This needs to be read as -32,767. However, the current  
method gives 0x8001.


This is more of a C question. You could try something like:


[[NSScanner scannerWithString:hexString] scanHexInt:&result];

if ([self bytes] == 1)
result = (int8_t) result;
else if [self bytes] == 2)
result = (int16_t) result;

return [NSNumber numberWithInt:result];


IOW, you can use any C trick to sign-extend the shorter value.

P.S. Using NSScanner seems like a very long way round. Why not use a  
multiply-by-256-and-add technique on the raw bytes? Then all you need  
to do is to treat the first (i.e. the last) byte as signed, and all  
the other bytes as unsigned, and your sign-extension problem is solved  
too.



___

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

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

2009-08-13 Thread Chase Meadors


On Aug 13, 2009, at 1:17 PM, Quincey Morris wrote:


On Aug 13, 2009, at 10:34, Chase Meadors wrote:

In other words, I might read one piece of data that is one byte:  
. I would want this to be read as -2. However, the current  
method would make the string "0xFE", then scan it to 0x00FE,  
which is completely different.


I might then read a piece of data that is two bytes: <01 80>  
(little endian). This needs to be read as -32,767. However, the  
current method gives 0x8001.


This is more of a C question. You could try something like:


[[NSScanner scannerWithString:hexString] scanHexInt:&result];

if ([self bytes] == 1)
result = (int8_t) result;
else if [self bytes] == 2)
result = (int16_t) result;

return [NSNumber numberWithInt:result];


Oh, I didn't realize this would work. Thank you.



IOW, you can use any C trick to sign-extend the shorter value.

P.S. Using NSScanner seems like a very long way round. Why not use a  
multiply-by-256-and-add technique on the raw bytes? Then all you  
need to do is to treat the first (i.e. the last) byte as signed, and  
all the other bytes as unsigned, and your sign-extension problem is  
solved too.





I'm a hobby programmer, and my first experience with programming was  
the currency converter w/ interface builder example. As such, I guess  
I'm learning "from the top down." I'm not very familiar with straight  
C as I am with Objective-C. I'm afraid you'll have to explain the  
multiply-by-256-and-add technique.



___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/c.ed.mead%40gmail.com

This email sent to c.ed.m...@gmail.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: Arbitrary length ints from NSData

2009-08-13 Thread Alastair Houghton

On 13 Aug 2009, at 19:25, Chase Meadors wrote:

I'm a hobby programmer, and my first experience with programming was  
the currency converter w/ interface builder example. As such, I  
guess I'm learning "from the top down." I'm not very familiar with  
straight C as I am with Objective-C. I'm afraid you'll have to  
explain the multiply-by-256-and-add technique.


FWIW, I don't think that's the best way either.  Why not just use the  
OSRead*() functions from ?  For instance,


  #import 

  ...

  const uint8_t *bytes = [myData bytes];
  const uint8_t *ptr = bytes;

  // Read a 32-bit signed int
  int32_t fourBytes = OSReadLittleInt32 (ptr, 0);
  ptr += 4;

  // Read a 16-bit signed int
  int16_t twoBytes = OSReadLittleInt16 (ptr, 0);
  ptr += 2;

  // Read an 8-bit signed int
  int8_t oneByte = (int8_t)*ptr++;

You *could* use offsets instead of pointers if you want---e.g.

  uintptr_t offset = 0;

  // Read a 32-bit signed int
  int32_t fourBytes = OSReadLittleInt32 (bytes, offset);
  offset += 4;

  // Read a 16-bit signed int
  int16_t twoBytes = OSReadLittleInt16 (bytes, offset);
  offset += 2;

  // Read an 8-bit signed int
  int8_t oneByte = (int8_t)bytes[offset++];

This way, you don't need to worry about endianness and there's no need  
for any shifting (which is the more sensible alternative to  
multiplications by 256).


Kind regards,

Alastair.

--
http://alastairs-place.net



___

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

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

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

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


Re: Arbitrary length ints from NSData

2009-08-13 Thread Quincey Morris

On Aug 13, 2009, at 11:25, Chase Meadors wrote:

I'm afraid you'll have to explain the multiply-by-256-and-add  
technique.


I mean something like this (untested):


unsigned char *bytes = [self bytes];
int byteIndex = [self length];
int result = 0;
BOOL firstByte = YES;

while (byteIndex--) {
if (firstByte) {
			result = (signed char *) bytes [byteIndex]; // signed the first  
time

firstByte = NO;
}
else
			result = result * 0x100 + bytes [byteIndex]; // unsigned the rest  
of the times

}

return [NSNumber numberWithInt: result];


BTW, I didn't notice that you'd originally declared 'result' as  
unsigned int, so my first suggestion wouldn't have have worked unless  
you also changed 'result' to a signed int.


P.S. I see Alastair gave you a mostly better answer already. However,  
I'll point out that if you have any *3-byte* numbers (I see "arbitrary  
length ints" in the subject line) you're not going to find an  
OSReadLittleInt24 to help you.



___

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

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


scroll view is now disabled after switching to snowleopard

2009-08-13 Thread Stephane Huaulme
this is an app with a couple of scrollviews, and after upgrading to  
snowleopard and recompiling, one of the 2 scrollviews is disabled.  
it's content is getting updated but it's grey'd out and i can't focus  
it.


when i compare that view using the inspector with the other almost  
identical view that does work, i can't find any difference that could  
explain the "disabling" of the second one.


any ideas?

___

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

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


[Meet]: Reminder LA CocoaHeads tonight 7:30pm

2009-08-13 Thread Rob Ross

Greetings LA CocoaHeads.

Tonight Niilo Tippler will be showing some graphic experiments
that he built in Flash - stuff that demonstrates some physics,
springing, gravity, etc. - and ported  over to the iPhone, explaining
how they work and the differences he found between the two platforms
in the process.



We meet at the offices of E! Entertainment at 7:30pm.

Our meeting location is

5750 Wilshire Blvd
Los Angeles, CA 90036.

Here's a google map of the location:

http://www.google.com/maps?f=q&hl=en&q=5750+Wilshire+Blvd,+Los+Angeles+CA+90036&ie=UTF8&z=15&om=1&iwloc=addr

Free street parking is available after 8pm - FEED THE METER UP TO 8PM
OR YOU MIGHT GET A TICKET!

I'd suggest trying Masselin Ave, which is one block East of Courtyard
Place.

We meet near the lobby of the West building at 5750 Wilshire Blvd, on
the West side of Courtyard Place. There are picknick tables in front
of the lobby and we'll gather there starting at 7:20pm. From there we
go inside and up to conference room 3A at around 7:45pm .

If you arrive late, please ask the building security personnel in the
lobby to direct you to the E! Security office, and they will be able
to contact the group in conference room 3A and send someone down to
meet you.

Rob
___

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

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


File's owner, outlets and methods

2009-08-13 Thread Michael de Haan

Hi all,
I wonder if I could get some clarity on this issue.
Hillegass asks, ( challenge chapter 12) to create a custom About Panel.
I have ( surprisingly) done this quite easily  :-)...but I am left  
with this one puzzle.


**Very** briefly, the set up is as follows.

AppController has an outlet (IBOutlet NSPanel *aboutWindow) and a  
method (-(IBAction) showPanel: (id) sender;)




"Custom" xib file;
File's owner  =  AppController.
File's owner (aboutWindow) outlet points to the NSPanel object in the  
xib.




"Main Menu" xib
AppController object to which the "About NewApplication" from the  
MainMenu is connected ( pointing to the method "showPanel").



My question is this.

The inspector of File's owner in the "Custom" xib shows, as expected  
an outlet ( which is connected) as well as the method "showPanel"  
which is *not* connected. In fact, I am unable to "connect" ( if that  
is the correct terminology) the "About NewApplication" to this, or to  
the File's owner (control-drag), but am able to do so to the  
AppController object in the mainMenu.xib


Is this just the way it is, or is there some good logical explanation  
for this that will help in my deeper understanding of cocoa?


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

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


Re: Releasing ivars in -didTurnIntoFault. Should set to nil?

2009-08-13 Thread Georg C. Brückmann
In fact, relinquishing ownership of the connection during this  
method is simply a bug. If you're its owner, you're responsible for  
preventing it from being deallocated while it's still alive -- and  
it's still alive.


In this case, you're pretty sure that autoreleasing it keeps it from  
being deallocated long enough for its lifetime to end, but that's  
not a safe general assumption. What if the object you're releasing  
has a pending error message it's going to display after a timer  
expires (i.e. after the autorelease pool has been drained)?


I think it’s a pretty sane assumption that the delegating *may* still  
access its reserved memory after the delegate method returns. If the  
delegating object has to execute further code in a future run loop  
cycle, then it’s the object’s responsibility to ensure it’s still  
alive. After all, it told its delegate that it had finished.
Also, I’d consider any implementation that doesn’t invalidate any  
pending timers when deallocating/finalizing  previously created flawed.


So, in such cases, you have an object lifetime issue that must be  
solved on a case by case basis. Sometimes -- maybe most times --  
autoreleasing might be an answer, but I don't think that  
recommending the use of 'autorelease' over 'release' *as a routine  
safety precaution* is a viable position to take.


Well, is there any disadvantage when autoreleasing? (I’m not talking  
about tight loops here – that’s another topic.) Generally speaking,  
releasing a delegating object, when it notifies its delegate that it’s  
finished, should be fine from the delegate’s point of view.


Also, I’m interested what method of reference releasing you’d  
recommend, because the timer issue mentioned above would be equally  
present when releasing instead of autoreleasing.


Note that I don’t want to persuade you, I just don’t see any  
disadvantage of autoreleasing while I do see a slight advantage.


– 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: NSPredicate & Editor questions

2009-08-13 Thread Peter Ammon


On Aug 12, 2009, at 3:20 PM, Dave DeLong wrote:

Thanks for the info!  I spent some time at NSCoder Night last night  
poking around with attempting to convert an NSPredicate into an  
NSCompoundPredicate using the TODParseKit and the BNF definition of  
NSPredicate grammar in the docs, then eventually gave up.  =)  (I  
figured there had to be an easier way, since this seems like a non- 
unreasonable thing to want to do)


Luckily, I was just pointed to the setObjectValue: approach on  
StackOverflow.com and have been trying to get that to work.


I've started building a test app to experiment with this.  Here's  
what I've got:


1.  Create a new Document-based Cocoa App.
2.  Add an IBOutlet to MyDocument called "predicateEditor"
3.  Drop an NSPredicateEditor into MyDocument.xib and connect it to  
File's Owner's predicateEditor outlet.
4.  Add a "[predicateEditor addRow:self];" message in MyDocument's  
windowControllerDidLoadNib: method
5.  In the dataOfType:... method, retrieve predicateEditor's  
objectValue, use NSKeyedArchiver to archive it, and return that as  
the data.
6.  In the readData:ofType:... method, unarchive the data as an  
NSPredicate and use predicateEditor's setObjectValue: method to  
restore it.


If I run this, create a predicate, and save it, then it saves nicely  
to a file. If I then try to open that file, I can NSLog and see that  
the predicate is getting unarchived properly, but the  
predicateEditor doesn't load it.  Is there anything I'm supposed to  
be doing besides setObjectValue:?  I haven't modified the  
predicateEditor at all, other than to make the nesting "Compound".


In document based apps, readData:ofType: is called before the nib is  
loaded.  So in your readData:ofType: method, the outlet to the  
NSPredicateEditor has not yet been populated, so that setObjectValue:  
goes to nil.


You can unarchive the predicate and store it in your MyDocument, and  
then push it to the NSPredicateEditor in windowControllerDidLoadNib:.   
Alternatively, if you're comfortable with bindings, you you can bind  
the NSPredicateEditor's object value to your document in IB, and then  
it will pick up the predicate when it's loaded.


Hope this helps,
-Peter
___

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

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

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

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


Re: File's owner, outlets and methods

2009-08-13 Thread Dave Carrigan


On Aug 13, 2009, at 1:32 PM, Michael de Haan wrote:

The inspector of File's owner in the "Custom" xib shows, as expected  
an outlet ( which is connected) as well as the method "showPanel"  
which is *not* connected. In fact, I am unable to "connect" ( if  
that is the correct terminology) the "About NewApplication" to this,  
or to the File's owner (control-drag), but am able to do so to the  
AppController object in the mainMenu.xib


I'm not 100% sure, but it seems like you're saying that you are trying  
to connect the About NewApplication menu item in MainMenu.xib to the  
Files Owner in Custom.xib?


If that is the case, you can't do that. All connections must be  
between objects and proxy objects within a single xib. The nib loading  
process only works on a single nib at a time and doesn't know anything  
about what might be in some other nib.


--
Dave Carrigan
d...@rudedog.org
Seattle, WA, USA



PGP.sig
Description: This is a digitally signed message part
___

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

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

Document file read, but -readFromData:(etc) has error.

2009-08-13 Thread John Velman
I'm writing a simple throw away program to transform data format from a
text file to a text file.  I decided to use a Cocoa Document class for
practice, instead of (for example) perl.

Using -readFromData:ofType:Error: storing the data as a string, and then
converting the string works fine (except the program just stalls
afterwards) and has to be killed.

In trying to track this down, I put a bunch of NSLog's in, and ended up
with this (boiler plate comments ommitted):

__

- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError 
**)outError
{
NSLog(@"readFromData has been called, typeName is: %...@\n", typeName);

if ( outError != NULL ) {
NSLog(@"outError is not null");

NSLog(@"Going to call NSError\n");
*outError = [NSError errorWithDomain:NSOSStatusErrorDomain 
   code:unimpErr userInfo:NULL];
NSLog(@"Read error -- outError is: %...@\n\n", *outError);
[self setInputData:[[NSString alloc] 
initWithData:data encoding:NSUTF8StringEncoding]];
[self convertData];
return NO;
}

"convertData" is the method that does the format conversion.  It has ample
NSLog statments so I can see that it is being converted properly.

My debug console gives:

2009-08-13 13:44:50.376 TransformKaiser[1419:10b] readFromData has been called, 
typeName is: Kiaser History Convert
2009-08-13 13:44:50.378 TransformKaiser[1419:10b] outError is not null
2009-08-13 13:44:50.378 TransformKaiser[1419:10b] Going to call NSError
2009-08-13 13:44:50.380 TransformKaiser[1419:10b] Read error -- outError is: 
Error Domain=NSOSStatusErrorDomain Code=-4 "Operation could not be completed. 
(OSStatus error -4.)" ( /  / unimplemented core routine)

(Could have spelled Kaiser correctly, but what the heck, this was supposed
to be a one run throw away program.)

and I get an alert message that says: "The document “testFile.txt” could
not be opened."  I suppose this is due to returning NO.

But what is the unimplemented core routine?


I'm using Xcode 3.1.3, on OS X 10.5.8, Intel core 2 duo.  My active
architecture is i386, sdk is 10.5, build configuration is Debug.

Thanks,

John Velman

___

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

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

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

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


iPhone: detect if docked?

2009-08-13 Thread Eric E. Dolecki
I am looking into disabling the idle timer when the thing is docked and
running my application.
UIApplication* application = [UIApplication sharedApplication];
application.idleTimerDisabled = YES;

Is there a way to tell if the device is currently docked so that the app
doesn't get smacked down by Apple for eating battery?
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: scroll view is now disabled after switching to snowleopard

2009-08-13 Thread Jean-Daniel Dupas


Le 13 août 2009 à 21:46, Stephane Huaulme a écrit :

this is an app with a couple of scrollviews, and after upgrading to  
snowleopard and recompiling, one of the 2 scrollviews is disabled.  
it's content is getting updated but it's grey'd out and i can't  
focus it.


when i compare that view using the inspector with the other almost  
identical view that does work, i can't find any difference that  
could explain the "disabling" of the second one.


any ideas?


Snow Leopard is under NDA and cannot be discussed here.

That said, I can give you a non snow leopard specific answer. It may  
be cause by a binding on the view with a "conditionally sets enabled"  
attribute.



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Document file read, but -readFromData:(etc) has error.

2009-08-13 Thread I. Savant
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName  
error:(NSError **)outError

{
   NSLog(@"readFromData has been called, typeName is: %...@\n",  
typeName);


   if ( outError != NULL ) {
   NSLog(@"outError is not null");

   NSLog(@"Going to call NSError\n");
*outError = [NSError errorWithDomain:NSOSStatusErrorDomain
  code:unimpErr userInfo:NULL];
   NSLog(@"Read error -- outError is: %...@\n\n", *outError);
   [self setInputData:[[NSString alloc]
   initWithData:data  
encoding:NSUTF8StringEncoding]];

   [self convertData];
   return NO;
}



  Have you provided the complete implementation for this method? If  
so, you seriously need to re-read this:


http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Documents.html#


But what is the unimplemented core routine?


  This line makes it clear you're not reading the documentation. The  
docs say of this method:


"The default implementation of this method throws an exception because  
at least one of the three reading methods (this  
method,readFromURL:ofType:error:, readFromFileWrapper:ofType:error:),  
or every method that may invoke readFromURL:ofType:error:, must be  
overridden."


  The core routine is the one you're trying to implement ... by  
returning NO, the system is displaying this pre-generated error.


  In your code (which makes no sense to me whatsoever), you appear to  
be asking if there's an error (which there is, by default, per the  
docs), then going ahead and reading in the file (without checking if  
that call even succeeded), then returning NO, signaling the document  
could not be read. What happens if there *is* no error is anyone's  
guess because you don't appear to be returning anything in that case  
(if the method says it returns something, it had better return  
something). Of course you'll never hit that case with how you're  
presently implementing it ...


  Usually your method would have if cases for each of your document  
types (which return yes on success or setting the error on failure)  
and your last line in that method would return NO (a catch all for  
"not the right doc type" and "doc type failed to open") so your  
customized error will be presented to the user.


  Seriously - read the documentation. It's all there in great detail.

--
I.S.



On Aug 13, 2009, at 5:07 PM, John Velman wrote:

I'm writing a simple throw away program to transform data format  
from a

text file to a text file.  I decided to use a Cocoa Document class for
practice, instead of (for example) perl.

Using -readFromData:ofType:Error: storing the data as a string, and  
then

converting the string works fine (except the program just stalls
afterwards) and has to be killed.

In trying to track this down, I put a bunch of NSLog's in, and ended  
up

with this (boiler plate comments ommitted):

__


"convertData" is the method that does the format conversion.  It has  
ample

NSLog statments so I can see that it is being converted properly.

My debug console gives:

2009-08-13 13:44:50.376 TransformKaiser[1419:10b] readFromData has  
been called, typeName is: Kiaser History Convert

2009-08-13 13:44:50.378 TransformKaiser[1419:10b] outError is not null
2009-08-13 13:44:50.378 TransformKaiser[1419:10b] Going to call  
NSError
2009-08-13 13:44:50.380 TransformKaiser[1419:10b] Read error --  
outError is: Error Domain=NSOSStatusErrorDomain Code=-4 "Operation  
could not be completed. (OSStatus error -4.)" ( /  / unimplemented  
core routine)


(Could have spelled Kaiser correctly, but what the heck, this was  
supposed

to be a one run throw away program.)

and I get an alert message that says: "The document “testFile.txt”  
could

not be opened."  I suppose this is due to returning NO.

But what is the unimplemented core routine?


I'm using Xcode 3.1.3, on OS X 10.5.8, Intel core 2 duo.  My active
architecture is i386, sdk is 10.5, build configuration is Debug.

Thanks,

John Velman

___

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

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

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

This email sent to idiotsavant2...@gmail.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: File's owner, outlets and methods

2009-08-13 Thread Michael de Haan


On Aug 13, 2009, at 1:59 PM, Dave Carrigan wrote:



On Aug 13, 2009, at 1:32 PM, Michael de Haan wrote:

The inspector of File's owner in the "Custom" xib shows, as  
expected an outlet ( which is connected) as well as the method  
"showPanel" which is *not* connected. In fact, I am unable to  
"connect" ( if that is the correct terminology) the "About  
NewApplication" to this, or to the File's owner (control-drag), but  
am able to do so to the AppController object in the mainMenu.xib


I'm not 100% sure, but it seems like you're saying that you are  
trying to connect the About NewApplication menu item in MainMenu.xib  
to the Files Owner in Custom.xib?


Can I withdraw my post?  :-(
You just made me realize something that I had missed completelyand  
I won't say what it is, it's too embarrassing!






If that is the case, you can't do that. All connections must be  
between objects and proxy objects within a single xib. The nib  
loading process only works on a single nib at a time and doesn't  
know anything about what might be in some other nib.



[

**Very** briefly, the set up is as follows.

AppController has an outlet (IBOutlet NSPanel *aboutWindow) and a  
method (-(IBAction) showPanel: (id) sender;)


]

So, there are really 2 things happening here?

One is that the About Window's  target is established in the  
MainMenu.xib  ( ie About NewApplication is connected to the method  
showPanel).
Secondly, in the About.xib the File's owner is set to the  
AppController AND File's owner "aboutWindow" outlet is now pointed to  
the NSPanel object.


I am assuming that this second action is used in the method of  
showPanel, where I assume? AppController's outlet is utilized?


-(IBAction) showPanel: (id) sender
{
BOOL successful = [NSBundle loadNibNamed: @"About" owner: self];

}






Dave...thanks for that insight so far.


___

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

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

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

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


Re: iPhone: detect if docked?

2009-08-13 Thread David Duncan

On Aug 13, 2009, at 2:12 PM, Eric E. Dolecki wrote:


Is there a way to tell if the device is currently docked?


Probably the closest thing would be to use the Battery API to  
determine if the battery is being charged. See UIDevice for details.

--
David Duncan
Apple DTS Animation and Printing

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Releasing ivars in -didTurnIntoFault. Should set to nil?

2009-08-13 Thread Quincey Morris

On Aug 13, 2009, at 13:33, Georg C. Brückmann wrote:

Well, is there any disadvantage when autoreleasing? (I’m not talking  
about tight loops here – that’s another topic.) Generally speaking,  
releasing a delegating object, when it notifies its delegate that  
it’s finished, should be fine from the delegate’s point of view.


Also, I’m interested what method of reference releasing you’d  
recommend, because the timer issue mentioned above would be equally  
present when releasing instead of autoreleasing.


Note that I don’t want to persuade you, I just don’t see any  
disadvantage of autoreleasing while I do see a slight advantage.


We're in a thread where the opinion has been expressed (I'm  
paraphrasing here, not quoting) that it's a bit safer to set a  
reference to nil (as opposed to leaving it pointing to a possibly non- 
existent object) just after releasing it. There's more to that  
opinion, but that's the guts of it, and I agree with it.


Your refinement was to suggest that it's even safer to autorelease the  
reference, instead of releasing it, before setting it to nil. My point  
was that it's not safer as a general principle -- it's just a solution  
to what would otherwise be a lifetime-maintenance bug in your code, in  
a specific scenario.


So what's the disadvantage to doing it generally? Well, ...

1. [not important] It clutters up the autorelease pool unnecessarily.

2. [somewhat important] It instills a false sense of security, but  
implying that extending the object lifetime to the next pool drain is  
always a sufficient lifetime extension. It isn't, not necessarily.


3. [somewhat more important] If you switch to garbage collection,  
solving the original problem (in the NSURLConnection case) with  
autorelease isn't possible. Under GC, the "defect" (if you'll excuse  
the word) in your original design is revealed, and finding a solution  
may be considerably more difficult.



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Document file read, but -readFromData:(etc) has error.

2009-08-13 Thread John Velman
On Thu, Aug 13, 2009 at 05:21:06PM -0400, I. Savant wrote:
>
>   Have you provided the complete implementation for this method? If so, you 
> seriously need to re-read this:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Documents.html#

Thanks.  I did read it, but some time ago, and I didn't re-read it for
this.

Sorry for the inconvenience!

John Velman

___

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

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


detect "left mouse button clicked in menu bar"

2009-08-13 Thread David M. Cotter
i know i can detect when a particular menu is about to be shown, but  
what I want is to run a quick process before any menus from the menu  
bar are shown, and not run it again all the while the user is browsing  
the menus in the menu bar


how do i do this?   apparently there is no "mouseDown" event sent when  
it's in the menu bar. currently i have this very ugly code:


-(void)sendEvent:(NSEvent *)inEvent
{
NSEventType evtType = [inEvent type];

switch (evtType) {

//  is this a mouse down in the menu bar?
case NSSystemDefined: {

if (
   [inEvent subtype] == 
NX_SUBTYPE_AUX_MOUSE_BUTTONS
&& [inEvent window] == NULL
) {
NSPoint 
mousePt = [inEvent locationInWindow];
NSScreen*   
screenRef = [NSScreen mainScreen];
PointF32myPt;

//  flip the coordinates
myPt = 
TransformScreenPointFromMacScreen(screenRef, mousePt);

CGFloat heightF = 
(CGFloat)[[NSApp mainMenu] menuBarHeight];

if (myPt.y < heightF && myPt.x < [screenRef 
frame].size.width) {
// do my quick process
}
}

break;
}


___

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

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


Can I tell [NSAppleScript executeAppleEvent] to wait for script to complete?

2009-08-13 Thread DeNigris Sean
When I use [NSAppleScript executeAppleEvent] to call handlers in a  
compiled script, it returns immediately.


Is there a way to get it to block until the script is finished?  Maybe  
there a notification I can listen for?


Thanks!

Sean DeNigris
s...@clipperadams.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: detect "left mouse button clicked in menu bar"

2009-08-13 Thread Peter Ammon


On Aug 13, 2009, at 2:56 PM, David M. Cotter wrote:

i know i can detect when a particular menu is about to be shown, but  
what I want is to run a quick process before any menus from the menu  
bar are shown, and not run it again all the while the user is  
browsing the menus in the menu bar


how do i do this?   apparently there is no "mouseDown" event sent  
when it's in the menu bar. currently i have this very ugly code:


The NSMenuDidBeginTrackingNotification is posted at the point menu  
tracking begins, before any menu is shown.  That sounds like what you  
want.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: File's owner, outlets and methods

2009-08-13 Thread Ken Thomases

On Aug 13, 2009, at 4:24 PM, Michael de Haan wrote:


[

**Very** briefly, the set up is as follows.

AppController has an outlet (IBOutlet NSPanel *aboutWindow) and a  
method (-(IBAction) showPanel: (id) sender;)


]

So, there are really 2 things happening here?

One is that the About Window's  target is established in the  
MainMenu.xib  ( ie About NewApplication is connected to the method  
showPanel).


The About _menu_'s target is established in the MainMenu.xib.  The  
About _window_ is not known in the scope of this xib.


Secondly, in the About.xib the File's owner is set to the  
AppController AND File's owner "aboutWindow" outlet is now pointed  
to the NSPanel object.


I am assuming that this second action is used in the method of  
showPanel, where I assume? AppController's outlet is utilized?


Not as you've written the showPanel: method below.

An outlet is a property of an object.  It's often backed by an  
instance variable as its implementation.


Once you connect an outlet to an object in the nib, this connection is  
recorded as data within the xib/nib.  Later, when that nib is loaded,  
Cocoa's nib loading machinery reestablishes the connection by setting  
the property on the object.  In this case, the outlet is on File's  
Owner which, during nib design, is a proxy for an actual object which  
is supplied when the nib is loaded.  It's the property on this actual  
object which gets set during nib loading.


So, after that nib is loaded, the aboutWindow property of your  
AppController object has been set to refer to the panel that was  
reconstituted from the data in the nib.


Now, some properties will be used by the framework because the  
framework was designed with them in mind.  For example, the delegate  
property of the application object.  Hooking this outlet up in a nib  
has automatic effects, because the framework makes use of the  
application delegate in various ways.


However, properties you define yourself typically won't be  
automatically used by the framework.  So, setting up a custom outlet  
such as aboutWindow in a nib doesn't have secondary effects.  It only  
has the primary effect of setting that property on that object as the  
nib is loaded.  From there, it's up to you to make use of that value  
in whatever code you write.




-(IBAction) showPanel: (id) sender
{
BOOL successful = [NSBundle loadNibNamed: @"About" owner: self];

}


Hmm.  As you report you've got things working, I'm guessing the panel  
in the About.xib is set to Visible At Launch.  So, the very act of  
loading the nib causes the window to display.  If you've also set it  
to Release When Closed, then it will properly clean itself up when  
it's dismissed.


However:

1) This doesn't make any use of the aboutWindow outlet of the  
AppController object.  So, there would be no need to set that outlet  
up and connect it.


2) Consider what happens if you invoke the About menu when the About  
panel is already showing.  In fact, try it.


You probably only want to load the nib once, if it hasn't already been  
loaded.  After that, you only want to reuse the panel that was loaded  
that first time.  You just have to tell it to show itself.  Try to  
figure out how that would work.  If you have trouble, feel free to ask  
again.


I'm not familiar with the Hillegass book, so I don't know if you've  
gotten to NSWindowController's, yet.  I'm guessing not.  At some  
point, you will.  It should make clear that you should probably use  
NSWindowControllers (or subclasses thereof) as File's Owner for nibs  
which contain windows or panels.  That has some important benefits for  
managing the resources of the nib.  I won't get into that now. :)


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

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


Re: Document file read, but -readFromData:(etc) has error.

2009-08-13 Thread Ken Thomases

On Aug 13, 2009, at 4:07 PM, John Velman wrote:

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

{
   NSLog(@"readFromData has been called, typeName is: %...@\n",  
typeName);


   if ( outError != NULL ) {
   NSLog(@"outError is not null");

   NSLog(@"Going to call NSError\n");
*outError = [NSError errorWithDomain:NSOSStatusErrorDomain
  code:unimpErr userInfo:NULL];
   NSLog(@"Read error -- outError is: %...@\n\n", *outError);
   [self setInputData:[[NSString alloc]
   initWithData:data  
encoding:NSUTF8StringEncoding]];

   [self convertData];
   return NO;
}


You appear to have misunderstand the nature of the outError  
parameter.  As the "out" prefix suggests, this is an output  
parameter.  The caller supplies the address of a place where you  
_could_ store an NSError object pointer _if_ your method encounters an  
error in reading from the data.


If outError == NULL, that means the caller is not interested in  
getting the details of any error that might occur.  If outError !=  
NULL, that does _not_ mean that an error has occurred or should be  
provoked.  It only means the caller wishes to receive the pointer to  
an NSError object _if_ an error occurs.  So, your 'if ( outError !=  
NULL )' conditional makes no sense as it stands.


Your code should attempt to perform the conversion of the data and,  
only if that conversion fails, it should check if the caller wanted a  
detailed error object and supply one.  So, you should only check if  
outError is or is not NULL after _you_ have determine that _your  
conversion code_ encountered an error.  You are not being signaled  
that there's been an error by your caller.  Your caller doesn't know  
if there's been an error.  It's waiting to find out.


Likewise, you should return TRUE or YES or the like if your conversion  
succeeds.  You should only return NO or FALSE if your conversion fails.


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

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


Re: File's owner, outlets and methods

2009-08-13 Thread Michael de Haan


On Aug 13, 2009, at 6:36 PM, Ken Thomases wrote:


On Aug 13, 2009, at 4:24 PM, Michael de Haan wrote:


[

**Very** briefly, the set up is as follows.

AppController has an outlet (IBOutlet NSPanel *aboutWindow) and a  
method (-(IBAction) showPanel: (id) sender;)


snip.

One is that the About Window's  target is established in the  
MainMenu.xib  ( ie About NewApplication is connected to the method  
showPanel).


The About _menu_'s target is established in the MainMenu.xib.  The  
About _window_ is not known in the scope of this xib.



Of course...stand corrected. That's what I meant but syntax is  
important  :-)






Secondly, in the About.xib the File's owner is set to the  
AppController AND File's owner "aboutWindow" outlet is now pointed  
to the NSPanel object.


I am assuming that this second action is used in the method of  
showPanel, where I assume? AppController's outlet is utilized?


Not as you've written the showPanel: method below.



As I drove home  I got to thinking ( that's what a good thunderstorm  
will do!). I in fact disconnected all references ( by this I mean  
IBOutlets in AppController and opened the connection between File's  
owner and the NSPanel . It still worked and then it dawned that the  
outlet was there **if** I needed to send a message **after** the Nib  
was loaded. So, reconnected all, and changed the title of the Panel  
after the "BOOL successful = [NSBundle loadNibNamed: @"About" owner:  
self];" call,   and it suddenly all made sense.


What confused me, as it has done a number of people following this, is  
the advice given by Hillegass to set up an outlet in the AppController  
class and use the NSBundle class to load the nib. Understandably, I  
think most of us expected, therefore , that this outlet **would** play  
a role in this setup, but , clearly, I think in this case, it is being  
set up for later use, I suspect.





An outlet is a property of an object.  It's often backed by an  
instance variable as its implementation.


Once you connect an outlet to an object in the nib, this connection  
is recorded as data within the xib/nib.  Later, when that nib is  
loaded, Cocoa's nib loading machinery reestablishes the connection  
by setting the property on the object.  In this case, the outlet is  
on File's Owner which, during nib design, is a proxy for an actual  
object which is supplied when the nib is loaded.  It's the property  
on this actual object which gets set during nib loading.


So, after that nib is loaded, the aboutWindow property of your  
AppController object has been set to refer to the panel that was  
reconstituted from the data in the nib.



I think I finally get "File's owner"  :-)  So, if I understand you  
correctly, having set File's owner to the appropriate class ( in this  
case AppController) I set the appropriate **proxy** outlet of File's  
owner  to the object ( in this case NSPanel instance) and when the  
Nib  is loaded, AppController's IBOutlet gets set to the NSPanel  
instance, allowing me to send a message from AppController ( set title  
etc) during run-time.








-(IBAction) showPanel: (id) sender
{
BOOL successful = [NSBundle loadNibNamed: @"About" owner: self];

}



2) Consider what happens if you invoke the About menu when the About  
panel is already showing.  In fact, try it.


Yep..see above  :-)





You probably only want to load the nib once, if it hasn't already  
been loaded.  After that, you only want to reuse the panel that was  
loaded that first time.  You just have to tell it to show itself.   
Try to figure out how that would work.  If you have trouble, feel  
free to ask again.







Ken...this may seem like a small thing to you, but this little  
exercise, with your help and the others who have answered has given me  
some good understanding I did not have before.

Much appreciated.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Can I tell [NSAppleScript executeAppleEvent] to wait for script to complete?

2009-08-13 Thread Jerry Krinock


On 2009 Aug 13, at 15:45, DeNigris Sean wrote:

When I use [NSAppleScript executeAppleEvent] to call handlers in a  
compiled script, it returns immediately.


Is there a way to get it to block until the script is finished?   
Maybe there a notification I can listen for?


H, my NSAppleScript Class Reference documentation does not list  
any such method.  It does list -executeAppleEvent:error: and - 
executeAndReturnError:, both of which return "The result of executing  
the event", which implies that they must wait for the script to  
complete.



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: detect "left mouse button clicked in menu bar"

2009-08-13 Thread Michael Watson

On Aug 13, 2009, at 16:56, "David M. Cotter"  wrote:

i know i can detect when a particular menu is about to be shown, but  
what I want is to run a quick process before any menus from the menu  
bar are shown


Launching a process is by no means a "quick" operation. It is  
imperative that menus appear instantly when requested and not cause a  
great deal system overhead in the process, since users tend to be  
trigger-happy with menus.


What is your actual goal? It seems silly that you'd need to execute a  
process every time someone clicks on a menu in the menu bar.



--
mikey

___

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

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

2009-08-13 Thread Chase Meadors


On Aug 13, 2009, at 1:50 PM, Quincey Morris wrote:


On Aug 13, 2009, at 11:25, Chase Meadors wrote:

I'm afraid you'll have to explain the multiply-by-256-and-add  
technique.


I mean something like this (untested):


unsigned char *bytes = [self bytes];
int byteIndex = [self length];
int result = 0;
BOOL firstByte = YES;

while (byteIndex--) {
if (firstByte) {
			result = (signed char *) bytes [byteIndex]; // signed the first  
time

firstByte = NO;
}
else
			result = result * 0x100 + bytes [byteIndex]; // unsigned the  
rest of the times

}

return [NSNumber numberWithInt: result];


BTW, I didn't notice that you'd originally declared 'result' as  
unsigned int, so my first suggestion wouldn't have have worked  
unless you also changed 'result' to a signed int.


P.S. I see Alastair gave you a mostly better answer already.  
However, I'll point out that if you have any *3-byte* numbers (I see  
"arbitrary length ints" in the subject line) you're not going to  
find an OSReadLittleInt24 to help you.





Yes, thanks for the help both of you. The OSRead functions are very  
convenient, but I settled on your solution because I do have some 3- 
byte numbers. Works like a charm!



___

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

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

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/c.ed.mead%40gmail.com

This email sent to c.ed.m...@gmail.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


Cocoa window in Carbon app and [NSApp postEvent]

2009-08-13 Thread Frederik Slijkerman

Hi,

I'm working on a Photoshop plugin that uses a Cocoa UI, while of course 
Photoshop is still Carbon currently. The plugin runs as a modal window 
pretty much all the time.


Now I've run into a problem: when I post a custom event to the main 
event queue using [NSApp postEvent], it is never processed. As far as I 
can tell, this is because [NSApp runModalForWindow] calls into Carbon to 
actually run the modal window, and while Carbon does handle mouse, 
keyboard and timer messages fine (by sending them directly to the window 
involved), it apparently doesn't know anything about any Cocoa events 
that are waiting in the main event queue.


Does this sound familiar to anyone? Is there any way I can work around this?

This is the code I use to post the event:

  NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined
location:NSZeroPoint modifierFlags:0 timestamp:0 windowNumber:0
context:0 subtype:0 data1:reinterpret_cast(h)
data2:reinterpret_cast(data)];
  [NSApp postEvent:event atStart:NO];

I've thought about replacing postEvent with a timer that would fire 
immediately, but it looks like this wouldn't work from a different 
thread, as timers work directly with NSRunLoop and NSRunLoop has a stern 
warning regarding thread safety...


So basically what I'm looking for is a thread-safe way to add an event 
to the main event queue, in such a way that it will be processed even 
when a modal window is running, this all in a Carbon application.


Thanks in advance!

Best regards,
Frederik Slijkerman
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: File's owner, outlets and methods

2009-08-13 Thread Ken Thomases

On Aug 13, 2009, at 9:32 PM, Michael de Haan wrote:


On Aug 13, 2009, at 6:36 PM, Ken Thomases wrote:

An outlet is a property of an object.  It's often backed by an  
instance variable as its implementation.


Once you connect an outlet to an object in the nib, this connection  
is recorded as data within the xib/nib.  Later, when that nib is  
loaded, Cocoa's nib loading machinery reestablishes the connection  
by setting the property on the object.  In this case, the outlet is  
on File's Owner which, during nib design, is a proxy for an actual  
object which is supplied when the nib is loaded.  It's the property  
on this actual object which gets set during nib loading.


So, after that nib is loaded, the aboutWindow property of your  
AppController object has been set to refer to the panel that was  
reconstituted from the data in the nib.



I think I finally get "File's owner"  :-)  So, if I understand you  
correctly, having set File's owner to the appropriate class ( in  
this case AppController) I set the appropriate **proxy** outlet of  
File's owner  to the object ( in this case NSPanel instance) and  
when the Nib  is loaded, AppController's IBOutlet gets set to the  
NSPanel instance, allowing me to send a message from AppController  
( set title etc) during run-time.


Correct, although I would apply the word "proxy" to File's Owner  
itself, not its outlets.


I like to explain File's Owner like this: imagine drawing the contents  
of a nib as an object graph on a piece of paper.  There would be  
circles for each object (window, view, menu bar, etc.) in the nib,  
with labeled arrows coming out of them and pointing to other circles/ 
objects for connections.  Some of these arrows would represent  
outlets, others would represent the action of a control.  Outlets  
would point to whole objects, actions would point to a named selector  
(method) within the target object.


Some of the objects in this graph are proxies.  They would be  
represented by ghostly circles, perhaps with a light gray, dashed  
circumference.  These objects are not really in the nib.  They serve  
as empty sockets for objects which will be supplied/found during nib  
loading.  Without such a way to represent objects which exist outside  
of the nib, there would be no way for the objects within the nib to  
have connections to the outside world.  They would be entirely insular.


Interface Builder provides proxies for the File's Owner, First  
Responder, and the Application object.  Actually, First Responder is  
really a stand-in for the nil target for actions.  When a nib is  
loaded, an owner object is explicitly supplied to the load method.   
The application object is the NSApp global.


You can imagine that at load time, there's an existing graph of real  
objects in your program, interconnected in complex ways.  The nib  
loading process creates a new subgraph for the objects in the nib, but  
the subgraph has these empty sockets in it.  The loading machinery  
grabs the corresponding pre-existing objects and pops them into those  
sockets, completing the new subgraph and integrating it into the whole  
object graph of your program.  In the act of putting a real object  
into the socket, any connections to and from the socket in the nib  
subgraph are realized with the real object as the destination or  
source.  Where the real object is now the source of a connection, the  
corresponding property on that object has to be set to refer to the  
new object that was instantiated in the nib subgraph.


Now, in order for Interface Builder to know which named arrows  
(outlets) may come out of these proxy objects, and which action  
methods may be targeted within them, you have to tell it what class  
they are intended to be.  IB communicates with Xcode to learn about  
these classes and their outlets and action methods.  Xcode learns  
about them from the IBOutlet and IBAction tags you supply in your  
declarations.  (You can actually directly tell IB about outlets and  
actions in the Identity Inspector without setting a custom class for  
an object, too.)


That's the only role for telling IB about the class of these objects  
(and for labeling outlets and action methods in your code).  It's not  
enforced at load time.  You could actually provide a different class  
of object at runtime, so long as it provided the necessary outlets and  
action methods.  (Of course, doing so would be confusing.)




Ken...this may seem like a small thing to you, but this little  
exercise, with your help and the others who have answered has given  
me some good understanding I did not have before.

Much appreciated.


You're quite welcome.  I'm glad I could help.  Good luck with your  
continued learning. :)


Cheers,
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-ad

Re: Document file read, but -readFromData:(etc) has error.

2009-08-13 Thread John Velman
On Thu, Aug 13, 2009 at 08:50:06PM -0500, Ken Thomases wrote:
> On Aug 13, 2009, at 4:07 PM, John Velman wrote:
>
>> - (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName 
>> error:(NSError **)outError
>> {
>>NSLog(@"readFromData has been called, typeName is: %...@\n", typeName);
>>
>>if ( outError != NULL ) {
>>NSLog(@"outError is not null");
>>
>>NSLog(@"Going to call NSError\n");
>>  *outError = [NSError errorWithDomain:NSOSStatusErrorDomain
>>   code:unimpErr userInfo:NULL];
>>NSLog(@"Read error -- outError is: %...@\n\n", *outError);
>>[self setInputData:[[NSString alloc]
>>initWithData:data 
>> encoding:NSUTF8StringEncoding]];
>>[self convertData];
>>return NO;
>>  }
>
> You appear to have misunderstand the nature of the outError parameter.  As 
> the "out" prefix suggests, this is an output parameter.  The caller 
> supplies the address of a place where you _could_ store an NSError object 
> pointer _if_ your method encounters an error in reading from the data.
>
> If outError == NULL, that means the caller is not interested in getting the 
> details of any error that might occur.  If outError != NULL, that does 
> _not_ mean that an error has occurred or should be provoked.  It only means 
> the caller wishes to receive the pointer to an NSError object _if_ an error 
> occurs.  So, your 'if ( outError != NULL )' conditional makes no sense as 
> it stands.
>
> Your code should attempt to perform the conversion of the data and, only if 
> that conversion fails, it should check if the caller wanted a detailed 
> error object and supply one.  So, you should only check if outError is or 
> is not NULL after _you_ have determine that _your conversion code_ 
> encountered an error.  You are not being signaled that there's been an 
> error by your caller.  Your caller doesn't know if there's been an error.  
> It's waiting to find out.
>
> Likewise, you should return TRUE or YES or the like if your conversion 
> succeeds.  You should only return NO or FALSE if your conversion fails.
>
> Regards,
> Ken

Thanks, Ken.  This is very helpful.  Originally I had left the error test
out, did my conversion as part of the read, and everything was fine except
that the program hung up after the conversion was complete.  But I'll leave
the long story out.  I got to putting in the log print of the error _after_
I tinkered around for a while and couldn't find why I was unable to do
something with the data in a different method (an IBAction) _after_ the
data was read.  Clearly this problem was elsewhere.

Back to the drawing board.  After the I.S. response, I went back and read
the document.pdf, and checked some of my other programs, and what I did
originally seems to have been in conformance with doc's and working.  I
must have another error, which I completely masked by missunderstanding the
nature of the outError argument.

Thanks again,

John V.

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: detect "left mouse button clicked in menu bar"

2009-08-13 Thread David M. Cotter
sorry, bad choice of words on my part.  i meant i want to call a  
function.


anyway i learned about "NSMenuDidBeginTrackingNotification" which does  
exactly the trick i was looking for



On Aug 13, 2009, at 8:09 PM, Michael Watson wrote:

On Aug 13, 2009, at 16:56, "David M. Cotter"   
wrote:


i know i can detect when a particular menu is about to be shown,  
but what I want is to run a quick process before any menus from the  
menu bar are shown


Launching a process is by no means a "quick" operation. It is  
imperative that menus appear instantly when requested and not cause  
a great deal system overhead in the process, since users tend to be  
trigger-happy with menus.


What is your actual goal? It seems silly that you'd need to execute  
a process every time someone clicks on a menu in the menu bar.



--
mikey



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: File's owner, outlets and methods

2009-08-13 Thread Michael de Haan


On Aug 13, 2009, at 8:26 PM, Ken Thomases wrote:



I think I finally get "File's owner"  :-)  So, if I understand you  
correctly, having set File's owner to the appropriate class ( in  
this case AppController) I set the appropriate **proxy** outlet of  
File's owner  to the object ( in this case NSPanel instance) and  
when the Nib  is loaded, AppController's IBOutlet gets set to the  
NSPanel instance, allowing me to send a message from AppController  
( set title etc) during run-time.


Correct, although I would apply the word "proxy" to File's Owner  
itself, not its outlets.



Of course...again  :-)



I like to explain File's Owner like this:


Ken...thanks for that really illuminating discourse on File's owner.  
As I look back, I am not sure why this is so confusing, but clearly  
it's a hurdle that many novices go through ( a quick search of the  
archives will attest to that)so, hopefully this will be my insight  
to the next level.


With much thanks again.
Michael.








___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Cocoa window in Carbon app and [NSApp postEvent]

2009-08-13 Thread Ken Ferry
Hi,
It sounds to me like you are interested in
-[NSObject performSelectorOnMainThread:withObject:waitUntilDone:modes:].

-Ken

On Thu, Aug 13, 2009 at 12:38 PM, Frederik Slijkerman <
frede...@ultrafractal.com> wrote:

> Hi,
>
> I'm working on a Photoshop plugin that uses a Cocoa UI, while of course
> Photoshop is still Carbon currently. The plugin runs as a modal window
> pretty much all the time.
>
> Now I've run into a problem: when I post a custom event to the main event
> queue using [NSApp postEvent], it is never processed. As far as I can tell,
> this is because [NSApp runModalForWindow] calls into Carbon to actually run
> the modal window, and while Carbon does handle mouse, keyboard and timer
> messages fine (by sending them directly to the window involved), it
> apparently doesn't know anything about any Cocoa events that are waiting in
> the main event queue.
>
> Does this sound familiar to anyone? Is there any way I can work around
> this?
>
> This is the code I use to post the event:
>
>  NSEvent *event = [NSEvent otherEventWithType:NSApplicationDefined
>location:NSZeroPoint modifierFlags:0 timestamp:0 windowNumber:0
>context:0 subtype:0 data1:reinterpret_cast(h)
>data2:reinterpret_cast(data)];
>  [NSApp postEvent:event atStart:NO];
>
> I've thought about replacing postEvent with a timer that would fire
> immediately, but it looks like this wouldn't work from a different thread,
> as timers work directly with NSRunLoop and NSRunLoop has a stern warning
> regarding thread safety...
>
> So basically what I'm looking for is a thread-safe way to add an event to
> the main event queue, in such a way that it will be processed even when a
> modal window is running, this all in a Carbon application.
>
> Thanks in advance!
>
> Best regards,
> Frederik Slijkerman
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com
>
> This email sent to kenfe...@gmail.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


[Moderator] Re: scroll view is now disabled after switching to snowleopard

2009-08-13 Thread Scott Anguish

Remember folks, SnowLeopard is still covered by non-disclosure.

Forums for NDA discussion are available at devforums.apple.com


scott
[moderator]
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Disabled controls don't update their visual appearance

2009-08-13 Thread Christopher Jensen
Sorry to bump my own post, but I am curious if anyone has any suggestions?
Just get in touch if you need to see more code to help me figure out the
issue :)
Thanks,
Chris
___

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

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

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

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