Re: byte orders question
On Nov 26, 2011, at 7:06 PM, Scott Ribe wrote: I think what you had before would work for the byte swap conversion, assuming that your result was an array of floats; CFSwapInt32HostToBig is not really the right call--when it works it is by accident. Thanks again Scott for thinking along. I replaced: res = CFSwapInt32BigToHost(value); with: res = ntohl((u_int32_t) ((u_int32_t *) value)); Again giving the same expected results. Would this be the correct call, or am I still missing something? Thanks, - Koen. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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
MapKit
Hi All. Is there a way to load a custom map (instead of Google map) in the MKMapView component? Thanks. Luca.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: byte orders question
On Nov 27, 2011, at 6:06 AM, Koen van der Drift wrote: Again giving the same expected results. Would this be the correct call, or am I still missing something? The purpose of casting? I think you need to review a C reference, you're casting a uint32_t to uint32_t * then back to uint32_t. In prior code you were casting something (unsigned char * ???) to uint32_t *, then dereferencing it, which would be a uint32_t, then casting that to a uint32_t. NSData *base64DecodedData = [NSData dataFromBase64String: @Q5YIjESWO5JDlpIbRzMVL0OW=]; int n = [NSData length] / 4; const uint32_t *buf = (const uint32_t *) [NSData bytes]; float *results = (float *) malloc(n * 4); for( int i = 0; i n; ++i ) ((uint32_t *)results)[n] = ntohl( buf[n] ); Two of the casts, of bytes malloc results, are not necessary in plain C, but they're required in C++ and are habit for me ;-) Of course you might want to check that sizeof( float ) is 4, but the prior suggestion to use it in the code in place of 4 is off, because your input will still be 4 bytes I presume, and if your platform float is not 4, then you can't make it work and have to fail. (Of course, if your platform doesn't adhere to IEE floating point standards, and your input does, or vice versa, you're screwed anyway.) You might want to check that the data length is an exact multiple of 4, or rather 8 since you're expecting floats in pairs. And so on... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: NSView mouseDown truncated coordinates
Many thanks for your replies, Jens and Ken. I use the mouseMoved event to set the mouse cursor according to whether a NSBezierPath instance contains the mouse point [pathInstance containsPoint:], to indicate whether the path can be moved. There is no scale transformation on the view. On the boundary of the path, the mouseMoved and the mouseDown events disagree whether the mouse point is contained by the path even though the mouse pointer has not moved. e.g. mouseMoved says the point is outside the path, whereas mouseDown says it is inside the path. The cursor indication gives a false impression that the path cannot be moved when it actually can be moved. The disagreement is caused by the fractional part of the location coordinates in mouseMoved and the integral coordinates in mouseDown. I thought that high precision mouse/trackpad movement was possible and that the location could be adjusted to match the screen resolution using NSView centerScanRect. However, centerScanRect (arithmetically) rounds the location to the nearest pixel whereas mouseDown has truncated the location. It looks like I may have to truncate the coordinates in mouseMoved, to match what mouseDown does. I noticed that NSWindow mouseLocationOutsideOfEventStream does produce the non-integral coordinates when called from mouseDown, though that may not be the right direction to go. Steven ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: MapKit
On 27 Nov 2011, at 7:17 AM, Luca Ciciriello wrote: Is there a way to load a custom map (instead of Google map) in the MKMapView component? No. However, you could define an MKOverlayView that completely overwrites the standard view. I'm not sure how much that gets you above defining your own UIView for your map content and putting it into a UIScrollView. — F ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: byte orders question
On Nov 27, 2011, at 10:02 AM, Scott Ribe wrote: The purpose of casting? I think you need to review a C reference, you're casting a uint32_t to uint32_t * then back to uint32_t. In prior code you were casting something (unsigned char * ???) to uint32_t *, then dereferencing it, which would be a uint32_t, then casting that to a uint32_t. That code is not mine, it came straight out of the docs describing the xml scheme, I copied it as is but couldn't get it to work, hence my initial question. I now simplified my code a bit more, I changed: res = ntohl((u_int32_t) ((u_int32_t *) value)); to: res = ntohl(value); You might want to check that the data length is an exact multiple of 4, or rather 8 since you're expecting floats in pairs. And so on... I will do that. Thanks again for your help and suggestions. - Koen. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: awakeFromInsert called twice with nested contexts
On Sat, Nov 19, 2011 at 6:49 PM, Roland King r...@rols.org wrote: On Nov 20, 2011, at 5:48 AM, Jerry Krinock wrote: On 2011 Nov 16, at 17:16, Tom Harrington wrote: I'm finding that if I use nested managed object contexts, awakeFromInsert will be called twice on new objects. I'm wondering if this is a Core Data bug or a documentation bug. I'd say it's a pretty serious Core Data bug. I've not had an occasion to use nested managed object contexts yet, but I put things in -awakeFromInsert that I only want to happen once. It's certainly not explicitly documented, however a quick scan of the iOS forums finds another 3 developers who've discovered the same thing. Is it really the same object however? It can't be, right, they have different addresses, so Core Data is arguably doing what the documentation says, it's calling awakeFromInsert only once in the object's lifetime, you just have two objects, one in each context. Actually I don't, so far as I can tell. As I mentioned in my previous message, I get the same managed object ID both times. I haven't checked the address, but surely if they were different objects they wouldn't have the same ID. What does the object look like when you get the second call? Has Core Data literally just created it in the second MOC and is calling awakeFromInsert on it before (I assume) populating the data on it from the original, or is it already a clone of the first, with properties and relationships set on it? If the former that seems not too inconsistent, new object in new store gets called to set up defaults before the properties you set on it are cloned over, if the second case, that's much harder to deal with (and sounds like a bug) The object appears the same both times-- a new object with no properties or relationships set. -- Tom Harrington atomicb...@gmail.com AIM: atomicbird1 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: awakeFromInsert called twice with nested contexts
On Sun, Nov 20, 2011 at 2:34 PM, Richard Somers rsomers.li...@infowest.com wrote: On Nov 16, 2011, at 6:16 PM, Tom Harrington wrote: I'm finding that if I use nested managed object contexts, awakeFromInsert will be called twice on new objects. On Mac OS X 10.7 NSManagedObjectContext can have a parentContext. Perhaps this would be applicable. That is specifically what I meant when I mentioned nested contexts-- one context whose parent context is another context. -- Tom Harrington atomicb...@gmail.com AIM: atomicbird1 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: awakeFromInsert called twice with nested contexts
On Sun, Nov 27, 2011 at 6:09 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Nov 27, 2011, at 16:49 , Tom Harrington wrote: Actually I don't, so far as I can tell. As I mentioned in my previous message, I get the same managed object ID both times. I haven't checked the address, but surely if they were different objects they wouldn't have the same ID. You're wrong about that. Different objects will of course have different pointers, but that's the most you can say. The object, and hence the object pointer, is specific to a managed object context. The object ID is an attribute of the persistent store, and is independent of the MOC. If they're different objects then I'm getting duplicates, which is at least as much of a bug and possibly more so. What I observe is that if I add 10 objects, I get 20 calls to awakeFromInsert, 10 for the child context and 10 for the parent. But, there are only 10 unique managed object IDs. It might be that I just happen to be getting the same IDs for two completely different sets of objects, but there shouldn't be two sets in the first place. -- Tom Harrington atomicb...@gmail.com AIM: atomicbird1 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: awakeFromInsert called twice with nested contexts
On Nov 27, 2011, at 20:50 , Tom Harrington wrote: If they're different objects then I'm getting duplicates, which is at least as much of a bug and possibly more so. What I observe is that if I add 10 objects, I get 20 calls to awakeFromInsert, 10 for the child context and 10 for the parent. But, there are only 10 unique managed object IDs. It might be that I just happen to be getting the same IDs for two completely different sets of objects, but there shouldn't be two sets in the first place. Objects are specific to a managed object context, so it's correct that there would be 20 objects, and it's correct that there would be only 10 object IDs. For any given row in the persistent store, there will be one object *per managed context* in memory. The set of objects that correspond to the row all have the same object ID -- that's what object IDs are for. All of the numbers you're quoting are consistent: 1 persistent store 2 managed object contexts 10 rows to be inserted in the persistent store (when the MOCs are eventually saved) 10 object IDs, one per row 20 object instances, one per row per managed object context___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)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: awakeFromInsert called twice with nested contexts
On Nov 27, 2011, at 9:23 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Nov 27, 2011, at 20:50 , Tom Harrington wrote: If they're different objects then I'm getting duplicates, which is at least as much of a bug and possibly more so. What I observe is that if I add 10 objects, I get 20 calls to awakeFromInsert, 10 for the child context and 10 for the parent. But, there are only 10 unique managed object IDs. It might be that I just happen to be getting the same IDs for two completely different sets of objects, but there shouldn't be two sets in the first place. Objects are specific to a managed object context, so it's correct that there would be 20 objects, and it's correct that there would be only 10 object IDs. To clarify: if you had two nested MOCs that shared the same parent MOC, how would you plan on editing an object in Nested Context A as well as in Nested Context B if there *weren't* two separate NSManagedObject instances with the same object ID, each associated with a different context? --Kyle Sluder___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
