Re: Passing an object to a custom sheet

[Quincey Morris]

On Apr 4, 2011, at 13:29, Torsten Geise wrote:

> So far, so good. My problem starts with passing objects to the dialog or 
> passing the content of the NSTextfield back to the caller. In the showDialog 
> function, I already have an instance to DialogController (instance 1). When 
> the NIB file gets loaded, it creates a second instance of DialogController 
> (instance 2) but containing the same instance of "window". 

OK, you have a few conceptual problems here. This DialogController is the cause 
of your problems.

-- The very brief sample code in the Sheet Programming Guide doesn't use an 
auxiliary controller. Presumably, the code it gives for using a custom sheet 
would go directly in the app delegate (or something like that). That's fine for 
a very simple sheet, but not much guidance when you want to use a separate 
controller object.

-- It's not clear, from your description of what you've done, what you expect 
the DialogController to *do* for you. Part of your trouble is you've decided 
you need one (or several), but you don't know what to use it for.

-- If you're going to use a controller, you may as well use a 
NSWindowController subclass, rather than rolling your own. A window controller 
works as well for sheets as it does for regular windows.

-- You shouldn't have 2 instances of the controller object. Presumably, you 
created one in your app delegate, and put a second one in the xib file, or 
created a second one manually. Don't do that!

If you take care of these problems, you should be a lot closer to your goal.


___

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: Passing an object to a custom sheet

[Joanna Carter]

Hi Torsten

> When I want to use an Object in the "onOkButtonPressed" function, how can I 
> set this object in instance #2? [NSBundle loadNibNamed:@"Dialog" owner:self] 
> does not return a pointer to the instance. In opposite, when "didEndSheet" is 
> called, I'm back in instance#1 without any knowledge about the value of 
> NSTextfield of instance#2.

The way I would usually handle this would be to add an extra -init method, 
which takes the object as a parameter, to the controller class, and hold the 
object in a private ivar in the controller.

Joanna

--
Joanna Carter
Carter Consulting

___

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 NSCache Eviction Behaviour

[Dalmazio Brisinda]

On 2011-04-05, at 2:37 AM, Ken Thomases wrote:

> On Apr 4, 2011, at 11:34 AM, Dalmazio Brisinda wrote:
> 
>> 2) The larger issue. The documentation states:
>> 
>> "By default, NSDiscardableContent objects in the cache are automatically 
>> removed from the cache if their content is discarded, although this 
>> automatic removal policy can be changed. If an NSDiscardableContent object 
>> is put into the cache, the cache calls discardContentIfPossible on it upon 
>> its removal."
>> 
>> So I set the eviction policy to NO (above) so objects are never evicted.
> 
> I don't think that's what that means.  Setting it to YES (or leaving it at 
> its default), means that the NSCache will more-or-less-immediately evict 
> NSDiscardableContent objects whose contents are discarded, without regard for 
> memory pressure (or count or cost).  Setting it to NO, does not mean that 
> objects are not evicted.  It simply means that NSCache isn't "eager" about 
> evicting NSDiscardableContent objects whose content have been discarded.  It 
> will let them stick around until the normal eviction process is provoked.

> 
> Put another way, NSDiscardableContent and NSCache are independent.  They can 
> be used separately from one another.  NSDiscardableContent objects merely 
> support the notion of discarding their contents, whether or not they are in 
> an NSCache.  (NSPurgeableData is one type of discardable object, and it 
> coordinates with the OS to discard its contents under memory pressure.  For 
> custom classes adopting NSDiscardableContent, you'd have to make your own 
> arrangements for content to be discarded.)  NSCache will evict its content 
> whether or not they are discardable.  However, NSCache is aware of 
> NSDiscardableContent and will, as an optional optimization, eagerly evict 
> discarded objects.
> 
> I don't know that there's a real good solution for something like NSCache but 
> for which you can prevent it from evicting stuff.  I suppose, you can put 
> stuff in it, but also keep it retained elsewhere.  Then, you can use the 
> delegate method to learn when NSCache believes there's reason to evict 
> things.  That will give you some visibility into the system's mechanism for 
> tracking memory pressure.  However, that won't actually let you prevent the 
> item from being evicted from the cache.  It just means the eviction will not 
> lead to the deallocation of the item.  (An alternative approach would be to 
> retain the object within the delegate method if you want to keep it.)
> 
> The problem is, once the item is evicted from the cache, you'd like to re-add 
> it to make sure the cache has a true representation of what you're keeping 
> around.  But if you re-add it immediately, that might cause NSCache to 
> immediately re-evict it.  (Also, it's not legal to re-add it from the 
> delegate callback.)

