Re: Magic Mouse and NSTouch
On Oct 27, 2009, at 10:44 PM, Scott Anguish wrote: There should be a tech note shortly that describes these capabilities. Is this the one? http://developer.apple.com/mac/library/releasenotes/DriversKernelHardware/RN-MagicMouse/index.html It doesn't mention NSTouch, so I'm hoping there's more detail coming later. I'm surprised no one has t I spent some time at a kind Apple reseller trying to test one myself, but completely missed the need for -[NSView setAcceptsTouchEvents:] and might have gotten a false negative. Like the OP, I would also be very grateful for information about the Magic Mouse's NSTouch capabilities before I make that investment. All my searching yields is mixed reports. thanks, -natevw On Oct 21, 2009, at 2:21 AM, Chunk 1978 wrote: i would be surprised if it didn't support NSTouch. although you may have to wait for 10.6.2: http://www.macrumors.com/2009/10/20/magic-mouse-user-guide-suggests-mac-os-x-10-6-2-release-in-near-future/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/nate-lists%40calftrail.com This email sent to nate-li...@calftrail.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: odd behavior with NSError?
On Oct 2, 2009, at 7:45 AM, Bill Bumgarner wrote:
In either case, assuming the undefined reference is nil would be a
bug. Initializing the variables to nil prior to the call isn't going
to change anything in that regard.
(And, yes, there are methods that modify their error parameter on
success -- purely an implementation detail. Perfect valid thing to
do since the return value is undefined on success.)
Ouch. So the following pattern is incorrect?
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:internalError];
if (internalError) {
// ...
}
I got into this habit because most every method is documented to say
things like parameter used if an error occurs and May be NULL.
You're saying that some methods go out of their way to trample my
(potentially unavailable) error storage even on success? I'm starting
to worry that I'll spend tomorrow fixing much old code instead of
getting to make new mistakes...
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: creating registration codes
On Aug 27, 2009, at 9:18 PM, Rick C. wrote: hello, my apologies if this is a bit off-topic, but once an app is done does anyone have a recommendation on how to go about setting up a registration code system for the created app. i guess it needs some programming in partner with some scripting on the web side. maybe a 3rd parth service? with so many developers in here with much more experience than myself i thought someone could point me in the right direction on coding/preparing an app to be sold. thank you very much, Yep, off topic for this list. But software registration options have been discussed on the macsb mailing list, which is a great place to talk with developers other developers who sell their own Mac apps: http://tech.groups.yahoo.com/group/macsb/ HTH, -nvw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Why I have a leak? I am unable to understand
On Aug 24, 2009, at 5:20 PM, Agha Khan wrote: HI: I know the leak is in next 2 lines I have commented all the code except these 2 lines. // NSTimeInterval NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar]; unsigned unitFlags = NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit | NSHourCalendarUnit | NSMinuteCalendarUnit | NSSecondCalendarUnit; NSDateComponents *dateSegments = [gregorian components:unitFlags fromDate:[NSDate date]]; I am not releasing gregorian, because I never used retain. Same is true with dateSegments. Can someone help me. Why I have a leak? I am unable to understand? From http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html You own any object you create. You “create” an object using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc,newObject, or mutableCopy). You created gregorian using [NSCalendar alloc], so you own it. The next rule on that page says: If you own an object, you are responsible for relinquishing ownership when you have finished with it. You relinquish ownership of an object by sending it a release message or an autorelease message (autorelease is discussed in more detail in “Delayed Release”). In Cocoa terminology, relinquishing ownership of an object is typically referred to as “releasing” an object. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
Layer-backed view confused by bounds transformation
An NSView's bounds can be set to a different size than its frame, which results in a transform being applied to the graphics context as the view is drawn. How is this supposed to affect subviews if the view is layer backed? If I set my view's bounds to have half the width of its frame, all its subviews are drawn and work correctly at double their normal size. When I turn on layer backing for this view, its subviews are no longer drawn transformed, although event handling remains transformed. If I turn on layer backing for just a subview, it displays at double size momentarily, but soon gets drawn at normal size even though events are handled at the double size. Is this to be expected? What are the geometry implications for Core Animation when the hosting view has a bounds transform? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: When do I need to override hash?
On Aug 19, 2009, at 4:28 PM, Gideon King wrote:
So do I need to override hash too? If so, are there any
recommendations as to how to determine the hash easily?
If you need to override -isEqual: to provide something besides pointer
comparison, you should also override -hash. If objects are equal,
their hashes must be equal or you may trigger undefined behaviour in
who knows what situations.
While this may not offer the best performance, the easiest way to
implement -hash would be to take all the properties/internal state of
your object that affect equality, format them into an NSString, and
then return the hash of the string.
E.g.:
- (NSUInteger)hash {
NSString* valueRepresentation = [NSString stringWithFormat:@%@ %lu,
self.companyName,
self.departmentID];
return [valueRepresentation hash];
}
hope this helps,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: When do I need to override hash?
On Aug 19, 2009, at 4:28 PM, Gideon King wrote: So do I need to override hash too? If so, are there any recommendations as to how to determine the hash easily? Sorry, just came across this thread that has some more tips: http://www.omnigroup.com/mailman/archive/macosx-dev/2003-December/049844.html If you need better performance from your hash function than my previous suggestion, you can just pick a somewhat unique property and return its -hash. This works because, while equal object have equal hashes, equal hashes don't guarantee equality. -nvw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Outline View DnD
On Aug 7, 2009, at 6:56 AM, bryscomat wrote: ... Now the dilemma comes when I want to get the drag and drop to work in a specific way. I want the playlists to be able to be dragged and placed in any order, but not above the separator. I have achieved this using the delegate method validateDrop: and returning DragOperationNone if the proposed child index is less than the index of the separator. However, I also want a user to be able to drag the items in the Singers group around in any order as well, and this doesn't allow that. I found that if in validateDrop: I check if the item is a singer and that the parent item is the singers group to allow it that it works for that. How do I get both of these to happen? If anyone could just point me in the right direction I'll take it from there. Take a look at the -[NSOutlineView setDropItem:dropChildIndex:] method. You can call it from your validateDrop method to change the proposedItem and proposedChildIndex if they are not appropriate. hth, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
Add same object/key to NSMapTable
The following (simplified test case) code will crash with NSZombieEnabled: NSMapTable* testTable = [NSMapTable mapTableWithStrongToStrongObjects]; NSString* o = [@test_object mutableCopy]; NSString* k = @test_key; [testTable setObject:o forKey:k]; [o release]; [testTable setObject:o forKey:k]; // crash What seems to be happening is that -[NSMapTable setObject:forKey:] does a plain release on the key's old object before retaining the new object. This can result in the situation above, where the retain of the new object is performed on a zombie created by the release of the (identical) old. I could find no documentation to the effect that re-assigning an object is not allowed, so can I assume this is indeed unintentional? If so, I've got this test case in project form and would be happy to file a bug. thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Add same object/key to NSMapTable
On Jun 17, 2009, at 6:44 PM, Kyle Sluder wrote: On Wed, Jun 17, 2009 at 6:33 PM, Nathan Vander Wiltnate-li...@calftrail.com wrote: I could find no documentation to the effect that re-assigning an object is not allowed, so can I assume this is indeed unintentional? If so, I've got this test case in project form and would be happy to file a bug. Please do file a bug. Filed as rdar://problem/6982962. Workaround is to refactor so you're not doing this, [[o retain] autorelease], or check if the object is already in the map table. In the meantime, the explicit case you present is always going to be fraught with peril, because after you release o, you have relinquished all rights to it. It's now a weak reference. Isn't it acceptable practice to let a container object I hold to maintain its objects on my behalf? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: When init returns nil does it cause a leak
On May 19, 2009, at 9:37 AM, Jean-Daniel Dupas wrote:
Le 19 mai 09 à 18:24, Reza Farhad a écrit :
Hi all
we have an object that gets initialized like most other objects
-(id)init
{
self = [ super init ];
if ( self ){
...do something;
}
return self;
}
if [ super init ] returns nil does this cause a leak, as the
memory has already been created by calling alloc when trying to
create the object
AnObject*object = [[ AnObject alloc ] init ];
I am sure the answer is simple but this suddenly stumbled me.
Thanks
The answer is in the Cocoa Fundamentals Guide Cocoa Objects
Object Creation Implementing Initializer
with a lots of other useful info.
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html
There was a thread in ObjC-language about this a while back:
http://lists.apple.com/archives/ObjC-Language/2008/Sep/msg00132.html
In the followup, an Apple runtime engineer recommends calling [super
dealloc] before returning nil, saying [self dealloc] or [self
release] are bad because they might call some subclass's -dealloc
method even though the subclass's -init hasn't done anything yet.
Of course, in practice [self release] should usually work just fine as
well, and avoids breaking the never call dealloc except in -dealloc
taboo. And indeed, this is what the documentation and sample code do
as well. I think you would be reasonably justified to do either. I'm
still debating this myself for our company's code, but the fact is
that they both work in most situations.
hope this helps,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)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: Getting NSDate from EXIF of a image
On Mar 2, 2009, at 8:48 PM, Jushin wrote:
I found that in order to convert NSString format of date to NSDate, we
need timezone.
But, EXIF doesn't support timezone unless GPS tags exist.
Yes, this is an unfortunate fact. Depending on what you need the date
for, you may need to let the user choose what timezone the camera is
in, and adjust the timestamp by the right amount before using the date
in GMT/UTC as it should be.
So, here is what I have come up with:
NSDictionary *metadata = (NSDictionary *)
CGImageSourceCopyPropertiesAtIndex(source, 0, NULL);
NSMutableDictionary *muMetadata = [[metadata mutableCopy]
autorelease];
[metadata release];
NSMutableDictionary *EXIFDictionary = [[[muMetadata
objectForKey:(NSString *)kCGImagePropertyExifDictionary]
mutableCopy] autorelease];
Maybe you are using these later in your code, but you don't need
mutable copies of these things to get the date.
NSString *EXIFDate = [[EXIFDictionary objectForKey:(NSString
*)kCGImagePropertyExifDateTimeDigitized] retain];
I'm not sure why you are retaining this here. You do not need to
retain this key to use it like you do below.
NSArray *listItems = [EXIFDate componentsSeparatedByString:@:];
NSString *newFormatedDate = [NSString stringWithFormat:@%...@-%@-%@:%@:
%@ %d,
[listItems objectAtIndex:0], [listItems objectAtIndex:1],
[listItems objectAtIndex:2],
[listItems objectAtIndex:3], [listItems objectAtIndex:4],
(([[NSTimeZone systemTimeZone] secondsFromGMT]/60)/60)];
NSDate *aDate = [[NSDate alloc] initWithString:newFormatedDate];
I still think these are not clever way. If you have better idea,
please share it with me :)
Why not use NSDateFormatter instead? Here's a function similar to one
we use, simplified a bit further and using the Digitized timestamp you
have in your code:
NSDate* PhotoDateFromEXIF(CFDictionaryRef exifProperties) {
NSString* dateTime = (NSString*)CFDictionaryGetValue(exifProperties,
kCGImagePropertyExifDateTimeDigitized);
NSDate* originalDate = nil;
if (dateTime) {
NSDateFormatter* exifFormat = [[[NSDateFormatter alloc] init]
autorelease];
[exifFormat setDateFormat:@:MM:dd HH:mm:ss];
originalDate = [exifFormat dateFromString:dateTime];
}
return originalDate;
}
hope this helps,
-natevw
On Mon, Mar 2, 2009 at 10:00 PM, Jushin coco...@gmail.com wrote:
I need to get time and date from EXIF of a image.
Following is the code snippet I used:
NSDictionary *metadata = (NSDictionary *)
CGImageSourceCopyPropertiesAtIndex(source, 0, NULL);
NSMutableDictionary *muMetadata = [[metadata mutableCopy]
autorelease];
[metadata release];
NSMutableDictionary *EXIFDictionary = [[[muMetadata
objectForKey:(NSString *)kCGImagePropertyExifDictionary]
mutableCopy
] autorelease];
NSString *EXIFDate = [[EXIFDictionary objectForKey:(NSString
*)kCGImagePropertyExifDateTimeDigitized] retain];
NSLog(EXIFDate);
NSDate *aDate = [[NSDate alloc] initWithString: EXIFDate];
Here are my questions:
1. the last line, NSDate *aDate returns null.
I think it is because the format of EXIFDate string that was created
right above isn't correct.
When I did NSLog(EXIFDate), I get followings:
2008:11:06 19:12:51
According to the NSDate documentation, string format of time should
be:
2008-11-06 19:12:51
2. the returned date string (EXIFData) doesn't have timezone
information.
Is it possible to get timezone info as well from the EXIF
information?
3. Well... eventually what I want to do is, I want to create unix
time format of date from image EXIF using timeIntervalSince1970.
Is there any other better way to get this?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/nate-lists%40calftrail.com
This email sent to nate-li...@calftrail.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: mergeChangesFromContextDidSaveNotification effects
I figured this out. Core Data sends out several separate ContextDidChange notifications in response to a single - mergeChangesFromContextDidSaveNotification call. I had a dumb bug in my code that resulted in me only seeing the first one. The object where I was debugging ContextDidChange notifications (and doing my caching) was the very one I was getting the first refreshed notification for — and I was removing it as a notification observer in its -didTurnIntoFault. So it would get turned to a fault first thing when merging the save notification, unregister itself as a result, and then no longer behave as intended. I moved the notification center unregistration to -dealloc, and now I can see that my merge does result in all the expected insertions, just with separate notifications. Hope this can help someone else realize that Core Data doesn't (necessarily) hate them if they come across my original post. -natevw On Jan 16, 2009, at 2:02 PM, Nathan Vander Wilt wrote: My application imports into an NSManagedObjectContext created on a background thread. As the last stage of this import, I save the background context to the persistent store. All my UI code uses a managed object context on the main thread, and expects to be notified via NSManagedObjectContextObjectsDidChangeNotification to update caches and redisplay. So... in my background thread I catch the NSManagedObjectContextDidSaveNotification and pass it to a method called on the main thread to - mergeChangesFromContextDidSaveNotification: in the main context. Now I would expect that all the objects I inserted into the background context would get inserted into the main context, and I would see evidence of this in the ObjectsDidChange notification. While the save notification has @inserted and @updated sets with the expected objects, the change notification only contains the updated object in its @refreshed set, and no inserted objects. Is this what I should expect? Is there a better way I can trigger the ObjectsDidChange notification on my main context after another context updates the persistent store? Or, taking things a step back, what's the best way to keep Core Data fetch request results up-to- date? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
mergeChangesFromContextDidSaveNotification effects
My application imports into an NSManagedObjectContext created on a background thread. As the last stage of this import, I save the background context to the persistent store. All my UI code uses a managed object context on the main thread, and expects to be notified via NSManagedObjectContextObjectsDidChangeNotification to update caches and redisplay. So... in my background thread I catch the NSManagedObjectContextDidSaveNotification and pass it to a method called on the main thread to - mergeChangesFromContextDidSaveNotification: in the main context. Now I would expect that all the objects I inserted into the background context would get inserted into the main context, and I would see evidence of this in the ObjectsDidChange notification. While the save notification has @inserted and @updated sets with the expected objects, the change notification only contains the updated object in its @refreshed set, and no inserted objects. Is this what I should expect? Is there a better way I can trigger the ObjectsDidChange notification on my main context after another context updates the persistent store? Or, taking things a step back, what's the best way to keep Core Data fetch request results up-to-date? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSCalendar/NSDate - generating all months/days in a year
On Dec 22, 2008, at 4:53 AM, Keith Blount wrote: Hi, Apologies in advance for what I think must be a basic question. It's something I've never had cause to do before, assumed must be fairly straightforward, and then seemed a lot more complicated than it should be which leads me to think that I am using the wrong search terms... All I want to do is this: I would like to generate the names of all the months for a specified year. Then for each month in that year, I would like to generate the names of every day. For instance: 2009 - January -- Thursday, 1st January 2009 -- Friday, 2nd January 2009 ... and so on - February -- ... etc. I seem to be looking in the wrong areas in the frameworks, though. I thought NSDate and NSCalendar would be the place to look, but both seem overly complicated for this purpose. As far as I can see, in order to use NSCalendar to do this, I would have to do the following: I would not agree with the other two posters on this, though their solutions should work in practice for your situation if you don't need anything general purpose. Otherwise, NSCalendar is your friend; if you find yourself typing something like January = 31 or 6 = Friday or 60 * 60 * 24 in your code you're likely duplicating its functionality without getting any of its benefits (language issues, and political issues like daylight savings, leap years, leap seconds, etc.) The way people label time is a complicated, changeable thing, best to let the operating system handle it for you. 1) Start with a January NSDate in the specified year. [the following code is all typed up in Mail, so may not be quite working] Sounds good, and if you know the year the easiest way would be: NSDateComponents* components = [[NSDateComponents alloc] init]; [components setMonth:1]; [components setYear:specifiedYear]; [calendar dateFromComponents:components]; Otherwise, if you have a date within the year: NSDate* startOfYear = nil; [calendar rangeOfUnit:NSYearCalendarUnit startDate:startOfYear interval:NULL forDate:dateWithinYear]; 2) Get number of months for that year using [calendar rangeOfUnit:NSMonthCalendarUnit inUnit:NSYearCalendarUnit forDate:january] (given that the app is only for personal purposes for now, I could just assume 12 for this part). You could do this, or just iterate as described below until the year changes. 3) Get number of days in each month by using [calendar rangeOfUnit:NSDayCalendarUnit inUnit:NSMonthCalendarUnit forDate:january] and then adding on a month (though how to do that? - NSTimeInterval is in seconds and there are different numbers of days in each month...) to get the number of days for each month. You can easily add on a month or day at a time using NSDateComponents and calendar. You can either use NSCalendar's - dateByAddingComponents:toDate:options:, or what I might do is take the component you might have made (or can get) from the original year +January and add days directly to that. NSCalendar can handle overflow, so you can have an NSDateComponent that says something like Year:2008 Month:1 Days:364 and you will get the right date from components. (Which you can then convert back to normalized components if you want to, say, check if the month has changed since the last day.) 4) Use NSDateFormatter to format the date for display (I'll have to do that part no matter what method I use). Yes, among other benefits, this saves you from having to localize all the month names and such yourself. Steps 1-3 seem needlessly complicated and error-prone, though, which leads me to suspect I am taking completely the wrong approach and missing the blindingly obvious. Is there a better way of doing this? I think your steps were on the right track, I've just tried to point out some other helpful methods. NSCalendar is not always exactly intuitive or succinct to use, but it does a LOT for you and even if this project is simple, getting familiar with it now will be a win if you ever do something needing more accuracy in the future. hope this helps, –natevw___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: warning: unused parameter '_value'
On Dec 22, 2008, at 4:42 AM, Gerriet M. Denkmann wrote: When I use [GCC_WARN_UNUSED_PARAMETER, -Wunused-parameter] I get (in Release build, not in Development) for every @synthesize statement a warning: warning: unused parameter '_value' There is no value nor _value in the source to be found. What am I doing wrong? Xcode Version 3.1.1; gcc 4.0; 10.5.6 This was a bug in the compiler until gcc 4.2: http://lists.apple.com/archives/objc-language/2008/jul/msg00043.html If you're able change your compiler setting at this point in development, that's the easiest fix. -nvw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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 binary data optimization(s)
Thanks to some patient help from this list, I now have a working Core Data model. One object in the model is basically a glorified vector polygon — an array of point structures that contain a about a dozen doubles each. I insert a lot of these polygon objects, and often need to draw all of them very quickly. I originally included the point structures themselves in the model, with a to-many relationship from each polygon to the points, and sorted the points to their proper order in memory when necessary. This was a bit slow, as Core Data seemed to fault each point object individually, resulting in a lot of query overhead. So I switched my polygon objects to have only one attribute: binary data for the point. I thought this would result in significant speedup, but Core Data faults my objects so often that now I spend even more time unarchiving each polygon's point data than it took to read each point's row in from the database! I've thought about caching the result of my get all polygons fetch to speed up redrawing, plus further optimizing my archiving code to help initial load and final save speed. If I do this, my thought was to watch the MOCObjectsDidChange notification for inserted/deleted objects and update my cache when necessary. (By my understanding, the updated objects will already be updated at my cached pointers.) This seems a little icky, though. Does Core Data provide a cleaner way of efficiently keeping a fetch result up-to-date? Another issue with dealing with the points via a binary data archive is the wasted memory. These polygons would be immutable if Core Data allowed such a thing, so it seems especially wasteful to keep the unarchived copy of the point array and the persistent data blob both in memory. If I model a (prefetched) to-one relationship to the polygon's binary data instead of an attribute, and [moc refreshObject:binaryData mergeChanges:NO] once unarchived, will this make it fairly likely I'll only have my unarchived copy of the point array data in memory? Or are the the above optimizations a bad approach to solving this problem? I'd like to get a little closer to the terabyte sized database with billions of rows/tables/columns advertised in the performance section, but it seems that statement assumes I'm fetching only a small fraction of those rows at once. For flat primitive data like this, is it possible to get performance closer to a raw push of the data to/from disk with Core Data? thanks, -natevw___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: Drag Drop: PREVENT file move
On Dec 11, 2008, at 3:11 PM, Houdah - ML Pierre Bernard wrote: Hi! My application shows a list of files in a table view. I have implemented drag and drop so that users may drag files from the list. I could envision them dragging the files onto other applications for viewing or dragging them on a removable media to create archive copies. The problem occurs when the user drags the file to another folder on the same disk. By default, the Finder then wants to move the file. I need to prevent just that as it will cause havoc. For one, I would lose track of the file. Is there a way for the originating application to control the allowed drag operations? Check out NSDraggingSource protocol's - draggingSourceOperationMaskForLocal:. You should be able to return something like (NSDragOperationCopy | NSDragOperationLink) if you want to make sure the original file stays in the same place. If you don't mind the file being moved so long as you know its no longer available, you could instead implement -(void)draggedImage:(NSImage*)anImage endedAt:(NSPoint)aPoint operation:(NSDragOperation)operation to be notified when a move/delete is completed. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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 warning: to-many relation does not have an inverse
Sorry if this ends up showing twice, but the original message has been
moderator-queued for length since early this morning. Being several
steps behind in even *asking* Core Data questions has been frustrating
me all day, as I try to press on in no less ignorance than yesterday.
On Dec 11, 2008, at 2:38 AM, Ben Trumbull wrote:
Consultant.interestingEmployees -- to-many relationship does not
have an inverse: this is an advanced setting (no object can be in
multiple destinations for a specific relationship)
[snip]
It says no object can be in multiple destinations for a specific
relationship (no inverse relationship, btw, fully modeled
relationships don't have this issue, because they're fully
modeled). If you have Department 0- People (no inverse to many to
People) with D1 and D2 being department objects and P1 being a
Person, you cannot have both D1-{ P1 } and D2- { P1 } If
Department had several no inverse to-many relationships to People,
like goodPeople and lazyPeople, then P1 could belong once in each
across all the Department objects.
It means you cannot pretend your no inverse to-many is like a many-
to-many relationship. If you try, you'll corrupt your data, and we
told you not to. You explicitly failed to model the part we needed
to verify whether or not your schema is correct, so this was as
helpful as we could be about your future undefined intentions.
If you sit down and think about how one implements many-to-many
relationships in a database, it should be clear why this is the
case. If that didn't make sense, then please, just model the
inverse like the compiler is suggesting.
this is an advanced setting == if you didn't understand this
message, you're going the wrong way. Otherwise, you're probably
going the wrong way
I apologize if there was something in my previous message that
suggested I thought the warning, and not my model, was wrong. However,
I would like to figure out what makes my way the wrong way, and what
the right way would be.
I hope that by corrupt data in the case of a many-to-many
relationship, you mean that if one isn't careful they may end up with
a row that links a foreign key from one table to a non-existent key in
another. In that case, I am not too worried, unless I should be? I am
already managing my object graph and undo management on my own, and
mostly need to use Core Data so that when I'm using the SQLite store I
don't have to overwrite the entire graph on disk if few or no objects
have actually changed. I am willing to improve my model's architecture
where it is incompatible, but if Core Data will bail out if I ever try
to cross a particular street on my own, I'll need to learn which
streets to avoid and why.
The other problem is that I do want to define an inverse for
Employee.company, but I can't set it to *both*
Company.currentEmployees and .previousEmployees. [snip]
Why are you trying to solve that problem ? In the obvious case,
Employee.company needs to be the inverse for currentEmployees
because it's the current company, and the alternatives semantically
don't make any sense. Then, previousEmployees has a separate
inverse, if only for bookkeeping purposes (e.g. so Core Data
maintains everything for you)
If you're trying to model companies and employees having an audit
record all of their previous employments, then you need to do that
explicitly instead of trying to be too clever. I'd recommend a many-
to-many relationship between Employee and Company for previous
employers to match previous employees. You could go with
lastPreviousEmployer and make it a one-to-many.
Maybe I need to clarify my model a bit. Just to be clear, all names
have been changed to protect the innocent and any resemblance to a
real Company with real Employees is unintentional. Perhaps it would
help to tweak my example a bit.
The odd thing about my Company is that it likes to move Desks
around. So when an Employee comes in for work, he must ask the
Company where his Desk is that morning. There are really three
kinds of Employees, Outgoing, Current and Interesting. In order
to be Interesting, an employee must also be Current. The Outgoing
Employees still need to be be able to ask the Company where their Desk
is, so they can clean their stuff out of the drawers before they say
goodbye.
The reason I want to implement Outgoing and Current as
relationships from a Company and Interesting as a relationship
from a separate Consultant is for performance and for information
hiding. Employees aren't in charge of whether they're Outgoing/Current
and don't need to know if they're considered Interesting. Further, the
Consultant shouldn't have to know all Employees, just the interesting
ones. Organizing it this way also means I have a ready-to-go list of
each type, so I don't have to filter down to, say, all Current
Employees come payday (which can
Re: NSKeyedArchiever and XML Format
On Dec 11, 2008, at 1:01 AM, Patrick Mau wrote: Good morning For the last day I have pulled my hair over NSKeyedArchiever and friends to load and save small data objects. I mainly use this feature for debugging, so the output format is set to XML. Normally, one would write an object 'p' in binary format, using: [NSKeyedArchiver archiveRootObject:p toFile:@/Users/mau/Desktop/ archiveRoot.plist]; Reading the object again would be done using: p = [NSKeyedUnarchiver unarchiveObjectWithFile:@/Users/mau/ Desktop/archiveRoot.plist]; To set the output format one cannot use the convenience methods above, but the following: NSMutableData *data = [NSMutableData data]; NSKeyedArchiver *a = [[NSKeyedArchiver alloc] initForWritingWithMutableData:data]; [a setOutputFormat:NSPropertyListXMLFormat_v1_0]; [a encodeObject:p forKey:@root]; Does using: [a encodeRootObject:p]; instead of the line above make it work as expected? [a finishEncoding]; [data writeToFile:@/Users/mau/Desktop/encodeRoot.plist atomically:YES]; [a release]; hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSKeyedArchiever and XML Format
On Dec 11, 2008, at 5:34 PM, Martin Wierschin wrote: [a encodeObject:p forKey:@root]; Does using: [a encodeRootObject:p]; instead of the line above make it work as expected? A good idea, but IIRC that did not work. In fact, I think it produced an archive that silently failed to be read back by the stock +[NSKeyedUnarchiver unarchiveObjectWithFile:] convenience method. While the documentation for that method itself makes no mention of that fact, the documentation at http://developer.apple.com/documentation/Cocoa/Conceptual/Archiving/Tasks/decoding.htm does say NSKeyedUnarchiver requires that the object graph in the archive was encoded with one of NSKeyedArchiver’s convenience class methods, such as archiveRootObject:toFile:. I'm not sure offhand why this would be, and it is a bummer, but the workaround is to just do the unarchiving symmetrically to the archiving, that is read the file into an NSData and then unarchive that using -decodeObject (or - decodeObjectForKey: if you encode with your own root key(s) after all). I'll note that I haven't tested this myself again, but that seems to be what the documentation is saying. -natevw___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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 warning: to-many relation does not have an inverse
I'm trying to port my model code to use Core Data. My model is something like this: I have a Company. It has two to-many relationships, currentEmployees and previousEmployees which are naturally both to Employees. Employees have a to-one relationship to the Company that is the inverse of both the currentEmployees and previousEmployees. That is, the employee (records) belong to the Company regardless of current/ previous status. I also have a Consultant. It has a to-many relationship to interestingEmployees. Nobody talking to an Employee needs to have access to the Consultant, so there is no inverse relationship. I have two problems with this model. When I compile it, I get a warning: Consultant.interestingEmployees -- to-many relationship does not have an inverse: this is an advanced setting (no object can be in multiple destinations for a specific relationship) This error doesn't make sense to me. Is it trying to say an object can only belong to one to-many relationship? The other problem is that I do want to define an inverse for Employee.company, but I can't set it to *both* Company.currentEmployees and .previousEmployees. I think the answer is to maintain the Employee.company relationship field myself without any inverse, but then I get two more warnings for each of the Company to- many relationships. This model was easy to implement in Foundation, I just created a bunch of Employee objects and just made sure they were in the proper sets (current/previous/interesting). I suppose I could model this by just having the current/previous and interesting/not interesting status be properties of the Employees themselves, but I'd prefer that A) Employees don't have access to these statuses and B) that my Company/Consultant can have tidy sets of relevant Employees. What's the best way for an object to be belong to multiple to-many relationships in Core Data? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Problem setting a Core Data Document Icon
On Dec 10, 2008, at 5:38 PM, vince wrote: I can't seem to set a default icon for my supported docs in a Core Data project. The .icns file is in my Bundle and placed in the Resources bin. I manually inserted the file name in the Target's Supported Document field. I rebooted my system a few times since and still no changes to the newly saved files. When you say you inserted the file name in the Supported Document field, did you include a Name for the document type, a UTI or Extensions (without leading dots) so the system can associate your specific file with the icon, and then also an Icon File name? You may also need to make sure your Target itself has a valid Identifier. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Shouldn't NSOpenPanel media browser aliases be resolved before type check?
On Dec 2, 2008, at 8:06 AM, Corbin Dunn wrote: Le Dec 1, 2008 à 5:32 PM, Nathan Vander Wilt a écrit : My Leopard-only application needs to be able to import any image supported by CGImageSource, so I create an NSOpenPanel and pass the array obtained from CGImageSourceCopyTypeIdentifiers() to runModalForTypes. This makes the Media Photos sidebar to show up automatically in the Open panel, which is great. However, seemingly random pictures in the iPhoto section of this Media Browser are greyed out. I tracked it down, and the problem is that when iPhoto creates an alias to an original file, this is not automatically resolved. (My OpenPanel does leave -resolvesAliases set to YES.) So the type of these random pictures is com.apple.alias-file instead of public.jpeg or any other image format, and the media panel doesn't let me choose these original files even though their aliases would resolve to supported types. Shouldn't these aliases be resolved before type checking, so that the CGImageSource type identifiers can be used in an open panel without needing custom delegate filtering? Yes, it should -- can you please log a bug? If possible include steps for how to create the aliases. Glad to hear it, the bug is rdar://problem/6410673 and should already have some info on how to reproduce. Please let me know if there's anything more you need. In the meantime, I've worked around this by having the NSOpenPanel accept kUTTypeData to get all files plus kUTTypeJPEG to trigger the photo media browser, then in my own -panel:shouldShowFilename checking the target types plus resolving and rechecking any kUTTypeAliasFile types that slip through at present. thanks, -natevw___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Shouldn't NSOpenPanel media browser aliases be resolved before type check?
My Leopard-only application needs to be able to import any image supported by CGImageSource, so I create an NSOpenPanel and pass the array obtained from CGImageSourceCopyTypeIdentifiers() to runModalForTypes. This makes the Media Photos sidebar to show up automatically in the Open panel, which is great. However, seemingly random pictures in the iPhoto section of this Media Browser are greyed out. I tracked it down, and the problem is that when iPhoto creates an alias to an original file, this is not automatically resolved. (My OpenPanel does leave -resolvesAliases set to YES.) So the type of these random pictures is com.apple.alias-file instead of public.jpeg or any other image format, and the media panel doesn't let me choose these original files even though their aliases would resolve to supported types. Shouldn't these aliases be resolved before type checking, so that the CGImageSource type identifiers can be used in an open panel without needing custom delegate filtering? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Can I put UTIs in NSFilesPromisePboardType promise drag array?
So I was reading through the Leopard AppKit release notes today, and stumbled across the Support for UTIs in NSView and NSWindow (a few sections below http://developer.apple.com/releasenotes/Cocoa/AppKit.html#UTIs) . It states: NSView's -dragPromisedFilesOfTypes:fromRect:source:slideBack:event: method now accepts UTIs as type strings, in addition to the sort of file name extensions that were accepted in Mac OS 10.4. So it looks like there is NOT any reason to build an NSFilesPromisePboardType array out of UTIs on 10.5+ after all! I've filed yet another why is this only buried in the release notes?!? bug on the documentation: rdar://problem/6332711. thanks, -natevw On Oct 1, 2008, at 2:27 PM, Nathan Vander Wilt wrote: I am initiating a promise drag by adding an array of strings to my pasteboard using for the NSFilesPromisePboardType. The documentation states that the types can be specified as filename extensions or as HFS file types encoded [as strings]. Is there any reason to not build an array of UTIs instead? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/nate-lists%40calftrail.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Can I put UTIs in NSFilesPromisePboardType promise drag array?
On Oct 1, 2008, at 3:09 PM, Jim Correia wrote: On Oct 1, 2008, at 5:27 PM, Nathan Vander Wilt wrote: I am initiating a promise drag by adding an array of strings to my pasteboard using for the NSFilesPromisePboardType. The documentation states that the types can be specified as filename extensions or as HFS file types encoded [as strings]. Is there any reason to not build an array of UTIs instead? I don't believe that works. I thought I filed a bug about it, but cannot quickly locate it. If you find definitively one way or the other, I'd appreciate your discovery. (It would require special support in the pasteboard for translation because legacy clients would only expect the extension or HFS type. Even just the extension is problematic for Carbon clients.) Thanks for the advice, I've taken the liberty of posting back to the list as well. I haven't experimented a ton, as the Finder and iPhoto both seem to accept (at least initially, in the case of iPhoto) any promise drag regardless of what I stuff into the array, and I hadn't many ideas of other programs to try it on. Despite Postel's principle, I'm tempted to use UTIs anyway, at least until we get bug reports of our app not playing nicely with another. HFS types seem to be well deprecated in nearly every other area, the drag destination guides don't encourage checking the types anyway, and the API itself doesn't facilitate easy checking especially given the fact that strings already are *either* extensions or legacy type codes with no programmatic distinction. Plus who really wants to keep comparing strings (eg 'txt' vs. 'TXT' vs. 'TEXT' times every other supported format) when they could be using UTTypeConformsTo instead? :-) thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Can I put UTIs in NSFilesPromisePboardType promise drag array?
On Oct 4, 2008, at 8:31 PM, Jim Correia wrote: On Oct 4, 2008, at 10:45 PM, Nathan Vander Wilt wrote: HFS types seem to be well deprecated in nearly every other area, the drag destination guides don't encourage checking the types anyway Can you post a reference? You generally should check the type in the drag, and not offer to accept a drag which you can't accept. As to HFS types being deprecated, the documentation at http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html says they were originally designed for Mac OS 9 and earlier. Beyond that, I think I'll have to mostly concede this point. You are right that the HIG encourages rejecting drags based on file types (though in the case of a non-promise drag this can take an extremely non-deterministic amount of time). For what it's worth, the sample code at http://developer.apple.com/documentation/Cocoa/Conceptual/DragandDrop/Tasks/DraggingFiles.html does not check types, but the text above does mention The destination can then accept or reject a drag operation based on the contents of the types array. and the API itself doesn't facilitate easy checking especially given the fact that strings already are *either* extensions or legacy type codes with no programmatic distinction. Due to the convention for how HFS types are encoding, it is possible to programatically distinguish the two, if you need to do so. I'm not sure what you mean here. The documentation for promise drags says to encode the OSType using NSFileTypeForHFSTypeCode() which in my testing just turns the characters the programmer sees in their source into a string (ie 'uint' becomes @uint). As extensions could be any number of characters, how would I know if docx is the exension of a new Office document or maybe some old OSType code registered decades ago for a totally different format? Plus who really wants to keep comparing strings (eg 'txt' vs. 'TXT' vs. 'TEXT' times every other supported format) when they could be using UTTypeConformsTo instead? :-) Nobody really wants to keep supporting legacy standards when there are new better ones. However, if you want to interoperate with stuff which uses those legacy standards, you have to. Until such time as NSPasteboard does implicit translation of UTIs put in NSFilesPromisePboardType, any client only expecting to see traditional types might fail. Only you can decide if you need to interoperate with such clients. As it turns outs, I've hedged my bets. I conservatively only put traditional types when writing NSFilesPromisePboardType, but correctly handle UTIs when receiving the drag. I don't know how many other clients are as flexible. What initially bothered me about the lack of UTI support was that I have no idea what the HFS types were, except for 'GIFf' and 'TEXT' which show up as canonical OSType examples throughout the docs. Of course, since I can use extensions that's mostly a a non-issue, though I do wonder what I'd do if another app gives me HFS types instead of extensions. You're probably right, though, if I'm the only one putting UTI strings into the promise array it might as well be haiku or ASCII art instead. thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Can I put UTIs in NSFilesPromisePboardType promise drag array?
I am initiating a promise drag by adding an array of strings to my pasteboard using for the NSFilesPromisePboardType. The documentation states that the types can be specified as filename extensions or as HFS file types encoded [as strings]. Is there any reason to not build an array of UTIs instead? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Changing slide back destination during drag
I have a view that allows users to drag copies of the items it contains. I'd like to add autoscrolling to the view, which will move the drag's source item. However, I can find no way to change the drag properties so that upon failure the image will slide back to where the item *is* rather than where it *was* before the view autoscrolled. I did find the NSDraggingInfo protocol's slideDraggedImageTo: which I suppose I could have called in my draggedImage:endedAt:operation: dragging source method. But this method is a strange one! The Leopard release notes state the following: -[NSDraggingInfo slideDraggedImageTo:] is now implemented to behave as documented. This change is enabled only for applications built on Leopard or later to avoid changing behavior of older binaries in ways that may be incorrect. So it's working as documented which would be great, but the documentation says it's deprecated (as of Leopard!) with no alternative method! Was -slideDraggedImageTo: really deprecated in the exact release it was also fixed? Or are the release notes just making a little joke (it now behaves as...deprecated)? (And even if it weren't deprecated, would it have enabled me to do what I want?) thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Hard calculation crashes after 60Minutes
On Aug 30, 2008, at 8:08 PM, Mr. Gecko wrote:
Hello I am making a program that does a really hard calculation and
it seems to crash after 60 Minutes. I don't really know why it does,
I am guessing it is because I am using a for loop that takes awhile
to run
If you can't find any leaks, it may be that autoreleased objects are
not really leaking, but your code does not give the framework-
supplied autorelease pool a chance to release the objects it owns. You
should create a pool of your own around the top and bottom of your
loop's block:
for (long_time) {
NSAutoreleasePool* myPool = [NSAutoreleasePool new];
// do stuff
[myPool release]; // or you could use [myPool drain] if
on 10.4+
}
hope this helps,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Undocumented Leopard support for overlapping sibling views
According to two list postings (http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01760.html , http://lists.apple.com/archives/cocoa-dev/2007/Nov/msg01764.html) both by Apple employees, overlapping sibling subviews are fully supported in Leopard (and presumably beyond). However, the official documentation (http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/chapter_5_section_5.html ) still says: Cocoa does not enforce clipping among sibling views or guarantee correct invalidation and drawing behavior when sibling views overlap. If you want a view to be drawn in front of another view, you should make the front view a subview (or descendant) of the rear view. And Interface Builder 3.1 on the one hand has options like Layout Send to Front that change the ordering of subviews, yet on the other still warns about Illegal geometry when a view overlaps one of its siblings even when the deployment target is set to 10.5. I can't find anything in the documentation (or even release notes) that describes that/how overlapping views are supported. Why isn't this documented? Can we rely on overlapping sibling views working now and in the future? Are there any caveats we should be aware of? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Undocumented Leopard support for overlapping sibling views
On Aug 28, 2008, at 2:40 PM, Corbin Dunn wrote: Please do log bugs requesting the documentation to be enhanced. Overlapping views do work in Leopard+, with or without layers. However, a sibling layered view will always be on top of a sibling non-layered view. I will do so, as well as a bug against Interface Builder for suppressing geometry warnings on platform(s) that support overlapping views. One further clarification, is the top view for drawing always the top view for event handling, especially with regards to layered/non- layered? How does -[NSView hitTest:] behave when multiple subviews are under a given point? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Convert unicode string into ascii
On Aug 28, 2008, at 3:48 PM, I. Savant wrote: On Aug 28, 2008, at 6:36 PM, Deborah Goldsmith wrote: I should point out that you can only write English with a-z, so I don't know if I'd consider the other characters weird. Not to mention characters like ¥, ©, and so on. Here's an enlightening article on the subject you might find useful: http://www.joelonsoftware.com/articles/Unicode.html Actually, Deborah just recently deprecated that article and provided some much more accurate alternatives: http://lists.apple.com/archives/cocoa-dev/2008/Aug/msg00940.html Unicode is not something you want to oversimplify. -nvw___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Obtaining rotation from CTM
On Aug 21, 2008, at 6:56 AM, Tilman Bender wrote: Hi there, Is it possible to obtain the angle of rotation from a tranformation- matrix created with CGAffineTransfrom? If you haven't applied any other transforms to your CGAffineTransform, you could determine the rotation (in radians) via: double rotationInRadians = acos(theTransform.a); // if the transform ONLY rotates around the origin My linear algebra is fairly rusty, so I may be forgetting some things, but I don't think it's practical to determine in the general case when you've also scaled and translated back and forth besides just rotating. A few cases will not affect the result above, but in most cases used in drawing, the above will probably not work. But I'm not sure why you'd need to do this in the first place, see below... Background: I am building a simple kitchen-timer app, that should work like the ones in your mom's kitchen: You set the time by touching a control and rotating it. Now I would like to obtain the current angle of my clock. I know how to use and create CGAffineTransform stuff, but I am not really familiar with the extraction of specific information from such a matrix. My question is: why do you need to get the rotation out of an affine transform? Somewhere in your code you've determined an angle from a move event, I would assume. It would make a lot more sense to keep track of the current angle, and only convert that to a CGAffineTransform in your drawing code, than to for some reason store a CGAffineTransform and try to extract the angle from that. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Memory Leaks Instruments Questions
On Aug 10, 2008, at 12:37 PM, Michael Kaye wrote: I've ben running my app with leaks in Instruments and it is reporting a fair number of leaks. On analyzing these leaks, they all appear to be related to apple frameworks methods/code and never as a direct result of any objects I've instantiated. Therefore my question is, is whether this is correct and what you would normally expect to see? Or are the leaks indirectly caused by something I am doing? If the former should I just ignore them and if the latter how do I track down exactly where it is occurring. While I have seen an occasional report of a leak from the run loop throughout a really long (~20 minutes) analysis session, if you have a fair number of leaks I think its safe to assume they are of your doing. A couple tips: - If you are viewing the list of allocations for a particular block, oftentimes you may see a whole lot of framework activity in the history. Remember that the last line is the only one that leaked. - While tracking down a couple hard-to-find leaks last week, I found the Outline View with Invert Call Tree to be quite helpful. It not only shows the root functions that leaked (eg malloc), but allows you to look and see what all called that and leaked, and so on. That way you can move up past the frameworks to see which of your functions are calling the low-level stuff. - If your program is still running, you can double-click a leaking method/function to pull it up in Xcode for further scrutiny. Of course this only works for what you have source code access to, that is, your own methods. I'm not sure why it only works when running, YMMV on that. Whilst we are on it, I have a second question and that is whether should I expect any singleton object to appear as a memory leak in Instruments. Obviously the point of a singleton is is that it has one instance and any instance variables exist with no dealloc. So does Instruments handle this or just report them as a leak? To be useful, a reference must be kept to the singleton. As long as this reference is kept, it has not leaked. A leak is when an object/ memory is allocated, but then all references to the object are lost. In this scenario there is no way to release/autorelease/free it anymore, ever, so it has leaked. But when there is still a reference to an object, Leaks will assume you are waiting to release it later. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Rotate NSString... I give up :( [SOLVED]
On Aug 6, 2008, at 2:08 PM, Vitaly Ovchinnikov wrote: Yes, you right, but I expected what I need to move text to the zero point, rotate it and move it back. But NSAffineTransform works quite the contrary and requires to move the zero point to the text and then back. That was a big surprise for me. Remember that affine transforms are of the form v' = Mv. So if you want to transform a vector by a matrix: v' = Mv ...and then by another matrix: v'' = Nv' But if you want to do it all in one step, you would do: v'' = NMv See how it's not MNv but NMv? What this means is that you must concatenate your transformation matrix in the opposite order of how you want it to transform your points. I'd agree this is surprising, I myself spent a long time one day trying to debug NSAffineTransform just on account of forgetting this relationship. hope this helps, -natevw On Thu, Aug 7, 2008 at 12:55 AM, Kyle Sluder [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 4:37 PM, Vitaly Ovchinnikov [EMAIL PROTECTED] wrote: Yes, he right. I've just tested it and it works fine. I though that -translateXBy:yBy: will move my object, but it moved pivot point... This is hard, especially with revesed OY axis ;) Well, it all happens in one transformation matrix. If I recall matrix math correctly (probably not), rotation is a linear transformation, but translation isn't, so in order to get rotation to work right the pivot point must be the origin. Since you want to rotate the object around its center, you need to translate it twice. This is all chained together in one transformation matrix, so when the multiplication's done the net result is one matrix that does all three operations. Anyone, please feel free to correct me, I would very much appreciate any clarification. :D --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/nate-lists%40calftrail.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Storing values in dictionary with their address as the key
What about using CFDictionary ? You can create a dicitonary with a
callback that support address (NULL for example).
I'll echo this; it's a really handy technique that I use frequently
(you can even use integers as keys!).
WARNING: Just in case, there is a major warning here. You should
avoid NS/CF bridge when inserting/removing value in a dictionary as
the semantic is not the same. NSDictionary always try to copy the
key whatever the calback is (or at least did it the last time I try).
Right, -[NSDictionary setObject:forKey:] on a CFDictionary created
with a custom retain callback will invoke copyWithZone: before
calling your retain callback. Apple claims this is not a bug.
Getting/removing values with objectForKey:/removeObjectForKey:
should work, though; if it doesn't, I'd like to know.
Yes, accessing and removing keys should work fine. For immutable keys
(you weren't planning on changing a key behind NSDictionary's back
anyway, right) a copy is often just implemented as a retain. Since
toll-free bridged NSDictionary must provide CFDictionary retain/
release callbacks to work right on the Core Foundation side of things,
it must be copying the key, adding it to the array (where it is
retained by the callback), and then releasing it's local reference.
Take out steps one and three, which are equivalent to a retain
followed by a release, and nothing should change as far as object
accessing or removal.
While for new code in Leopard+ apps you might want to look into
NSMapTable with the flags Mike suggested, I just was dealing with
NSMutableDictionary's key copying off-list last night and didn't see
that suggestion. What I did is just added a category on
NSMutableDictionary:
@interface NSMutableDictionary (TLMutableDictionaryNoncopiedKeys)
- (void)setObject:(id)anObject forUncopiedKey:(id)aKey;
@end
@implementation NSMutableDictionary (TLMutableDictionaryNoncopiedKeys)
/* NSMutableDictionary copies its keys. When we use pointer-equality
for certain types' comparision,
this breaks those types' keys. Fortunately, CFMutableDictionary does
not assume NSString-ish keys,
and the copying behaviour is implemented within the -
[NSMutableDictionary addObject:forKey:]
method itself (see http://www.cocoabuilder.com/archive/message/cocoa/2008/4/2/203028
and links
for details).
If we just bridge to Core Foundation when adding keys, everything
else should work properly.
*/
- (void)setObject:(id)anObject forUncopiedKey:(id)aKey {
CFMutableDictionaryRef selfCF = (CFMutableDictionaryRef)self;
Boolean keyAlreadySet = CFDictionaryContainsKey(selfCF, aKey);
if (keyAlreadySet) {
CFDictionaryReplaceValue(selfCF, aKey, anObject);
}
else {
CFDictionaryAddValue(selfCF, aKey, anObject);
}
}
@end
Replacing this single method was enough for me, since in most cases in
my code where the stringish (that is, assuming copied keys will
still compare equal) behaviour is not desirable, I am creating an
empty dictionary and populating it with just that one method.
Otherwise, many other methods (especially NSDictionary's initializers
and convenience initializers) would all need uncopiedKey overrides,
and some of these could theoretically end up being much less efficient
than the methods they replaced. However, if you can't use just the
above method to insert keys, then other solutions like CFDictionary
and NSMapTable (especially) might not work much better for you
anyway...so this seems like a pretty decent solution for many cases.
hope this helps,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Storing values in dictionary with their address as the key
On Jul 29, 2008, at 8:58 AM, Nathan Vander Wilt wrote: Right, -[NSDictionary setObject:forKey:] on a CFDictionary created with a custom retain callback will invoke copyWithZone: before calling your retain callback. Apple claims this is not a bug. Getting/removing values with objectForKey:/removeObjectForKey: should work, though; if it doesn't, I'd like to know. Yes, accessing and removing keys should work fine. For immutable keys (you weren't planning on changing a key behind NSDictionary's back anyway, right) a copy is often just implemented as a retain. Since toll-free bridged NSDictionary must provide CFDictionary retain/release callbacks to work right on the Core Foundation side of things, it must be copying the key, adding it to the array (where it is retained by the callback), and then releasing it's local reference. Take out steps one and three, which are equivalent to a retain followed by a release, and nothing should change as far as object accessing or removal. Actually, that category thing is a no-go if you intend to archive your dictionary! I repeat: beware of the code I posted thread previous! While this is an implementation detail that could change, - [NSDictionary initWithCoder:] calls some internal dictionary class's - initWithObjects:forKeys:count: that also copies the keys. This leads me to suspect that NS[Mutable]Dictionary may recopy keys in other places at whim as well. I am not sure what happens if you try to unarchive a CFDictionary that was archived as an NSDictionary, but I've got better things to do than mess with a class that clearly was not designed for what I'm trying to use it for. If you want to use non-copied/pointer-equivalent objects as keys, especially if there is any chance you're going to be doing any archiving, skip NSMutableDictionary. Use NSMapTable instead, which thankfully also supports NSCoding. hth, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Handling key equivalents in a controller class?
Jens – I've been wanting to do similar key handling in my controller class (rather than view classes), so I'm glad I'm not the only one not fully grokking the responder chain. I got some helpful responses to my more specific question, but without loss of generality. Especially: http://www.cocoabuilder.com/archive/message/cocoa/2008/7/9/212381 My takeaway from that experience was that if I need custom event responding, I need my own NSResponder inserted somewhere in the chain. It makes sense, but coming from the other direction (I want to handle some events in my controller) it's tempting to look for another way that doesn't seem to exist. hth, -natevw On Jul 19, 2008, at 12:34 PM, Jens Alfke wrote: On 19 Jul '08, at 8:52 AM, Matt Neuburg wrote: Try it and see. Let's say we want to catch Esc directed to the window as a whole (to exit full screen mode, if I recall your example). So what I would do is to insert an NSResponder instance behind the window in the chain and implement keyDown:. I had already tried implementing keyDown: in my controller object, which is the window's delegate, to no avail. But that class is just a direct subclass of NSObject, not NSResponder or NSWindowController. I tried changing its superclass to NSResponder, but that didn't help. Looks like I need to read up on the conceptual docs about the responder chain, to figure out how to make my object the window's next responder. (I've never manipulated the chain directly before.) When an event arrives (arrives! It got here by being handed up thru all the views and the window, which therefore clearly didn't handle it), we look to see if it's for us - i.e., is it Esc or not. If it is, we tell the window to do what it's supposed to do, and the event is not handed any further up the responder chain. If not, we pass the event to super and the event is handed on up the responder chain in the usual way, That makes sense. I had been thinking that event handlers would need a boolean return value to indicate whether or not they handled the event, but I'd overlooked the behavior of calling super to pass the event up. Thanks! —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/nate-lists%40calftrail.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Delete action from variety of key presses
On Jul 7, 2008, at 5:07 PM, Graham Cox wrote:
The view that is first responder needs to override -keyDown: and do
this:
[self interpretKeyEvents:[NSArray arrayWithObject:event]];
which hooks the event into the standard dispatcher for these methods.
(One thing that has long puzzled me about this though - why is the
parameter an array of events when only one event is ever available?)
Okay, got this message late though it looks like another had responded
to it already. Given that I need to override -keyDown: (or -
performKeyEquivalent:) in applicable first responders anyway, and it
doesn't really read well to have -forwardDelete:, backwardDelete:,
etc. actions, I just did the following:
#pragma mark Keyboard events
- (BOOL)acceptsFirstResponder {
return YES;
}
- (void)keyDown:(NSEvent*)keyEvent {
NSString* keyCharacters = [keyEvent charactersIgnoringModifiers];
if ([keyCharacters length] == 1) {
unichar keyPressed = [keyCharacters characterAtIndex:0];
if (keyPressed == NSDeleteCharacter || keyPressed ==
NSDeleteCharFunctionKey) {
[self doCommandBySelector:@selector(delete:)];
}
else [super keyDown:keyEvent];
}
else [super keyDown:keyEvent];
}
Provided the view(s) with this code is the first responder, it causes
the action to fire when either delete key is pressed, with any
modifiers. If I need more fine-grained behaviour (forceDelete: or
something when Cmd is pressed), I'll just add it in that method.
I'm tempted to improve upon this by using the
NSUserInterfaceValidations informal protocol (which my app delegate
already conforms to for the sake of the EditDelete menu item) to
check if the delete action is even performed. The way this code
works, the delete key gets swallowed even when nothing is deleted.
This silent dropping of the delete key is how many apps behave, but
wouldn't it be better to pass the event up to super when the delete:
action isn't really valid, so it can eventually result in a beep/bonk/
blip?
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Delete action from variety of key presses
I want to be able to delete the items selected in a view, but am struggling finding a best way to turn the different key presses into a -delete: action that my controller can handle. I think I want (it seems expected functionality anyway) the delete key, the forward delete key, as well as Cmd-Delete to all trigger this action. I could assign one of those as a Key Equivalent for the EditDelete menu item, but that leaves the other two out in the cold. Furthermore, several applications (Keynote, iTunes) don't show any such key equivalent yet accept some or all of those keystrokes to delete a selection. iPhoto has PhotosMove To Trash equivalized to Cmd-Delete, but also performs that action if simply Delete is pressed. So I'm not finding a lot of clues in existing applications. A search through the archives would have me either a) add hidden buttons equivalent to these keys or b) subclass view(s) to handle the keystrokes myself. The first option seems really, really hackish but the second option means I'd have to subclass any view that could be key when the user wants to delete, and implement the same keychecking method in each. Is there a cleaner way to let my controller know whenever the user wants delete? Or am I making this too complicated to begin with somehow? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Delete action from variety of key presses
The Cocoa Text Bindings system already translates keys and key
combinations into invocations of NSResponder methods. http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/TextDefaultsBindings/chapter_9_section_1.html
So, what you need to do is determine which methods those keys are
already mapping to, override those methods in the appropriate place
in your responder chain (e.g. on your custom view or application
delegate), and have them all invoke some common method to do what
you want.
Thanks, I forgot to mention that I tried overriding some of those
action methods. However, I couldn't get them to fire.
If I implement:
- (BOOL)acceptsFirstResponder {
return YES;
}
- (void)keyDown:(NSEvent*)keyEvent {
(void)keyEvent;
printf(key event received\n);
}
- (void)deleteBackward:(id)sender {
(void)sender;
printf(delete backward received\n);
}
- (void)deleteForward:(id)sender {
(void)sender;
printf(delete forward received\n);
}
...and then press delete or forward-delete, I only ever get key event
received. According to the chart at http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/chapter_2_section_3.html#/
/apple_ref/doc/uid/1060i-CH3-SW10, it looks like the event should
flow all the way down to the Key Action? conditional, and since it's
a bound key binding I thought I should get the Yes: Send action
message to first responder path.
However, on further investigation, I see that this is just a
potential path diagram, and seems to be an example for if the first
responder view is a text one, which mine will rarely be. Under what
circumstances will the Cocoa Text Bindings system convert keypresses
to the text actions, so that a non-NSResponder (ie, a window/app
delegate) can perform the action?
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Delete action from variety of key presses
By overriding -keyDown: and not calling [super keyDown:keyEvent], you have stopped your view from actually processing the keys any further. That's why you aren't getting to either of the delete methods. Hmm, the flowchart I mentioned (http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/chapter_2_section_3.html ) gave me the impression that the Cocoa Text System would kick in before the view even had a chance at the event. I did try passing it to super (which in my case is NSView), but still didn't get the text binding actions to fire. The more I think about it though, it wouldn't make sense for Cocoa Text Bindings to always get first refusal of a key event. I think the links Ken Thomases provided, while great references for that system, only are relevant in subclasses of Cocoa's *Text* subclasses, where Apple has provided a subclass of NSView that loads the key mappings and does the action dispatch itself. Without the key view being one of Cocoa's text views, would I ever get these actions? Is there a similar built-in mechanism for application- or document-wide bindings unrelated to text editing? If not, then is the only way to turn a key event into an action by doing it myself in an NSResponder subclass put (or picked from) somewhere in the chain? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Good mouse tracking design for dynamic view?
So it seems I need to do more bookwork myself, but I'm wondering which direction others would recommend: a) Set up a single tracking area for the whole view, and perform all my own hit testing every time the mouse moves. b) Keep the per-item tracking areas, but perform my own testing in the edge cases when active (mouse has entered but not exited) tracking areas are getting reset. I vote for option A. Efficiency should not be a concern. [...] Reinventing hit testing shouldn't be much of a concern either [...] Thanks all for your encouragement. Implementing it myself isn't a problem (the rest of the code is pretty geometry heavy, so it's certainly not foreign territory) and has already made it easier to implement (or at least try out) other ideas, like finding everything within a certain radius of the cursor rather than just under. I just put a single tracking area across the entire view bounds (with the NSTrackingInVisibleRect, which I understand to make the tracking area's frame rect irrelevant anyway) and just run a linear search noting all items under the mouse every time it moves. I then compare this to a list from the previous check, and notify the items that have changed of an exit/entrance accordingly. I haven't tested performance with a ton of items, but as not a great amount of work is done I don't foresee any problem. I had to do one little hack for when the view itself is exited, namely, when the whole-view tracking area is exited I need to manually exit all items. Otherwise when the final mouseMoved fired, some items could still be underneath the mouse and would remain entered. Only really hackish in the sense that I need two functions to update the active items and post pseudo-events, rather than just the one. thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cocoa says not KVC compliant
On Jul 2, 2008, at 10:13 AM, Milen Dzhumerov wrote: I've run into a something I find strange. I've got a property declared as: @property(readwrite, assign, nonatomic) CGImageRef image; ... When I try to set it using KVC (e.g. [obj setValue:[NSValue valueWithPointer:image] forKeyPath:@image]), it says [*ClassName* 0x133050 setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key image.' Keep in mind that the core KVC messages are -setValue:(id)forKey: and - (id)valueForKey:. That is, the KVC functions deal with values that are true Objective-C objects. Your [NSValue valueWithPointer:] shows you are somewhat aware of this, but if you look at http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/DataTypes.html you will see that neither a CGImageRef nor a plain old pointer (void*) are supported scalar types in KVC. I may be wrong, but my understanding is that you will not be able to use KVC on this property, at least not without declaring the property type to be an NSValue*, which may or may not be an appropriate solution to your particular problem. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Layer hosting view not redisplaying under PPC
Today I took some time again to test my app on more architectures than just i386, and I'm encountering a strange problem on PowerPC with a custom view that hosts Core Animation layers. While other built-in views like NSButton are redrawing fine, none of my custom layer- hosting view's drawing shows up until I either minimize/unminimize the window or hide/unhide the application. This happens under Rosetta as well. I fear I must be doing something subtly wrong, because (e.g.) iTunes' CoverFlow view works fine under Rosetta and (obviously) on a PPC Mac, but I'm at a loss for where to even start. Under the hood, it seems to be working properly: The view draws correctly when the app is first launched. Right after an event that causes a layer to need redisplay is received, my - drawLayer:inContext: code is called and encounters no errors. All internal mechanisms seem to be working just the same as on Intel, the only difference is the drawing just doesn't actually show up. If I just move the window around, still nothing changes. When I hide/unhide the app, without doing any further actions that might affect the view, the drawing expected as a result of the earlier event finally shows up! Also, if I maximize the app on Intel, the layers in the view do their little implicit grow to new size animation. When I do this on PowerPC, only the first frame (or at least a very early frame) of this implicit animation shows. This isn't even my code, as Core Animation normally just stretches the cached texture, only calling - drawLayer:inContext: code for the final frame! I would suspect this is a bug in Core Animation, except for the fact that it's quite a show stopper and doesn't seem to have stopped anyone else. Why, only when running the version compiled for PowerPC, would my drawing simply not get updated as often as it should? What could I be doing wrong? What should I check? thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: How is Apple + Ctrl + D implemented?
On Apr 28, 2008, at 5:35 AM, John Joyce wrote: Graham, Thanks for your reply! But how can I find the range of the word given the glyph index? I just can not find an API doing so. [snip] The range of the word is up to you to find and depends on the language. If it is any common language from Europe, your job is a lot easier. You mainly need to work with whitespace and punctuation. If you're working with Japanese, you'll need to learn of lot of complex tricks to identify the range of words...[snip] Nota bene that the popup/Cmd-Ctrl-D dictionary does not look up single words only. Try it on that Latin phrase, and it's not just because of the quotes. The heuristic seems to be the longest main entry that matches (exactly after normalization?). It finds ablative absolute and a cappella and Aaron Copland, over ablative and a and Aaron (and nota above). Thus, there seems to be no way to pop up a definition for a capella [sic], only a and capella, as was confusing me until I realized my mispelling. Any stemming seem to be handled by either dictionary entries (ablative absolutes shows in Dictionary.app's list although it pulls up the singular entry), or finally by word boundaries (compare Aaron Coplands to Aaron Copland's). The main entry category doesn't seem to include phrases, as a bit much is findable in Dictionary.app, but not in the popup panel. The exactly part seems to come from nota bene (with two regular spaces) failing. Inserting a single U+2003 EM SPACE also causes failure, but not a U+00A0 NO-BREAK SPACE (which might be explained in terms of normalization before matching?). Of course, this is all just tested on words in the Oxford English, testing on Japanese text may reveal subtleties that affect the heuristic, which was deliberately vague about whether longest is in terms of words or characters (words seems most likely, so the previous discussion is still relevant). What none of this explains is why Preview.app won't give a pop-up dictionary even when a PDF has selectable text (which can be pulled up in Dictionary.app). For me, that would be an interesting explanation to hear. thanks, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: warning: Image scaling is not supported on Mac OS X versions prior to 10.5.
On Apr 14, 2008, at 6:12 AM, yang younker wrote: /* com.apple.ibtool.document.notices */ /* com.apple.ibtool.document.warnings */ /Users/younker/Developer/Example1/English.lproj/MainMenu.xib:460: warning: Image scaling is not supported on Mac OS X versions prior to 10.5. /Users/younker/Developer/Example1/English.lproj/MainMenu.xib:458: warning: Image scaling is not supported on Mac OS X versions prior to 10.5. /* com.apple.ibtool.document.errors */ This means your NIB/XIB has a deployment target not equal to 10.5.x, but you have some sort of button or other view whose Scaling setting is not None. If you go into Interface Builder, and go to your file's Info window, it will show a list of all these warnings. Either change your deployment target, or click each warning to pull up the problematic view in the inspector window and set its Scaling to None. It may be alright to ignore these warnings, I don't know. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: EXC_BAD_ACCESS when calling CGContextDrawLayerInRect
On Apr 13, 2008, at 7:15 AM, Carter R. Harrison wrote: CGContextRef context = [[NSGraphicsContext currentContext] graphicsPort]; CGContextDrawLayerInRect(context, CGRectMake([self frame].origin.x, [self frame].origin.y, [self frame].size.width, [self frame].size.height), cgback); cgback is a instance variable pointing to a CGLayer. So my code works, the correct things are being drawn to my view (more or less), but what happens is that after several seconds of use, the app crashes and I get an EXC_BAD_ACCESS error. Can you post more information regarding your cgback variable? How is it being allocated? That parameter seems to be the most likely culprit. -nvw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: some questions about creating image thumbnails
On Apr 9, 2008, at 8:32 AM, Jesse Grosjean wrote: I've heard (or maybe imagined) that some image file formats will already embed their own thumbnails. Is that a better way to do things... what image formats support that if any? This I do know a bit better. TIFF images can indeed store multiple representations, and it seems NSImage is well suited to using those representations. You might consider PNG as well. It cannot store multiple representations in one file, but it can compress many screen graphics (think screenshots of a typical application window and such) better than TIFF compressions while still keeping the original pixels. JPEG and other (usually unwritable) camera formats can store a thumbnail in their metadata, but I wouldn't recommend going that route. Not the only reason, but unless you're dealing with photographic material JPEG's lossy compression will not likely be suited to your needs. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: some questions about creating image thumbnails
On Apr 9, 2008, at 8:32 AM, Jesse Grosjean wrote: 1. If I don't care about on disk size is NSTIFFCompressionNone a fast way to write? (assuming that compression would take more time). Or maybe compression will actually save me time since the disk write will be faster? I am by no means a performance expert (is anyone besides Shark?) but I suspect that nowadays you would much rather do a bit of extra work in CPU/memory than extra hauling from the hard drive. You'd want to confirm this yourself in a small prototype that kinda mimics the behaviour of your application, except many times over. Watch out for both NSImage and disk caching, though. If you oversimplify your code by (say) loading the same image over and over, your prototype might not end up mimicking your app correctly. Anyway, I haven't experimented with this much myself, so I should let someone else give you a real answer! -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Getting the mouse location in a CAlayer's coordinates
On Apr 8, 2008, at 9:15 AM, douglas a. welton wrote: Hi All, Would someone provide me a pointer for how to get the mouse location in the coordinate system of a transformed layer that is underneath the mouse. I thought I could do something like this: Mouse_Location = [Target_Layer convertPoint: NSPointToCGPoint( [NSEvent mouseLocation] ) fromLayer: nil]; using nil for the fromLayer because Target_Layer is the view's topmost layer and contains all other sublayers. Unfortunately, the results I get back are incorrect (no conversion appears to be done) and when the Target_Layer has a transform (scaling) applied, the results are very wrong. I still don't fully understand how all the coordinate systems interact (see thread:http://www.cocoabuilder.com/archive/message/cocoa/2008/3/12/201189) but I think the following steps will get you what you need. 1. Convert the NSEvent's -locationInWindow to a a view coordinate, as describe in the documentation for that accessor: NSPoint event_location = [theEvent locationInWindow]; NSPoint local_point = [self convertPoint:event_location fromView:nil]; 2. Then convert the view coordinate to the root CALayer coordinate (since this may not be the same with resolution independence) using - [NSView convertPointToBase:] as follows: NSPoint root_point = [self convertPointToBase:local_point]; 3. Now you can convert it to the layer you want: CGPoint layer_point = [rootLayer convertPoint: NSPointToCGPoint(root_point) toLayer:desiredLayer]; Note that none of the CALayer point conversions say they accept nil (as -[NSView convertPoint:fromView:] allows). In fact they are explicit in saying that The receiver and layer and must share a common parent layer., though I'm pretty sure this still allows for the root layer to convert into its children's systems. hope this helps, -natevw ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Fixing my massive memory leak with NSImage/CALayer
I want to pop up photographs inside their own Core Animation layers,
but I get huge real memory usage that never goes down.
I have an FRPhoto class whose instances manage other metadata for the
image, and also have a convenience method to get an NSImage* as follows:
- (NSImage*)image {
if (!cachedImage) {
cachedImage = [[NSImage alloc] initByReferencingFile:filename];
}
return cachedImage;
}
...which I use to show the photo, in my view's method:
- (void)showPhoto:(FRPhoto*)photo {
CALayer* layer = [CALayer layer];
CGImageRef image = photo image] representations] objectAtIndex:0]
CGImage];
layer.contents = (id)image;
layer.frame = CGRectMake(0.0f, 0.0f, 50.0f, 50.0f);
layer.contentsGravity = kCAGravityResizeAspect;
[interactionLayer addSublayer:layer];
[layersForPhotos setObject:layer forKey:photo];
}
To put the FRPhoto into the layersForPhotos dictionary, I just
implemented a lazy retained copy:
- (id)copyWithZone:(NSZone*)zone {
(void)zone;
return [self retain];
}
These FRPhoto instances are kept basically indefinitely, so when I
hide the photo (also in the view) I make sure to call -[NSImage
recache]:
- (void)hidePhoto:(FRPhoto*)photo {
CALayer* layer = [layersForPhotos objectForKey:photo];
[layersForPhotos removeObjectForKey:photo];
[layer removeFromSuperlayer];
layer.contents = nil;
[[photo image] recache];
}
So by my reckoning: The CALayer should be autoreleased. And its
contents, too, were supposed to be an autoreleased CGImage, and I set
that property to nil just in case the layer itself is somehow sticking
around. The NSImage that my FRPhoto holds on to should have
invalidate[d] and free[d] the offscreen caches of all image
representations. But yet my memory usage just goes up and up and up,
every photo I view. Images I have looked at already pop right back up,
so they definitely act like they're still cached somewhere.
Even after many non-photo-showing event cycles, or just leaving it be
for a few minutes, absolutely no significant amount of memory has been
released according to both Instruments' ObjectAlloc and the Activity
Monitor. By the time I've look at a dozen images my RAM is totally
overwhelmed, making iPhoto's 15 second beachballs every couple minutes
look pretty attractive, compared to total system-wide gridlock.
What am I doing wrong? How can I get these images out of memory?
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
yearly NSDraggingInfo -draggedImage question (BEWARE!)
I implemented a dragging destination, and only get nil from [sender draggedImage]. Why? thanks, -natevw p.s. IMPORTANT NOTE! No one has lived to answer this question: http://www.cocoabuilder.com/archive/message/cocoa/2004/8/19/114978 http://www.cocoabuilder.com/archive/message/cocoa/2005/2/4/127484 http://www.cocoabuilder.com/archive/message/cocoa/2007/5/26/183772 I take no responsibility for any alien abduction that may result from your attempt to respond. I can't imagine the carnage that must have happened in '06; not even the question survived. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: yearly NSDraggingInfo -draggedImage question (BEWARE!)
[sending to the list this time, I might maybe someday eventually get
used to the reply-to policy here.]
On Mar 20, 2008, at 3:00 PM, Sherm Pendley wrote:
On Thu, Mar 20, 2008 at 5:19 PM, Nathan Vander Wilt [EMAIL PROTECTED]
wrote:
I implemented a dragging destination, and only get nil from [sender
draggedImage]. Why?
My car wouldn't start this morning. Why not?
Probably the aliens! :-)
If a more detailed explanation would help:
I subclassed an NSImageView to turn it into a dropbox to help me
prototype a file-opening feature.
I implemented the following method in my DropBox class:
- (NSDragOperation)draggingEntered:(idNSDraggingInfo)sender {
printf(Dragged Image: %x\n, (NSUInteger)[sender draggedImage]);
return NSDragOperationLink;
}
When I hover any file/folder from the Finder over this drop box, I get:
Dragged Image: 0
in the debugging console. Likewise if I check it in my prepare/
performDragOperation, this value is always nil.
The documentation says nothing about this method ever returning nil,
so it's even more suprising to me that it would *always* return nil. I
would expect it to give back a reference to the file/folder icon image
that I'm dragging around underneath the cursor. Is that not what this
method is documented to do?
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: yearly NSDraggingInfo -draggedImage question (BEWARE!)
On Mar 20, 2008, at 3:31 PM, Dave Hersey wrote:
Do you get anything different if you print the object as a pointer
(%p)? Printing it as an int value is... weird.
Try:
printf(Dragged Image: %p\n, (void *)[sender draggedImage]);
That's a useful format I'd either forgotten or never known, thanks! I
was just casting to an int to get rid of the warning for the hex,
though. (In C casts are pretty weak.) Now from all three methods I
always get:
Dragged Image: 0x0
...which is prettier, but still doesn't explain why the return value
is always nil. Or why Sherm's car wouldn't start.
If this is a bug, it seems to have been around since before 2004. (See
list of unanswered links in OP.) If it's a documentation omission,
nobody seems to know what the docs *should* say, also since 2004. If
it's user error, I'll still blame the docs, but at least I can make my
bug report better!
Maybe this would be a better way of asking:
What is the NSDraggingInfo protocol's -draggedImage method supposed to
return, and under what circumstances?
thanks,
-natevw
On Mar 20, 2008, at 6:15 PM, Nathan Vander Wilt wrote:
...
I subclassed an NSImageView to turn it into a dropbox to help me
prototype a file-opening feature.
I implemented the following method in my DropBox class:
- (NSDragOperation)draggingEntered:(idNSDraggingInfo)sender {
printf(Dragged Image: %x\n, (NSUInteger)[sender draggedImage]);
return NSDragOperationLink;
}
When I hover any file/folder from the Finder over this drop box, I
get:
Dragged Image: 0
in the debugging console. Likewise if I check it in my prepare/
performDragOperation, this value is always nil.
The documentation says nothing about this method ever returning
nil, so it's even more suprising to me that it would *always*
return nil. I would expect it to give back a reference to the file/
folder icon image that I'm dragging around underneath the cursor.
Is that not what this method is documented to do?
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
NSDate from xsd:dateTime / ISO 8601
I'm trying to convert a date formatted as a valid xsd:dateTime format, which is a subset of ISO 8601. I though I had it when I saw that that -[NSDate dateWithString:] takes an international string representation format. But when I feed it a string like @2007-07-01T01:33:01Z, I get back nil. Does -dateWithString: really not support the international [standard!] string representation of ISO 8601?? What's the right way to convert such an xsd:dateTime to an NSDate? thanks, -natevw ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.espanol.yahoo.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 [EMAIL PROTECTED]
Re: NSDate from xsd:dateTime / ISO 8601
Does -dateWithString: really not support the
international [standard!] string representation of
ISO 8601?? What's the right way to convert such an
xsd:dateTime to an NSDate?
+[NSDate dateWithString:] is, I think, configured to recognize one
particular date format, which depends on your system locale. It's
not very useful. What you want to do is customize an
NSDateFormatter object to recognize your format, and then parse
using it.
Here's some code I wrote recently. [...]
Thanks, I'd forgotten about NSDateFormatter. I took your code
snippets and made the following function:
NSDate* dateFromISO8601(NSString* str) {
I should note for posterity's sake that this function is poorly named:
ISO 8601 is a versatile format with many representation options. I did
come across http://boredzo.org/iso8601parser/, which is a category on
NSCalendarDate that looks like it tries to cover everything. It takes
a very low level, state machine(ish) approach to the problem.
I've killed an entire afternoon on this already, so for now I'll stick
with a format of @-MM-dd'T'HH:mm:ss'Z'. Unless I can prove I'll
never get a file with sub-second date precision (or some other
allowable variation of xsd:dateTime), I'll have to revisit this
eventually. NSXML does seem to be able to take an NSCalendarDate as an
objectValue (http://developer.apple.com/documentation/Cocoa/Conceptual/NSXML_Concepts/Articles/TransformObjectValues.html
), but I can only find this for emitted XML, and not during reading. I
still hope this functionality is already in Cocoa somewhere, but it's
looking less likely.
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Core Animation - Modifying CAConstraints
I have a situation where I want to re-order sublayers of a layer which are positioned using CAConstraints. Is this at all possible? Not sure what you mean by re-order, whether z-order or sibling order, or if you mean re-layout? Using CAConstraints will help with the last option. The constraints array property of a CALayer is declared as: @property(copy) NSArray *constraints; Which tells me that I can't modify the array in the object, but could modify the objects in the array. However, CAConstraint is completely private apart from initialisation methods. I'm pretty sure you can also provide a new array of constraints, eg: [sublayer setConstraints:[NSArray array]]. The (copy) just means the array you pass will be copied, there is no (readonly) flag on that. But typically to add a constraint, just instantiate a CAConstraint and add it to the sublayer with -[CALayer addContraint:]. You'll also need to set the parent layer's layoutManager property, to a [CAConstraintLayoutManager layoutManager] (you can also provide your own, without even using constraints, but this one is meant to specifically deal with the sublayers and their constraints). You may occasionally need to explicitly call -[CALayer setNeedsLayout] on the root layer, but it is done automatically for some changes, IIRC. Most of this is covered in: http://developer.apple.com/documentation/Cocoa/Conceptual/CoreAnimation_guide/Articles/Layout.html, which also has some sample code. hope this helps, -natevw ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.espanol.yahoo.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 [EMAIL PROTECTED]
Core Animation geometry, layer hosting, and resolution independence
I am having trouble understanding how Core Animation geometry interacts with NSView geometry in a layer-hosting situation. I have an NSView that hosts a root layer, and it has two sublayers that I need the user to be able to drag each around. I want to be able to convert a mouse coordinate into a point suitable for -hitTest:'ing on my root layer. I can convert from the mouse coordinates to the view's coordinates, but then I am not sure how to proceed. The convertPoint:fromView: method of NSView translates into the bounds rectangle, which is distinct from the view's frame. CALayers don't have this bounds/frame distinction, and I'm not sure whether the view's *frame* or it's *bounds* get applied to the hosted layer. I looked at how GeekGameBoard does it: CGPoint where = NSPointToCGPoint([self convertPoint: locationInWindow fromView: nil]); where = [_gameboard convertPoint: where fromLayer: self.layer]; CALayer *layer = [_gameboard hitTest: where]; ...which is straightforward enough BUT when I use Quartz Debug to double the scale factor, GeekGameBoard breaks, as if mouse movements/locations were halved. How do I convert points between these coordinate spaces in a more savvy manner? I think I get Core Animation's geometry within Core Animation, but I still don't get how it relates to the device and NSView geometry. Given the huge textures Core Animation wants to make when I create sublayers on a layer with a shrinking transform, it almost seems that 1 unit always corresponds to 1 pixel. How does Core Animation's geometry relate to NSView's resolution independent geometry? thanks, -natevw ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.espanol.yahoo.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 [EMAIL PROTECTED]
Re: Core Animation geometry, layer hosting, and resolution independence
--- Jens Alfke [EMAIL PROTECTED] escribió: On 12 Mar '08, at 2:49 PM, Nathan Vander Wilt wrote: I don't understand what this base coordinate system is (not the window's, otherwise the conversions would likely be offset by the view's position therein, right?). But whatever it is, it seems to be shared by the CALayer. The Cocoa Drawing Guide, under Pixel-Exact Drawing, says: These convenience methods make it possible to convert values to and from the base (device) coordinate system. They take into account the current backing store configuration for the view, including whether it is backed by a layer. In a layer-backed NSView, it seems that the 'device', aka backing store, is the view's CALayer; so these methods will convert to/from the layer's coordinates. Most excellent! Glad to have a documentation reference that seems to guarantee correct behaviour in this situation. Between that an the individual geometry guides, I think I should be able to eventually build a sense for how it all meshes. It'd still be nice to have a single go-to document that describes all the various coordinate systems as they meet in a custom drawn layer hosting view. Maybe some of the individual places could be clearer as well. I hate filing bugs like this against documentation, because I really don't know what would help until I've read it, but I'll try file at least one. thanks much, -natevw __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.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 [EMAIL PROTECTED]
[self setLayer:] in initWithFrame:
I provide an initWithFrame: for my NSView subclass, and as it is a stand-in for a Custom View in IB the method is called. It does initialize all my instance variables as expected. However, when I try to turn my view into a layer-hosting view with: CALayer* rootLayer = [CALayer layer]; [self setLayer:rootLayer]; [self setWantsLayer:YES]; [rootLayer setDelegate:self]; [rootLayer setNeedsDisplay]; My delegate method is never called, nor are any borders shown if I set those properties on my rootLayer. (The delegate does get a look, though, since I can crash the app by feeding a garbage pointer as a delegate.) Moving this code into my view's awakeFromNib handler makes the delegate work as expected. Why can't I enable layer hosting in my initWithFrame: method? thanks, -natevw ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.espanol.yahoo.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 [EMAIL PROTECTED]
Re: [self setLayer:] in initWithFrame:
If you don't have layer backing turned on in the nib file the view loading machinery turns off layer backing after initWithFrame: is called. Ah, that explains it! From my understanding (and the docs don't elaborate on this much at all), I *don't* want to do that, since I need to provide my own layer before calling wantsLayer:, correct? thanks, -natevw ¡Capacidad ilimitada de almacenamiento en tu correo! No te preocupes más por el espacio de tu cuenta con Correo Yahoo!: http://correo.espanol.yahoo.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 [EMAIL PROTECTED]
