Contribute some dictionary keys with registerDefaults
I currently have a plist which contains some configuration values; at start of day I use the following call to make certain factory settings available to the application through NSUserDefaults: [[NSUserDefaults standardUserDefaults] registerDefaults:[NSDictionary dictionaryWithContentsOfFile:configPath]]; This works fine with single-object keys. i.e. I can include a key of type Number in the plist file, and it will be made available in the same way as other user defaults. However some of my user defaults are organised within a dictionary (e.g. there is a dictionary for each separate camera connected to the system, tracking user-controllable defaults such as chosen framerate). I would like a way to contribute factory settings from my plist for some of those key values. However if I include a dictionary in my plist, and separately call [[NSUserDefaults standardUserDefaults] setObject:aDictionary forDefault:@my_camera_key]; then this dictionary object fully overrides the entire dictionary object that I supplied for my_camera_key in the plist. I had thought there was an outside chance that it would effectively merge the two dictionaries together, looking for a specific key first in the dictionary object in the user-specified defaults and then falling back to the dictionary object I supplied through registerDefaults. This does not appear to be the case though. Not sure if this makes sense - perhaps an example will help. plist supplied to registerDefaults contains: my_camera_key dictionary my_camera_key.key1 = 4 my_camera_key.key2 = 5 dictionary passed to setObject:forDefault:@my_camera_key contains: key1=7 key3=1 I had vaguely hoped that if I then called [[NSUserDefaults standardUserDefaults] objectForKey:@my_camera_key] then I might get back a dictionary containing three objects: key1=7 key2=5 key3=1 Can anyone suggest how I might achieve what I am trying to do here? (Or suggest a better mechanism of doing what I want to do, i.e. maintain some sort of hierarchy to my defaults, but also be able to supply factory settings for objects below the top level of the hierarchy? Thanks for any suggestions Jonny ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Contribute some dictionary keys with registerDefaults
When you call -setObject:forKey:, it replaces the entire contents of that key, whether the object is a number, string, dictionary, etc. That’s the same behavior as if you called -setObject:forKey: on a regular dictionary when one of its objects is, itself, a dictionary. Depending on what you need to be doing, you could go a couple of routes: 1. Add a category on NSUserDefaults to handle getting/setting those values that are organized in a sub-dictionary. 2. Create a custom class that manages all of your settings and don’t call NSUserDefaults directly outside of that class. I’ve tended to go with the latter method myself. It allows me to type the property value, i.e., int or long instead of NSNumber*, or NSString* instead of id; it allows me to range-check and otherwise validate values before storing them; and it means that NSUserDefaults property keys are only managed in one place so I don’t have to worry about key typos in other files that would have me accessing the wrong value or an unknown value. On Jun 18, 2014, at 5:22 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: I currently have a plist which contains some configuration values; at start of day I use the following call to make certain factory settings available to the application through NSUserDefaults: [[NSUserDefaults standardUserDefaults] registerDefaults:[NSDictionary dictionaryWithContentsOfFile:configPath]]; This works fine with single-object keys. i.e. I can include a key of type Number in the plist file, and it will be made available in the same way as other user defaults. However some of my user defaults are organised within a dictionary (e.g. there is a dictionary for each separate camera connected to the system, tracking user-controllable defaults such as chosen framerate). I would like a way to contribute factory settings from my plist for some of those key values. However if I include a dictionary in my plist, and separately call [[NSUserDefaults standardUserDefaults] setObject:aDictionary forDefault:@my_camera_key]; then this dictionary object fully overrides the entire dictionary object that I supplied for my_camera_key in the plist. I had thought there was an outside chance that it would effectively merge the two dictionaries together, looking for a specific key first in the dictionary object in the user-specified defaults and then falling back to the dictionary object I supplied through registerDefaults. This does not appear to be the case though. Not sure if this makes sense - perhaps an example will help. plist supplied to registerDefaults contains: my_camera_key dictionary my_camera_key.key1 = 4 my_camera_key.key2 = 5 dictionary passed to setObject:forDefault:@my_camera_key contains: key1=7 key3=1 I had vaguely hoped that if I then called [[NSUserDefaults standardUserDefaults] objectForKey:@my_camera_key] then I might get back a dictionary containing three objects: key1=7 key2=5 key3=1 Can anyone suggest how I might achieve what I am trying to do here? (Or suggest a better mechanism of doing what I want to do, i.e. maintain some sort of hierarchy to my defaults, but also be able to supply factory settings for objects below the top level of the hierarchy? Thanks for any suggestions Jonny ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Taking screen shots
Actually just window shots. I feel like I've been fighting with the screen shot code, and that it shouldn't be this difficult. I get past one problem only to find another. My most recent seems intractable. If drawing to the window happens when the window is not completely on screen and if you drag the window so that it is fully visible on screen so you can see that all the drawing you did is actually drawn and then take a snapshot using CGWindowListCreateImage of the fully visible window, the bit of the window that was offscreen when drawn to is missing the drawing that happened at that time. The size of the window shot is correct it is just as if the drawing didn't happen to that part of the window. I hope I've described this well enough. Is there something I'm missing that will cause CGWindowListCreateImage to capture all the drawing. Kevin ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Bindings setup with NSCollectionViews
On Jun 17, 2014, at 7:40 PM, Hajder Rabiee wrote: I am having trouble getting the master-detail binding configuration setup correctly. I've sat down far too many hours trying to debug this and I hope anyone can give me a hint on how to solve this issue. The full problem description can be found already at http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-binding-configuration How are you binding the NSViewControllers? AFAIK, NSViewController does not implement any bindings. The typical approach is to subclass and implement the observations necessary to update its represented object. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Taking screen shots
On Wed, Jun 18, 2014, at 07:12 AM, Kevin Meaney wrote: If drawing to the window happens when the window is not completely on screen and if you drag the window so that it is fully visible on screen so you can see that all the drawing you did is actually drawn and then take a snapshot using CGWindowListCreateImage of the fully visible window, the bit of the window that was offscreen when drawn to is missing the drawing that happened at that time. The size of the window shot is correct it is just as if the drawing didn't happen to that part of the window. I hope I've described this well enough. Not really. Can you show some code? --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Taking screen shots
Not really.
Can you show some code?
dictArray = CGWindowListCopyWindowInfo(kCGWindowListOptionIncludingWindow,
(CGWindowID)[self._window
windowNumber]);
if (dictArray (CFArrayGetCount(dictArray) 0))
windowDict = CFArrayGetValueAtIndex(dictArray, 0);
if (windowDict (CFDictionaryGetCount(windowDict) 0))
rectDict = CFDictionaryGetValue(windowDict, kCGWindowBounds);
if (rectDict)
{
if (CGRectMakeWithDictionaryRepresentation(rectDict, winRect))
gotRect = YES;
}
if (dictArray)
CFRelease(dictArray);
NSRect screenRect;
if (gotRect)
{
// screenRect = [self._window contentRectForFrameRect:winRect];
screenRect = winRect;
screenRect.origin.y += winRect.size.height - self._height;
screenRect.size.height = self._height;
}
else
{
NSScreen *screen = self._window.screen;
CGFloat screenHeight = screen.frame.size.height;
NSRect windowRect = self._window.frame;
NSRect contentRect = [self._window contentRectForFrameRect:windowRect];
screenRect = CGRectMake(
contentRect.origin.x,
screenHeight - (contentRect.origin.y +
contentRect.size.height),
contentRect.size.width,
contentRect.size.height);
}
MICGImage *newImage;
CGImageRef cgImage;
cgImage = CGWindowListCreateImage(screenRect,
kCGWindowListOptionIncludingWindow,
(CGWindowID)[self._window windowNumber],
kCGWindowImageBoundsIgnoreFraming);
--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:
https://lists.apple.com/mailman/options/cocoa-dev/ktam%40yvs.eu.com
This email sent to k...@yvs.eu.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Taking screen shots
On Jun 18, 2014, at 8:24 AM, Kevin Meaney k...@yvs.eu.com wrote: [ snip ] Thanks. But I’m still confused about the timing. What method does this code live in, and when is that method executed relative to the window being dragged completely back on to the screen? --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Taking screen shots
Apologies,
The e-mail with the code went out before I was finished editing.
The code shown is that taking the screen capture. But what is captured is not
what I see in the window.
Kevin
On 18 Jun 2014, at 16:24, Kevin Meaney k...@yvs.eu.com wrote:
Not really.
Can you show some code?
dictArray = CGWindowListCopyWindowInfo(kCGWindowListOptionIncludingWindow,
(CGWindowID)[self._window
windowNumber]);
if (dictArray (CFArrayGetCount(dictArray) 0))
windowDict = CFArrayGetValueAtIndex(dictArray, 0);
if (windowDict (CFDictionaryGetCount(windowDict) 0))
rectDict = CFDictionaryGetValue(windowDict, kCGWindowBounds);
if (rectDict)
{
if (CGRectMakeWithDictionaryRepresentation(rectDict, winRect))
gotRect = YES;
}
if (dictArray)
CFRelease(dictArray);
NSRect screenRect;
if (gotRect)
{
// screenRect = [self._window contentRectForFrameRect:winRect];
screenRect = winRect;
screenRect.origin.y += winRect.size.height - self._height;
screenRect.size.height = self._height;
}
else
{
NSScreen *screen = self._window.screen;
CGFloat screenHeight = screen.frame.size.height;
NSRect windowRect = self._window.frame;
NSRect contentRect = [self._window contentRectForFrameRect:windowRect];
screenRect = CGRectMake(
contentRect.origin.x,
screenHeight - (contentRect.origin.y +
contentRect.size.height),
contentRect.size.width,
contentRect.size.height);
}
MICGImage *newImage;
CGImageRef cgImage;
cgImage = CGWindowListCreateImage(screenRect,
kCGWindowListOptionIncludingWindow,
(CGWindowID)[self._window windowNumber],
kCGWindowImageBoundsIgnoreFraming);
--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:
https://lists.apple.com/mailman/options/cocoa-dev/ktam%40yvs.eu.com
This email sent to k...@yvs.eu.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:
https://lists.apple.com/mailman/options/cocoa-dev/ktam%40yvs.eu.com
This email sent to k...@yvs.eu.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Taking screen shots
The sequence of events are: 1. Drag window so that it is partially offscreen. 2. Draw into the window where part of the drawing happens in the part of the window that is offscreen. 3. Drag the window so that it is fully on screen. Observe that the window shows all the drawing that was performed. 4. Take a snapshot of the window. 5. Save the snapshot to an image file. 6. Note that the snapshot is missing the part of the drawing that was drawn offscreen, but was visible after step 3. Kevin On 18 Jun 2014, at 16:30, Kyle Sluder k...@ksluder.com wrote: On Jun 18, 2014, at 8:24 AM, Kevin Meaney k...@yvs.eu.com wrote: [ snip ] Thanks. But I’m still confused about the timing. What method does this code live in, and when is that method executed relative to the window being dragged completely back on to the screen? --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Taking screen shots
On Jun 18, 2014, at 8:36 AM, Kevin Meaney k...@yvs.eu.com wrote: The sequence of events are: 1. Drag window so that it is partially offscreen. 2. Draw into the window where part of the drawing happens in the part of the window that is offscreen. Ok, what does this mean? In AppKit, you don’t draw into a window; the window asks you to draw. If you mean that you’re sending -drawRect: to the view yourself, that will never work. It’s also possible that CGWindowList doesn’t force a window to draw its entire area. Do you get the same results with the SonOfGrab sample project? https://developer.apple.com/library/mac/samplecode/SonOfGrab/Listings/Controller_m.html#//apple_ref/doc/uid/DTS10004490-Controller_m-DontLinkElementID_4 --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Taking screen shots
On Jun 18, 2014, at 8:36 AM, Kevin Meaney k...@yvs.eu.com wrote: The sequence of events are: 1. Drag window so that it is partially offscreen. 2. Draw into the window where part of the drawing happens in the part of the window that is offscreen. Ok, what does this mean? In AppKit, you don’t draw into a window; the window asks you to draw. If you mean that you’re sending -drawRect: to the view yourself, that will never work. Drawing happens when I receive an xpc message containing a drawing command. To do the drawing I get the NSGraphicsContext from which I pull the graphicsPort which is a special kind of CGContext. I then use CoreGraphics commands to do the drawing. I looked at SonOfGrab when I first implemented this, so I'm looking at it again to see if it can provide some clues. Kevin It’s also possible that CGWindowList doesn’t force a window to draw its entire area. Do you get the same results with the SonOfGrab sample project? https://developer.apple.com/library/mac/samplecode/SonOfGrab/Listings/Controller_m.html#//apple_ref/doc/uid/DTS10004490-Controller_m-DontLinkElementID_4 --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Taking screen shots
SonOfGrab displays in the composited image window the correct image after following the same steps. Kevin On 18 Jun 2014, at 17:01, Kevin Meaney k...@yvs.eu.com wrote: On Jun 18, 2014, at 8:36 AM, Kevin Meaney k...@yvs.eu.com wrote: The sequence of events are: 1. Drag window so that it is partially offscreen. 2. Draw into the window where part of the drawing happens in the part of the window that is offscreen. Ok, what does this mean? In AppKit, you don’t draw into a window; the window asks you to draw. If you mean that you’re sending -drawRect: to the view yourself, that will never work. Drawing happens when I receive an xpc message containing a drawing command. To do the drawing I get the NSGraphicsContext from which I pull the graphicsPort which is a special kind of CGContext. I then use CoreGraphics commands to do the drawing. I looked at SonOfGrab when I first implemented this, so I'm looking at it again to see if it can provide some clues. Kevin It’s also possible that CGWindowList doesn’t force a window to draw its entire area. Do you get the same results with the SonOfGrab sample project? https://developer.apple.com/library/mac/samplecode/SonOfGrab/Listings/Controller_m.html#//apple_ref/doc/uid/DTS10004490-Controller_m-DontLinkElementID_4 --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: https://lists.apple.com/mailman/options/cocoa-dev/ktam%40yvs.eu.com This email sent to k...@yvs.eu.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSCoding vs NSSecureCoding
On Tue, 17 Jun 2014 08:22:40 -0700, Tony Parker said: NSKeyedArchiver and NSKeyedUnarchiver also support secure coding as of 10.9. Tony, Thanks for the details. Are there any issues in creating an archive on 10.9 and then decoding it on 10.8 or older? Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Taking screen shots
On Wed, Jun 18, 2014, at 09:01 AM, Kevin Meaney wrote:
Drawing happens when I receive an xpc message containing a drawing
command. To do the drawing I get the NSGraphicsContext from which I pull
the graphicsPort which is a special kind of CGContext. I then use
CoreGraphics commands to do the drawing.
You're still not being specific enough. Where is this code happening?
Which context is it grabbing?
If you want to draw to the screen, you send -setNeedsDisplay: to a view
and wait for the window to come around and ask you to draw. That is the
ONLY* way to draw to the screen in OS X.
So this is OK:
// xpc listener
- (void)handleIncomingDrawCommand:(id)drawCommand {
AppendDrawCommandToQueue(drawCommand);
[_myView setNeedsDisplay:YES];
}
// view
- (void)drawRect:(NSRect)dirtyRect {
CGContextRef cgContext = [[NSGraphicsContext currentContext]
graphicsPort];
ApplyDrawCommandsFromQueue(cgContext);
}
This is NOT OK:
- (void)handleIncomingDrawCommand:(id)drawCommand {
CGContextRef cgContext = [[NSGraphicsContext currentContext]
graphicsPort];
ImmediatelyPerformDrawCommand(drawCommand, cgContext); // NO!
}
Depending on your application, your listener may need to maintain a
partial or complete history of draw commands it has received so that it
can draw them all anew in -drawRect:. If it's too expensive to redraw
all your commands every time you get sent -drawRect:, you can maintain
_your own_ offscreen buffer and just blit it to the screen in
-drawRect:.
// xpc listener
NSBitmapImageRep *_offscreenBuffer;
- (void)handleIncomingDrawCommand:(id)drawCommand {
AppendDrawCommandToQueue(drawCommand); // in case we need to resize
and redraw the _offscreenBuffer
PerformQueuedDrawCommands(_offscreenBuffer);
[_myView setNeedsDisplay:YES];
}
// view
- (void)setFrameSize:(NSSize)newSize {
ResizeBuffer(_offscreenBuffer, newSize);
PerformQueuedDrawCommands(_offscreenBuffer);
[super setFrameSize:newSize];
}
- (void)drawRect:(NSRect)dirtyRect {
[_offscreenBuffer drawAtPoint:self.bounds.origin];
}
You can build a CGContextRef around an NSBitmapImageRep by using
+[NSGraphicsContext graphicsContextWithBitmapImageRep:] and getting the
result's graphicsPort.
--Kyle Sluder
* not really the only way, but the only supported way that works in all
cases.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSCoding vs NSSecureCoding
Hi Sean, On Jun 18, 2014, at 9:42 AM, Sean McBride s...@rogue-research.com wrote: On Tue, 17 Jun 2014 08:22:40 -0700, Tony Parker said: NSKeyedArchiver and NSKeyedUnarchiver also support secure coding as of 10.9. Tony, Thanks for the details. Are there any issues in creating an archive on 10.9 and then decoding it on 10.8 or older? Nope, this should work fine. The archive itself does not contain anything different. The reason that keyed archiver allows you to set secure coding is simply to perform an additional check when encoding that all classes you’re putting in the archive adopt the NSSecureCoding protocol. So in other words, the secure decoding is an option that can be applied to any keyed archive. - Tony Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa-dev Digest, Vol 11, Issue 339
I¹m not clear as to what your view/nib structure is. If you are using a view nib, I recommend using a custom viewController and, in awakeFromNib, setting a local property (maybe from an IBOutlet) to the array controller. Trying to bind anything to an array controller through a view controller¹s representedObject does not work. On 6/18/14 8:28 AM, cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com wrote: I am having trouble getting the master-detail binding configuration setup correctly. I've sat down far too many hours trying to debug this and I hope anyone can give me a hint on how to solve this issue. The full problem description can be found already at http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-bin ding-configuration ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Bindings setup with NSCollectionViews
Sorry, forgot to update the Subject on previous post On 6/18/14 8:28 AM, cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com wrote: Bindings setup with NSCollectionViews ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Taking screen shots
This is NOT OK:
- (void)handleIncomingDrawCommand:(id)drawCommand {
CGContextRef cgContext = [[NSGraphicsContext currentContext]
graphicsPort];
ImmediatelyPerformDrawCommand(drawCommand, cgContext); // NO!
}
Bugger, that is exactly what I'm doing.
Basically the tool is intended for drawing to an offscreen bitmap. But I got
feedback that while testing out scripts people wanted to see what was going on,
so I tried having a window associated with the offscreen bitmap that could be
shown in a debug mode and blit the offscreen context into the window in the
draw rect of the window's content view after setting set needs display. This
slowed things down a lot for large bitmaps as I'm not keeping track of what
region changed.
So I tried this approach, with a fixed size window and the performance is only
slightly slower than working with an offscreen bitmap without a window. I've
got a large collection of test scripts producing images and comparing the
output to previously produced images and the generated images from the window
context are within acceptable tolerances the same images.
The window is fixed size, but the problem occurred when the window was dragged
offscreen and if drawing occurred whilst the window was offscreen. SonOfGrab
gets the window content correctly.
Thanks for the feedback.
I'll have to think about another approach.
Kevin
Depending on your application, your listener may need to maintain a
partial or complete history of draw commands it has received so that it
can draw them all anew in -drawRect:. If it's too expensive to redraw
all your commands every time you get sent -drawRect:, you can maintain
_your own_ offscreen buffer and just blit it to the screen in
-drawRect:.
// xpc listener
NSBitmapImageRep *_offscreenBuffer;
- (void)handleIncomingDrawCommand:(id)drawCommand {
AppendDrawCommandToQueue(drawCommand); // in case we need to resize
and redraw the _offscreenBuffer
PerformQueuedDrawCommands(_offscreenBuffer);
[_myView setNeedsDisplay:YES];
}
// view
- (void)setFrameSize:(NSSize)newSize {
ResizeBuffer(_offscreenBuffer, newSize);
PerformQueuedDrawCommands(_offscreenBuffer);
[super setFrameSize:newSize];
}
- (void)drawRect:(NSRect)dirtyRect {
[_offscreenBuffer drawAtPoint:self.bounds.origin];
}
You can build a CGContextRef around an NSBitmapImageRep by using
+[NSGraphicsContext graphicsContextWithBitmapImageRep:] and getting the
result's graphicsPort.
--Kyle Sluder
* not really the only way, but the only supported way that works in all
cases.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Taking screen shots
Since the SonOfGrab application works for grabbing the contents of my window,
even when it is partially offscreen at the time of taking the screen grab I had
a look at what it was doing differently.
Basically SonOfGrab was passing in CGRectNull into CGWindowListCreateImage
instead of a defined rectangle. I was defining a rectangle because I wanted the
content region of the window not the whole window. So instead I passed in
CGRectNull and then afterwards crop the generated CGImageRef down to exclude
the window title bar.
This now works as it should and as it does for SonOfGrab.
So now I'm going to ask about why drawing to the windows graphics context
directly is not ok.
I'm not dealing with any views, just a window created programmatically with its
one content view. The window cannot be
resized. In this situation I believe the issues around lock focus and the
calling of draw rect within a view hierarchy may not apply. Are there other
issues that will hurt me when drawing directly?
Kevin
On 18 Jun 2014, at 17:47, Kyle Sluder k...@ksluder.com wrote:
On Wed, Jun 18, 2014, at 09:01 AM, Kevin Meaney wrote:
Drawing happens when I receive an xpc message containing a drawing
command. To do the drawing I get the NSGraphicsContext from which I pull
the graphicsPort which is a special kind of CGContext. I then use
CoreGraphics commands to do the drawing.
You're still not being specific enough. Where is this code happening?
Which context is it grabbing?
If you want to draw to the screen, you send -setNeedsDisplay: to a view
and wait for the window to come around and ask you to draw. That is the
ONLY* way to draw to the screen in OS X.
So this is OK:
// xpc listener
- (void)handleIncomingDrawCommand:(id)drawCommand {
AppendDrawCommandToQueue(drawCommand);
[_myView setNeedsDisplay:YES];
}
// view
- (void)drawRect:(NSRect)dirtyRect {
CGContextRef cgContext = [[NSGraphicsContext currentContext]
graphicsPort];
ApplyDrawCommandsFromQueue(cgContext);
}
This is NOT OK:
- (void)handleIncomingDrawCommand:(id)drawCommand {
CGContextRef cgContext = [[NSGraphicsContext currentContext]
graphicsPort];
ImmediatelyPerformDrawCommand(drawCommand, cgContext); // NO!
}
Depending on your application, your listener may need to maintain a
partial or complete history of draw commands it has received so that it
can draw them all anew in -drawRect:. If it's too expensive to redraw
all your commands every time you get sent -drawRect:, you can maintain
_your own_ offscreen buffer and just blit it to the screen in
-drawRect:.
// xpc listener
NSBitmapImageRep *_offscreenBuffer;
- (void)handleIncomingDrawCommand:(id)drawCommand {
AppendDrawCommandToQueue(drawCommand); // in case we need to resize
and redraw the _offscreenBuffer
PerformQueuedDrawCommands(_offscreenBuffer);
[_myView setNeedsDisplay:YES];
}
// view
- (void)setFrameSize:(NSSize)newSize {
ResizeBuffer(_offscreenBuffer, newSize);
PerformQueuedDrawCommands(_offscreenBuffer);
[super setFrameSize:newSize];
}
- (void)drawRect:(NSRect)dirtyRect {
[_offscreenBuffer drawAtPoint:self.bounds.origin];
}
You can build a CGContextRef around an NSBitmapImageRep by using
+[NSGraphicsContext graphicsContextWithBitmapImageRep:] and getting the
result's graphicsPort.
--Kyle Sluder
* not really the only way, but the only supported way that works in all
cases.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
iOS app restarting from screen one. Why?
I've seen this only since iOS 7 and haven't been able to figure out what causes this. Many times in many applications on iOS, when an app is in the background and is brought to the front, it doesn't continue from the screen it was left at. In many cases, I've seen the app restarting from screen one. Most of the times I've seen this, I've been toggling Personal Hotspot. Does anyone have any info on what causes the app to seemingly unroll it's Navigation Controller stack and start from the first screen again? Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Send msg to object by nameed NSString;
If I have a class:
@interface MyClass : NSObject
{
NSNumber*myNumber;
}
@property (nonatomic, retain) NSNumber* myNumber;
And in the class implementation I have:
-(void)doSomething
{
// it could get this string from anywhere, not always a constant
NSString* myString = @myNumber;
???
}
Is there a way to access the myNumber property and send it a message knowing
only it's name (contained in myString)?
So rather than doing:
[myNumber release];
I could do something like:
[getProperty(myString) release];
Thanks,
Trygve
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Bindings setup with NSCollectionViews
The master detail view is bound to BoardArrayController with Controller Key: arrangedObjects The detailed view is bound to BoardArrayController with Controller Key: selection and Model Key Path: lists I have followed the guide here https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CocoaBindings/Tasks/masterdetail.html#//apple_ref/doc/uid/20002090-BCICADHC On Wed, Jun 18, 2014 at 4:17 PM, Keary Suska cocoa-...@esoteritech.com wrote: On Jun 17, 2014, at 7:40 PM, Hajder Rabiee wrote: I am having trouble getting the master-detail binding configuration setup correctly. I've sat down far too many hours trying to debug this and I hope anyone can give me a hint on how to solve this issue. The full problem description can be found already at http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-binding-configuration How are you binding the NSViewControllers? AFAIK, NSViewController does not implement any bindings. The typical approach is to subclass and implement the observations necessary to update its represented object. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business -- Med vänliga hälsningar / Best Regards Hajder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa-dev Digest, Vol 11, Issue 339
The application consists of one main xib and its File's Owner is a subclass of NSWindowController. Can you further explain as to which binding to an array controller that is not possible? The only places where 'representedObject' is present is in the item prototypes for NSCollectionView. I.e. the ones that are added automatically when dragging an NSCollectionView in IB. On Wed, Jun 18, 2014 at 7:09 PM, Gordon Apple g...@ed4u.com wrote: I’m not clear as to what your view/nib structure is. If you are using a view nib, I recommend using a custom viewController and, in awakeFromNib, setting a local property (maybe from an IBOutlet) to the array controller. Trying to bind anything to an array controller through a view controller’s representedObject does not work. On 6/18/14 8:28 AM, cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com wrote: I am having trouble getting the master-detail binding configuration setup correctly. I've sat down far too many hours trying to debug this and I hope anyone can give me a hint on how to solve this issue. The full problem description can be found already at *http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-binding-configuration http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-binding-configuration* -- Med vänliga hälsningar / Best Regards Hajder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS app restarting from screen one. Why?
On Jun 18, 2014, at 11:22 AM, Alex Zavatone z...@mac.com wrote: Does anyone have any info on what causes the app to seemingly unroll it's Navigation Controller stack and start from the first screen again? Probably because the OS quit the app while it was backgrounded, and it’s being relaunched? Back in the day, before app processes persisted in the background, it was important to explicitly save your UI state (controller stack) and restore it on startup, but I suspect a lot of apps don’t pay attention to this anymore since the relaunch doesn’t happen very often. —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
On Jun 18, 2014, at 11:23 AM, Trygve Inda cocoa...@xericdesign.com wrote: Is there a way to access the myNumber property and send it a message knowing only it's name (contained in myString)? You mean like key-value coding? [self valueForKey: @“myNumber”]; —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
Yes. You can either use key-value coding: [[self valueForKey:myString] release];
or you can use the ObjC runtime functions to do exactly that.
#import objc/runtime.h
id value = nil;
object_getInstanceVariable(self, [myStr UTF8String], value); // if your ivar
is auto synthesized from a property, you’d need to prepend an underscore.
[value release];
No need to do that when you have Key-Value Coding, however. Just use that.
On Jun 18, 2014, at 11:23 AM, Trygve Inda cocoa...@xericdesign.com wrote:
If I have a class:
@interface MyClass : NSObject
{
NSNumber*myNumber;
}
@property (nonatomic, retain) NSNumber* myNumber;
And in the class implementation I have:
-(void)doSomething
{
// it could get this string from anywhere, not always a constant
NSString* myString = @myNumber;
???
}
Is there a way to access the myNumber property and send it a message knowing
only it's name (contained in myString)?
So rather than doing:
[myNumber release];
I could do something like:
[getProperty(myString) release];
Thanks,
Trygve
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/danhd123%40mac.com
This email sent to danhd...@mac.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Bindings setup with NSCollectionViews
That part should work. I was referring to the view controller¹s representedObject, if you are using such a view controller in a view nib and trying to bind the collection view to an array controller through the view controller¹s representedObject. On 6/18/14 1:34 PM, Hajder Rabiee hajd...@gmail.com wrote: The application consists of one main xib and its File's Owner is a subclass of NSWindowController. Can you further explain as to which binding to an array controller that is not possible? The only places where 'representedObject' is present is in the item prototypes for NSCollectionView. I.e. the ones that are added automatically when dragging an NSCollectionView in IB. On Wed, Jun 18, 2014 at 7:09 PM, Gordon Apple g...@ed4u.com wrote: I¹m not clear as to what your view/nib structure is. If you are using a view nib, I recommend using a custom viewController and, in awakeFromNib, setting a local property (maybe from an IBOutlet) to the array controller. Trying to bind anything to an array controller through a view controller¹s representedObject does not work. On 6/18/14 8:28 AM, cocoa-dev-requ...@lists.apple.com http://cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com http://cocoa-dev-requ...@lists.apple.com wrote: I am having trouble getting the master-detail binding configuration setup correctly. I've sat down far too many hours trying to debug this and I hope anyone can give me a hint on how to solve this issue. The full problem description can be found already at http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-b inding-configuration ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: iOS app restarting from screen one. Why?
Honestly, it seems like it's unrolling the navigation controller for some strange reason when I toggle Personal Hotspot while the app is in the background. Many times I've seen this happen and even when moving various iPhone's Settings panels to the background, then bringing them to the front again. Never saw it before iOS 7, so I was wondering it anyone else has been seeing this. Since many of our apps need to be run on a VPN, it's expected that the network connection could change due to user action and it's really not optimal if changing network access forces a nav stack unroll. I'm not even sure that's what's happening, but it sure appears to be after looking at this happening over at least 5 apps for about 9 months. Has anyone else seen this type of behaviour? On Jun 18, 2014, at 2:42 PM, Jens Alfke wrote: On Jun 18, 2014, at 11:22 AM, Alex Zavatone z...@mac.com wrote: Does anyone have any info on what causes the app to seemingly unroll it's Navigation Controller stack and start from the first screen again? Probably because the OS quit the app while it was backgrounded, and it’s being relaunched? Back in the day, before app processes persisted in the background, it was important to explicitly save your UI state (controller stack) and restore it on startup, but I suspect a lot of apps don’t pay attention to this anymore since the relaunch doesn’t happen very often. —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
RE: iOS app restarting from screen one. Why?
Sent from AOLMail On Wednesday, June 18, 2014 Alex Zavatone z...@mac.com wrote: I've seen this only since iOS 7 and haven't been able to figure out what causes this. Many times in many applications on iOS, when an app is in the background and is brought to the front, it doesn't continue from the screen it was left at. In many cases, I've seen the app restarting from screen one. Most of the times I've seen this, I've been toggling Personal Hotspot. Does anyone have any info on what causes the app to seemingly unroll it's Navigation Controller stack and start from the first screen again? Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/altotest1%40aol.com This email sent to altote...@aol.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Bindings setup with NSCollectionViews
Actually I already have an alternative (code) solution, instead of binding an IBOutlet to an ArrayController, I could just call setContent on my detailedView in observeValueForKeyPath (see hint in the question). But I would prefer getting it to work through IB only, since everything else is already in place. On Wed, Jun 18, 2014 at 9:33 PM, Gordon Apple g...@ed4u.com wrote: That part should work. I was referring to the view controller’s representedObject, if you are using such a view controller in a view nib and trying to bind the collection view to an array controller through the view controller’s representedObject. On 6/18/14 1:34 PM, Hajder Rabiee hajd...@gmail.com wrote: The application consists of one main xib and its File's Owner is a subclass of NSWindowController. Can you further explain as to which binding to an array controller that is not possible? The only places where 'representedObject' is present is in the item prototypes for NSCollectionView. I.e. the ones that are added automatically when dragging an NSCollectionView in IB. On Wed, Jun 18, 2014 at 7:09 PM, Gordon Apple g...@ed4u.com wrote: I’m not clear as to what your view/nib structure is. If you are using a view nib, I recommend using a custom viewController and, in awakeFromNib, setting a local property (maybe from an IBOutlet) to the array controller. Trying to bind anything to an array controller through a view controller’s representedObject does not work. On 6/18/14 8:28 AM, cocoa-dev-requ...@lists.apple.com http://cocoa-dev-requ...@lists.apple.com cocoa-dev-requ...@lists.apple.com http://cocoa-dev-requ...@lists.apple.com wrote: I am having trouble getting the master-detail binding configuration setup correctly. I've sat down far too many hours trying to debug this and I hope anyone can give me a hint on how to solve this issue. The full problem description can be found already at *http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-binding-configuration http://stackoverflow.com/questions/24190299/nscollectionview-master-detail-binding-configuration* -- Med vänliga hälsningar / Best Regards Hajder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
On 19 Jun 2014, at 4:53 am, Daniel DeCovnick danhd...@mac.com wrote: Yes. You can either use key-value coding: [[self valueForKey:myString] release]; [value release]; These invocations of -release appear to be erroneous. Why do you have them there? If you think they should be there as a matter of routine, your understanding of memory management is probably faulty. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
On 19 Jun 2014, at 4:53 am, Daniel DeCovnick danhd...@mac.com wrote:
Yes. You can either use key-value coding: [[self valueForKey:myString]
release];
[value release];
These invocations of -release appear to be erroneous. Why do you have them
there? If you think they should be there as a matter of routine, your
understanding of memory management is probably faulty.
--Graham
The reason for this is I have several classes with only properties (no
methods other than getters/setters created with synthesize).
The method propertyKeys (below) is used to simplify and shorten the code in
these classes since I want to encode/decode and (upon dealloc), release all
the properties.
In the example below there is only one property, but in reality there are
many.
The interface looks like:
@interface MyClass : NSObject NSCoding
{
NSNumber* someValue;
}
@property (nonatomic, retain) NSNumber* someValue;
The implementation looks like:
@implementation MyClass
@synthesize someValue;
-(id)init
{
if (self = [super init])
{
[self setSomeValue:[NSNumber numberWithInt:3];
}
return self;
}
-(void)dealloc
{
for (NSString* key in [self propertyKeys])
[[self valueForKey:key] release];
[super dealloc];
}
-(id)initWithCoder:(NSCoder *)coder
{
if (self = [self init])
{
for (NSString* key in [self propertyKeys])
{
if ([coder containsValueForKey:key])
[self setValue:[coder decodeObjectForKey:key] forKey:key];
}
}
return (self);
}
-(void)encodeWithCoder:(NSCoder *)coder;
{
for (NSString* key in [self propertyKeys])
[coder encodeObject:[self valueForKey:key] forKey:key];
}
-(NSArray *)propertyKeys
{
NSMutableArray* propertyKeyArray =
[[[NSMutableArray alloc] init] autorelease];
unsigned int outCount, i;
objc_property_t* properties =
class_copyPropertyList([self class], outCount);
if (properties)
{
for(i = 0; i outCount; i++)
{
objc_property_t property = properties[i];
const char* propName = property_getName(property);
if(propName)
{
NSString* propertyName =
[NSString stringWithUTF8String:propName];
[propertyKeyArray addObject:propertyName];
}
}
free(properties);
}
return (propertyKeyArray);
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
On 19 Jun 2014, at 10:57 am, Trygve Inda cocoa...@xericdesign.com wrote:
The method propertyKeys (below) is used to simplify and shorten the code in
these classes since I want to encode/decode and (upon dealloc), release all
the properties.
-(void)dealloc
{
for (NSString* key in [self propertyKeys])
[[self valueForKey:key] release];
This looks pretty smelly.
I can understand your motivation, but I think this could end up being
problematic if later you want to generalise or subclass your object. If a
subclass adds to the -propertyKeys, it could find them over-released, because
the base class has already released them (or else it will need to rely on this
implementation detail of the base class, which is knowledge it shouldn't
require). If it overrides any property getter to do something different,
releasing the result is probably going to be wrong. If you declare any
properties anywhere to be anything other than 'retain' it's going to be wrong.
You might argue that you don't intend to subclass or generalise or use any
properties other than 'retain', and it works as it stands, and that would be
true, but there is a more generic way that is no more work.
Ideally, your -dealloc method should mirror your -init method, so that you have
each property set to nil listed individually, just as -init sets each one
individually. Sure, that's tedious if you have hundreds of properties, but it's
at least reliable with no nasty surprises. If you are determined to iterate a
list, then at least use the setter, passing nil, rather than the getter, and
calling release. (That also allows you to change a property to 'assign' or
'copy' if necessary without creating a bug).
I ought to mention that I used something very close to your scheme a while ago
to try and save myself a load of tedious coding to init, archive, dearchive and
dealloc a whole bunch of properties. At first it seemed like a huge win, but
I've been regretting and undoing it ever since, because every time I come to
actually use one of these objects, I find these shortcuts not doing exactly
what they need to do. Having said that I am subclassing, often in ways I didn't
originally expect to be doing.
-(NSArray *)propertyKeys
{
NSMutableArray* propertyKeyArray =
[[[NSMutableArray alloc] init] autorelease];
Just as a final comment, why not make this a class method, and cache the array
in a static? It never changes for a given class, so rebuilding it every time is
an unnecessary waste of time. OK, that is possibly premature optimisation, but
this sort of case is something that makes sense to optimise by design whether
it matters or not.
It would probably also be better if this method didn't automatically enumerate
the properties using property_getName, but built it from explicit string
literals (even though you then have to list them individually). It means
properties added by a subclass are exclusively the domain of the subclass, as
they should be, and that properties that you want to exclude from archiving,
KVO, etc can be simply omitted from the list as needed.
So my arguments against your approach boil down to problems if you subclass,
which you will probably say you never intend to do. I thought that I wouldn't
be subclassing as well :)
A performance related argument: using property getters and setters in
-initWithCoder: and -encodeWithCoder: can bring with them serious performance
issues. Might not matter in your case, or in most cases, but it really adds up
if you have a large and complex object graph. A recent exercise to set ivars
directly in -initWithCoder: instead of using property setters saw a 100 - 600x
speed improvement when reading a file for a graph with ~10,000 objects. Just
sayin'.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
On 19 Jun 2014, at 10:57 am, Trygve Inda cocoa...@xericdesign.com wrote:
The method propertyKeys (below) is used to simplify and shorten the code in
these classes since I want to encode/decode and (upon dealloc), release all
the properties.
-(void)dealloc
{
for (NSString* key in [self propertyKeys])
[[self valueForKey:key] release];
Ideally, your -dealloc method should mirror your -init method, so that you
have each property set to nil listed individually, just as -init sets each one
individually. Sure, that's tedious if you have hundreds of properties, but
it's at least reliable with no nasty surprises. If you are determined to
iterate a list, then at least use the setter, passing nil, rather than the
getter, and calling release. (That also allows you to change a property to
'assign' or 'copy' if necessary without creating a bug).
I would think 'copy' would still be ok with this (for example in the case of
NSStrings) since that should still be released. For 'assign' I can see the
advantage.
So this would be better?
for (NSString* key in [self propertyKeys])
[self setValue:nil forKey:key];
I can't at all see how I would ever subclass this, but I'll certainly give
the rest of your post some serious thought. Obviously if I ever do need to
subclass, I'll have to revert to listing each property on its own for
code/decode and dealloc.
Thanks,
Trygve
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Send msg to object by nameed NSString;
A performance related argument: using property getters and setters in -initWithCoder: and -encodeWithCoder: can bring with them serious performance issues. Might not matter in your case, or in most cases, but it really adds up if you have a large and complex object graph. A recent exercise to set ivars directly in -initWithCoder: instead of using property setters saw a 100 - 600x speed improvement when reading a file for a graph with ~10,000 objects. Just sayin'. Should I be doing: self.myProperty = [coder decodeObjectForKey:kMyProperty]; (isn't that effectively the same as a getter/setter)? Guessing it would be better as: myProperty = [[coder decodeObjectForKey:kMyProperty] retain]; 100x - 600x is a big hit. Trygve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