Thanks for that explanation. It seems I misunderstood the NSCache 
documentation. 

It's too bad that NSCache doesn't have an LRU or similar user-definable 
eviction policy setting. This is all that would be needed to make it much more 
useful generally. If resources are low, it could still evict all objects it 
needs to -- but at least we would have the option of having this done in an 
pre-defined order that's friendly to a variety of application needs. The 
current approach severely limits the utility of this type of cache. But seeing 
as it's a relatively new to Cocoa, I guess I should be grateful it's available 
at all, even if in it's current rather limited form.

I guess I'll have to rethink my design. Pity. NSCache looked so promising.


> 
> 
>> Okay. So implementing the delegate method cache:willEvictObject: shows it 
>> never gets called. Which means the object is not actually getting evicted.
> 
> Another explanation is that you may have a typo in your definition of that 
> method, such that NSCache is not finding it via respondsToSelector:.  (Why 
> that delegate protocol method is @optional is beyond me.  Had it been 
> @required, such bugs would not be possible.)

Hmm. Well you were right -- this turned out to be developer error. Though I 
implemented the correct method, I hadn't conformed to the protocol. And it 
seems that NSCache is checking protocol conformance in addition to 
respondsToSelector.


> 
> It's also possible that was due to NSCache believing that the items were 
> discarded.  Maybe for those, it feels free to evict without calling the 
> delegate.  On the other hand, it may just be a bug.  You might look into 
> libcache/cache.h, which is the low-level API for the same sort of 
> functionality.  That might avoid any bug that NSCache might have in this 
> respect.
> 
> Regards,
> Ken
> 

I'll have a closer look at libcache/cache.h and see if I can bend it to my 
application needs. Not sure if I want to re-implement NSCache to support 
user-defined eviction policies at this time.

Thanks for your help.

Best,
Dalmazio





smime.p7s
Description: S/MIME cryptographic s

Re: Passing an object to a custom sheet

[Graham Cox]

On 05/04/2011, at 6:29 AM, Torsten Geise wrote:

> - DialogController is of type NSObject and acts a the File's Owner of 
> Dialog.xib.

This will work, but it's more conventional (and has certain advantages) to 
subclass NSWindowController instead of NSObject here. After all, you are 
controlling a window.

> 
> So far, so good. My problem starts with passing objects to the dialog or 
> passing the content of the NSTextfield back to the caller. In the showDialog 
> function, I already have an instance to DialogController (instance 1). When 
> the NIB file gets loaded, it creates a second instance of DialogController 
> (instance 2) but containing the same instance of "window". 


Well, you definitely only want one instance. Either you create it, or you have 
it in the nib, but not both.

The usual case is to use NSWindowController and create it yourself, such as 
calling [[NSWindowController alloc] initWithWindowNibName:]; This 
automatically passes itself as File's Owner for the given nib. That said, what 
you have is OK enough. But if you also added an instance of the controller to 
the nib, remove it.

> When I want to use an Object in the "onOkButtonPressed" function, how can I 
> set this object in instance #2? [NSBundle loadNibNamed:@"Dialog" owner:self] 
> does not return a pointer to the instance. In opposite, when "didEndSheet" is 
> called, I'm back in instance#1 without any knowledge about the value of 
> NSTextfield of instance#2.


Your controller should abstract the functional meaning of the dialog for its 
clients. By that I mean that it's incorrect to expose the inner parts of the 
dialog (text fields and so on) to code outside the controller. Instead, you 
should have methods on the controller for getting information in abstract 
terms, e.g. -countOfWidgetsString which internally accesses the text field's 
contents via the IBOutlet. That allows you to complete change the inner design 
of the controller/dialog without affecting what it *means* to the outside world.

Once you do that, the answer to your question should be obvious. You just ask 
the controller for the information you want, and it gets it by some internal 
means and returns it.

The remaining kink with sheets and other asynchronous dialogs is to have a way 
to tell the client that the information has been entered and is ready to use. 
Typically you do this by defining an informal (or formal, if you want to get 
fancy) delegate protocol and invoking that when the OK button is clicked. The 
method you call is a simple callback that the delegate can use as its cue to 
fetch the information it wants from the dialog controller (or you can bundle 
the information up in some form - a dictionary perhaps - and pass it to the 
delegate).

So typically you start the dialog with a method something like this on the 
controller:

- (void)beginGetWidgetCountDialogOnParentWindow:(NSWindow*) parent 
delegate:(id) delegate;

and when the delegate is called back (you'll need to store the delegate 
reference in the controller so that it can call it when the OK button gets 
clicked), you can ask it for its widget count (or whatever).

So, bottom line - craft the controller to handle the job it is required to do 
and DO NOT EXPOSE ITS INTERNALS TO THE OUTSIDE WORLD.


--Graham


___

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

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

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

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

Re: Odd NSCache Eviction Behaviour

[Graham Cox]

On 05/04/2011, at 7:01 PM, Dalmazio Brisinda wrote:

> Pity. NSCache looked so promising


You could roll your own cache class that has the same interface but uses a LRU 
algorithm internally. Then if NSCache is updated it would be a drop-in 
replacement. The only drawback with it at present (which might be considered 
rather major) is that there's no straightforward way to hook your own cache 
objects into the runtime such that it would automatically cause eviction when 
memory pressure is tight. On iOS I believe there is a hook for responding to 
low memory, but on Mac OS there isn't, unfortunately. The best you can do is to 
set some sort of high water mark limit that evicts the LRU objects whenever the 
cache is accessed. Doing that is obviously pretty straightforward.

--Graham


___

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

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

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

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

Re: Trying to subclass UISwitch

[Hank Heijink (Mailinglists)]

Typing "customize uiswitch" into Google returned this as the second hit: 
http://osiris.laya.com/projects/rcswitch/

Might be worth looking at.

Hank

On Apr 4, 2011, at 10:22 PM, Philip Ershler wrote:

> The first thing I tried to do was to subclass the UISwitch. But when one 
> looks at the docs for the UISwitch there are no Properties or Instance 
> Methods that one can override to change the "text" on the switch. And when 
> one looks at the origins of the UISwitch, there is nothing to be overridden 
> to change the text (or actually the images that contain text) either.
> 
> Inherits from 
> UIControl : UIView : UIResponder : NSObject
> Conforms to   
> NSCoding
> NSCoding (UIView)
> NSObject (NSObject)
> So when I hit The UISwitch class is not customizable. I threw in the towel.
> 
> Phil
> 
> On Apr 4, 2011, at 6:20 PM, Laurent Daudelin wrote:
> 
>> I think there is a difference between "customizable" and "not subclassable". 
>> The question I guess would be: did he try to subclass?
>> 
>> -Laurent.
>> -- 
>> Laurent Daudelin
>> AIM/iChat/Skype:LaurentDaudelin  
>> http://www.nemesys-soft.com/
>> Logiciels Nemesys Software   
>> laur...@nemesys-soft.com
>> 
>> On Apr 4, 2011, at 15:04, Luke the Hiesterman wrote:
>> 
>>> "The UISwitch class is not customizable."
>>> 
>>> And what he really wanted to do was customize the appearance.
>>> 
>>> Luke
>>> 
>>> On Apr 4, 2011, at 3:02 PM, Jeffrey Walton wrote:
>>> 
 On Mon, Apr 4, 2011 at 12:20 PM, Philip Ershler  
 wrote:
> Hi,
> After beating my head against the wall trying to subclass UISwitch, 
> so that I might change the "text" for the two states, I finally noticed 
> that there is a statement in the docs that UISwitch cannot be subclassed. 
> (Please no wise cracks that I should have seen that straight away, I get 
> to claim old eyes).
 Prohibiting subclassing is *not* mentioned here:
 http://developer.apple.com/library/ios/#documentation/uikit/reference/UISwitch_Class/Reference/Reference.html
 
>> 
>> ___
>> 
>> 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/ershler%40cvrti.utah.edu
>> 
>> This email sent to ersh...@cvrti.utah.edu
> 
> Philip R. Ershler Ph.D.
> University of Utah
> Cardiovascular Research and Training Institute
> 95 South 2000 East
> Salt Lake City, UT 84112-5000
> 
> phone: (801) 230-8771
> alt ph: (801) 587-9528
> fax: (801) 581-3128
> e-mail: ersh...@cvrti.utah.edu
> 
> 
> ___
> 
> 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/hank.list%40runbox.com
> 
> This email sent to hank.l...@runbox.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: Trying to subclass UISwitch

[Thomas Davie]

On 4 Apr 2011, at 17:31, Philip Ershler wrote:

> Outstanding, thank you very much!
> 
> Phil
> 
> On Apr 4, 2011, at 10:28 AM, Roger Dalal wrote:
> 
>> Phil:
>> 
>> Try http://osiris.laya.com/projects/rcswitch/ by Sascha Hoehne and Robert 
>> Chin. It is well done.
>> 
>> Roger Dalal
>> Assembled Apps

I didn't know this existed at the time I ended up writing my own, so the result 
is that I wrote my own a while back.  If for some reason you find this version 
unsatisfactory, I also have a version available under the BSD 3 part license 
here:

http://whataboutapp.co.uk/

Bob

___

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

lockFocus mystery in screensaver

[Gabriel Zachmann]

One of the users of my screensaver has reported a problem and sent in the 
system.log.

In it, I find this line:
System Preferences[324]: *** Assertion failure in -[ArtSaverView lockFocus], 
/SourceCache/AppKit/AppKit-949.54/AppKit.subproj/NSView.m:4755

It appears after the following steps that I do in my screensaver:
1. stopAnimation, so that -animateOneFrame does not get called
2. do something that takes a bit longer, and that changes some internal data
3. startAnimation.

I have read the documentation about NSView::lockFocus, but I am no wiser.

Does anyone have an idea, what might be causing this error message?
Do I miss something?

At the bottom, you can find the relevant code from stop-/startAnimation methods.

Any insights and suggestions will be highly appreciated.

Best regards,
Gabriel.

PS:

- (void) stopAnimation
{
asl_log( ...);
[someInfo writeToFile: path atomically: YES];
[super stopAnimation]; 
}

- (void) startAnimation
{
asl_log( ...);
[super startAnimation];
} 



smime.p7s
Description: S/MIME cryptographic signature
___

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: applicationWillTerminate not received

[Matt Neuburg]

On Sat, 02 Apr 2011 21:01:46 -0400, Jeffrey Walton  said:
>Hi All,
>
>I'm using NSLog and breakpoints to trace application life cycle
>messages on an iPhone. I'm receiving applicationDidBecomeActive,
>applicationWillResignActive, applicationDidEnterBackground,
>applicationWillEnterForeground, etc as expected.
>
>If I perform the following, the application does not appear to receive
>the applicationWillTerminate message.
>* enter background by pressing Home
>* double press Home to list tasks
>* delete the [background] task (tap down and hold for 'Red X')
>
>I planned on saving some state when the applicationWillTerminate was
>invoked. Are things working as expected? Should I abandon my plans to
>save state during termination?
>

Yes. Apple is clear about this. If you're going to live in a multitasking 
world, then assume you will *never* receive applicationWillTerminate. Save 
state when backgrounding (or before, incrementally, as Apple recommends). I can 
list for you the few situations in which applicationWillTerminate is received, 
if you really want me to, but I don't see what good that list would do you.

Alternatively, if you insist on working this way, then check the box that says 
you don't multitask.

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

diable localization

[Georg Seifert]

Hi,

I what to give my users the possibility to disable the localization of my app. 
Is there a way to tell the system (NSBundle?) to always load the english nibs?

Best
Georg___

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

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

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

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

Re: Trying to subclass UISwitch

[Philip Ershler]

This is the same link that Roger Dalal posted yesterday.

Thanks
On Apr 5, 2011, at 6:57 AM, Hank Heijink (Mailinglists) wrote:

> Typing "customize uiswitch" into Google returned this as the second hit: 
> http://osiris.laya.com/projects/rcswitch/
> 
> Might be worth looking at.
> 
> Hank
> 
> On Apr 4, 2011, at 10:22 PM, Philip Ershler wrote:
> 
>> The first thing I tried to do was to subclass the UISwitch. But when one 
>> looks at the docs for the UISwitch there are no Properties or Instance 
>> Methods that one can override to change the "text" on the switch. And when 
>> one looks at the origins of the UISwitch, there is nothing to be overridden 
>> to change the text (or actually the images that contain text) either.
>> 
>> Inherits from
>> UIControl : UIView : UIResponder : NSObject
>> Conforms to  
>> NSCoding
>> NSCoding (UIView)
>> NSObject (NSObject)
>> So when I hit The UISwitch class is not customizable. I threw in the towel.
>> 
>> Phil
>> 
>> On Apr 4, 2011, at 6:20 PM, Laurent Daudelin wrote:
>> 
>>> I think there is a difference between "customizable" and "not 
>>> subclassable". The question I guess would be: did he try to subclass?
>>> 
>>> -Laurent.
>>> -- 
>>> Laurent Daudelin
>>> AIM/iChat/Skype:LaurentDaudelin 
>>> http://www.nemesys-soft.com/
>>> Logiciels Nemesys Software  
>>> laur...@nemesys-soft.com
>>> 
>>> On Apr 4, 2011, at 15:04, Luke the Hiesterman wrote:
>>> 
 "The UISwitch class is not customizable."
 
 And what he really wanted to do was customize the appearance.
 
 Luke
 
 On Apr 4, 2011, at 3:02 PM, Jeffrey Walton wrote:
 
> On Mon, Apr 4, 2011 at 12:20 PM, Philip Ershler  
> wrote:
>> Hi,
>>After beating my head against the wall trying to subclass UISwitch, 
>> so that I might change the "text" for the two states, I finally noticed 
>> that there is a statement in the docs that UISwitch cannot be 
>> subclassed. (Please no wise cracks that I should have seen that straight 
>> away, I get to claim old eyes).
> Prohibiting subclassing is *not* mentioned here:
> http://developer.apple.com/library/ios/#documentation/uikit/reference/UISwitch_Class/Reference/Reference.html
> 
>>> 
>>> ___
>>> 
>>> 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/ershler%40cvrti.utah.edu
>>> 
>>> This email sent to ersh...@cvrti.utah.edu
>> 
>> Philip R. Ershler Ph.D.
>> University of Utah
>> Cardiovascular Research and Training Institute
>> 95 South 2000 East
>> Salt Lake City, UT 84112-5000
>> 
>> phone: (801) 230-8771
>> alt ph: (801) 587-9528
>> fax: (801) 581-3128
>> e-mail: ersh...@cvrti.utah.edu
>> 
>> 
>> ___
>> 
>> 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/hank.list%40runbox.com
>> 
>> This email sent to hank.l...@runbox.com
>> 
> 

Philip R. Ershler Ph.D.
University of Utah
Cardiovascular Research and Training Institute
95 South 2000 East
Salt Lake City, UT 84112-5000

phone: (801) 230-8771
alt ph: (801) 587-9528
fax: (801) 581-3128
e-mail: ersh...@cvrti.utah.edu


___

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: Trying to subclass UISwitch

[Philip Ershler]

On Apr 5, 2011, at 7:05 AM, Thomas Davie wrote:

> 
> On 4 Apr 2011, at 17:31, Philip Ershler wrote:
> 
>> Outstanding, thank you very much!
>> 
>> Phil
>> 
>> On Apr 4, 2011, at 10:28 AM, Roger Dalal wrote:
>> 
>>> Phil:
>>> 
>>> Try http://osiris.laya.com/projects/rcswitch/ by Sascha Hoehne and Robert 
>>> Chin. It is well done.
>>> 
>>> Roger Dalal
>>> Assembled Apps
> 
> I didn't know this existed at the time I ended up writing my own, so the 
> result is that I wrote my own a while back.  If for some reason you find this 
> version unsatisfactory, I also have a version available under the BSD 3 part 
> license here:
> 
> http://whataboutapp.co.uk/
> 
> Bob
> 

Thank You,
Phil___

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

Drawing custom group row in TableView

[Georg Seifert]

Hi,

I have a custom NSTableView want to draw my own group row background. What Is 
the best way to do that.

I subclassed NSTableView and use a subclass of NSTextfieldCell to draw the 
table. What I can’t figure out, what to overwrite to add my own drawing code. 
Any ideas?

Best
Georg___

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

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

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

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

AVFoundation and YouTube?

[John Michael Zorko]

Hello, all ...

I've used AVFoundation / AVAsset / AVPlayer / etc. to play both M3U8 and M4V 
content on iOS 4.3.1. I'd also like to use it to play YouTube content (so I can 
do animation / scaling stuff on the AVPlayerLayer). I've a couple of questions:

1. Is this possible with the iOS-optimized versions of YouTube content?
2. If so, how do I get the iOS-optimized version of the URL?

Regards,

John

___

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: applicationWillTerminate not received

[David Duncan]

On Sat, Apr 2, 2011 at 9:53 PM, Quincey Morris  
wrote:

> I think you'll need to force a low-memory termination to test the code path 
> through 'applicationWillTerminate:'. I couldn't see an easier way to make it 
> happen with an iOS 4.0 backgroundable multitasking-aware app.


Not even then. On a multitasking device one you go into the background you will 
either wake up or be SIGKILL'd, including for memory warnings.

On Apr 4, 2011, at 4:20 PM, Jeffrey Walton wrote:

> It sure would be nice if we could count on applicationWillTerminate
> all the time. A SIGKILL without applicationWillTerminate seems kind of
> rude :(


Is there any reason you can't save your state once you enter the background 
instead?
--
David Duncan

___

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: NSString, stringByAppendingPathComponent, and Canonicalization

[David Duncan]

On Apr 4, 2011, at 8:08 PM, Jeffrey Walton wrote:

> Hi All,
> 
> I need to accept a filename from the user.

Given the nature of the file system on iOS, do you really need to accept a file 
name from the user, or just a document title? Unless your supporting users 
syncing documents via some method that relies on filename, it is probably best 
to use arbitrary file names and use whatever the user gives you as a document 
title instead.
--
David Duncan

___

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: Drawing custom group row in TableView

[Corbin Dunn]

On Apr 5, 2011, at 7:36 AM, Georg Seifert wrote:

> Hi,
> 
> I have a custom NSTableView want to draw my own group row background. What Is 
> the best way to do that.
> 
> I subclassed NSTableView and use a subclass of NSTextfieldCell to draw the 
> table. What I can’t figure out, what to overwrite to add my own drawing code. 
> Any ideas?

Yeah, I have some ideas!

Override this method:

- (void)drawRow:(NSInteger)row clipRect:(NSRect)clipRect;

corbin


___

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

Dynamically Loading Code and Core Data Non-Standard Persistent Attributes

[Carter R. Harrison]

My Core Data application has a plugin architecture.  Plugins reside within 
their own bundles and of course are loaded dynamically at runtime.  I intend to 
encode instances of each plugin bundle's principal class just as Apple 
describes it in the section of the Core Data Programming Guide called 
"Non-Standard Persistent Attributes".  In this section it explains that you 
should create an attribute of type "Transformable" within your entity.  This 
particular attribute is encoded and decoded using NSKeyedArchiving.  So the 
instances of my plugins archive correctly, but when I relaunch the application 
and Core Data tries to unarchive them I receive an exception like: 

*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class 
(DiskSpaceAlert)

I can't tell exactly why this is happening.  My plugin class implements the 
NSCoding protocol.  I'm thinking that it's happening because at the time of 
unarchiving, my plugin's bundle has not been loaded and thus the 
NSKeyedArchiver can't find my class (DiskSpaceAlert in this case).  So I added 
code to dynamically load all of my plugin bundles prior to the point where they 
are unarchived but this hasn't fixed anything.

Can anybody help me out?  Thank you in advance.
___

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

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

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

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

Re: Odd NSCache Eviction Behaviour

[Dalmazio Brisinda]

On 2011-04-05, at 7:16 PM, Graham Cox wrote:

> 
> On 05/04/2011, at 7:01 PM, Dalmazio Brisinda wrote:
> 
>> Pity. NSCache looked so promising
> 
> 
> You could roll your own cache class that has the same interface but uses a 
> LRU algorithm internally. Then if NSCache is updated it would be a drop-in 
> replacement. The only drawback with it at present (which might be considered 
> rather major) is that there's no straightforward way to hook your own cache 
> objects into the runtime such that it would automatically cause eviction when 
> memory pressure is tight. On iOS I believe there is a hook for responding to 
> low memory, but on Mac OS there isn't, unfortunately. The best you can do is 
> to set some sort of high water mark limit that evicts the LRU objects 
> whenever the cache is accessed. Doing that is obviously pretty 
> straightforward.
> 
> --Graham

Thanks Graham. Your suggestion sounds like a good idea. 

I'll begin experimenting with duplicating the NSCache API, and just use a high 
water mark limit for the time being. 

I wonder if it's worthwhile to base this high-water mark on anything other than 
a static value? Like perhaps some physical resource-aware value?

Best,
Dalmazio



smime.p7s
Description: S/MIME cryptographic signature
___

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

special characters are destroyed when copying a string character by character

[Horst Jäger]

Hi,

I have noticed that special characters are destoryed when they are copied one 
by one from one string into another. Listed below is some demo code (demo.h, 
Demo.m) which yields the console log also listed below (Demo.log). 

It states that the String containig no special characters is copied properly 
while the other is not.

Any idea why?

Thanks in advance

Horst



 Demo.log 


2011-04-05 17:47:24.280 Demo[8890:207] Wurst Wurst 1
2011-04-05 17:47:24.281 Demo[8890:207] Käse K‰se 0

 /Demo.log 


 Demo.h 

@interface Demo : NSObject

+(NSString*)copyUnicharByUnicharString:(NSString*)src;

+(void)demo;

@end

 /Demo.h 


 Demo.m 

#import "Demo.h"


@implementation Demo

+(NSString*)copyUnicharByUnicharString:(NSString*)src{
NSMutableString* dst = [NSMutableString string];
NSUInteger length = [src length];
for(NSUInteger index = 0; index < length; ++index){
unichar chr = [src characterAtIndex:index];
[dst appendFormat:@"%c", chr];
}
return dst;
}

+(void)demo{

NSString* sausageString = @"Wurst"; // Wurst is the German word for 
sausage
NSString* cheeseString  = @"Käse" ; // Käse  is the German word for 
cheese

NSString* sausageStringCopy = [self 
copyUnicharByUnicharString:sausageString];
NSString* cheeseStringCopy  = [self 
copyUnicharByUnicharString:cheeseString ];

BOOL sausageStringIsEqualToSausageStringCopy = [sausageString 
isEqualToString:sausageStringCopy];
BOOL cheeseStringIsEqualToCheeseStringCopy   = [cheeseString  
isEqualToString:cheeseStringCopy ];

NSLog(@"%@ %@ %d", sausageString, sausageStringCopy, 
sausageStringIsEqualToSausageStringCopy);
NSLog(@"%@ %@ %d", cheeseString , cheeseStringCopy , 
cheeseStringIsEqualToCheeseStringCopy  );

}

@end

 Demo.m 












--
Horst Jäger h.jae...@medienkonzepte.de
Medienkonzepte  http://www.medienkonzepte.de/
Schaafenstr. 25, 50676 Köln, Germany
Tel +49 221 93187017  / Fax +49 221 93187029

___

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: special characters are destroyed when copying a string character by character

[Sherm Pendley]

On Tue, Apr 5, 2011 at 11:55 AM, Horst Jäger  wrote:
>
>                [dst appendFormat:@"%c", chr];

%c is the format specifier for 8-bit chars - use %C for 16-bit unichars.

sherm--

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

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

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

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

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

Re: special characters are destroyed when copying a string character by character

[Kyle Sluder]

On Tue, Apr 5, 2011 at 8:55 AM, Horst Jäger  wrote:
> Any idea why?

Because "unichar" is not the same thing as a grapheme.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/stringsClusters.html%23//apple_ref/doc/uid/TP40008025-SW1

--Kyle Sluder
___

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

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

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

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

Re: special characters are destroyed when copying a string character by character

[Kyle Sluder]

On Tue, Apr 5, 2011 at 9:31 PM, Kyle Sluder  wrote:
> On Tue, Apr 5, 2011 at 8:55 AM, Horst Jäger  
> wrote:
>> Any idea why?
>
> Because "unichar" is not the same thing as a grapheme.
>
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Strings/Articles/stringsClusters.html%23//apple_ref/doc/uid/TP40008025-SW1

And now reading your code again it's clear that Sherm's certainly more
correct than me… but even though a direct unichar-by-unichar should
work (and Sherm points out that your use of %c means you're not
copying unichars, hence your scrambling), the hairs on your neck
should prick up if you find yourself blindly enumerating unichars.

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

ScrollView Programming

[Jeffrey Walton]

Hi All,

I'm working from "Scroll View Programming Guide for Cocoa" [1]. All
items are IBOutlets (even the ScrollView), and all outlets are
verified in ViewDidLoad via ASSERTs (no asserts fire). I believe I
have followed the instructions under Creating a Scroll View in
Interface Builder. Unfortunately, there is no scrolling.

ViewDidLoad also includes the following:
  scrollView.scrollEnabled = YES;
  scrollView.contentSize = [self.view sizeThatFits:CGSizeZero];

After following Steps 1 - 4, what is the layout supposed to look like under IB?

+ File Owner
+ First Responder
+ View
  + Scroll View
+ Control 1
+ Control 2
+ ...

Or

+ File Owner
+ First Responder
+ Scroll View
  + View
+ Control 1
+ Control 2
+ ...

When I get to step 3 and [loosely] follow "Choose Layout > Make
subviews of > Scroll View", I get the first layout (View is parent of
ScrollView). But no scrolling.

My controls need about 610 px (height). Which View (vanilla View or
Scroll View) is supposed to 411 px (available screen), and which is
supposed to be 610 px (sized for controls)?

Finally, the documentation states to use ""Choose Layout > Make
subviews of > ...". I don't have "Make subviews of" in IB 3.2.6 (iOS
4.3). I only have an "Embed Objects In". And I can't select the "View"
(per Step 2) when making a subview - I can only select all the
Controls and embed all the controls.

Should I be working form a different document? Perhaps the doc is not for 3.2.X.

Jeff

[1] 
http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/NSScrollViewGuide/Articles/Creating.html
___

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: Dynamically Loading Code and Core Data Non-Standard Persistent Attributes

[Eli Bach]

On Apr 5, 2011, at 4:36 PM, Carter R. Harrison wrote:

> ...when I relaunch the application and Core Data tries to unarchive them I 
> receive an exception like: 
> 
> *** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class 
> (DiskSpaceAlert)
> 
> I can't tell exactly why this is happening.  My plugin class implements the 
> NSCoding protocol.  I'm thinking that it's happening because at the time of 
> unarchiving, my plugin's bundle has not been loaded and thus the 
> NSKeyedArchiver can't find my class (DiskSpaceAlert in this case).  So I 
> added code to dynamically load all of my plugin bundles prior to the point 
> where they are unarchived but this hasn't fixed anything.
> 
> Can anybody help me out?  Thank you in advance.

Now, I haven't investigated doing this at all, but you may need to do an extra 
step after loading your plugins, and that would be to get the objective-c 
runtime to insert your classes into the in-memory runtime structures.

You may need to query the class by name or try to manually instantiate/delete 
an instance of each class in the plugin [say, by calling a function in each 
plugin to do so].

It may also depend on how you are loading your plugins, as in, if you load them 
using an objective-c API, it may add your classes to the runtime when the 
plugin loads whereas if you use unix plugin code, it wouldn't.

Eli

___

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: ScrollView Programming

[Quincey Morris]

On Apr 5, 2011, at 22:54, Jeffrey Walton wrote:

> After following Steps 1 - 4, what is the layout supposed to look like under 
> IB?
> 
> + File Owner
> + First Responder
> + View
> + Scroll View
>   + Control 1
>   + Control 2
>   + ...
> 
> Or
> 
> + File Owner
> + First Responder
> + Scroll View
> + View
>   + Control 1
>   + Control 2
>   + ...

The second, not the first. Note that IB lies to you -- this isn't the view 
hierarchy. The scroll view is the parent of 3 views: the clip view view, and 
the 2 scrollers. The clip view is the parent of the "document" view***, which 
is the (single) view that actually contains your content.

> When I get to step 3 and [loosely] follow "Choose Layout > Make
> subviews of > Scroll View", I get the first layout (View is parent of
> ScrollView). But no scrolling.

Almost certainly your problem is that you failed to set the autoresizing 
springs correctly for the "document" view. In the simplest case, it should be 
anchored on all 4 sides, and be stretchy in both directions.




*** That's what the documentation calls the scroll view's content view. It has 
nothing to do with NSDocument, except that perhaps originally it was shorthand 
for "document contents" view. I think the clip view has another name in the 
documentation too, but I've forgotten what it is.

___

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: ScrollView Programming

[Quincey Morris]

On Apr 5, 2011, at 23:28, Quincey Morris wrote:

> Almost certainly your problem is that you failed to set the autoresizing 
> springs correctly for the "document" view. In the simplest case, it should be 
> anchored on all 4 sides, and be stretchy in both directions.

Gah! Said that backwards. If you do the above, it will of course never scroll 
because it will always get resized to the size of the clip view. It needs to be 
*bigger* than the clip view for scrolling to happen.

If it's just a view full of controls, it shouldn't be set to resize 
automatically at all.


___

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