Re: Printing a view + landscape printing

[Jean Suisse]

Thank you very much for your reply.
I can now print the right view. This view (Parent View) has only two large 
custom subviews in which I display graphics.

Currently, when I print Parent View, it is vertically spanned over two pages 
(which are printed) and horizontally spanned over two pages (which are not 
printed).
I tried to determine the size of the printable area of one page and to print a 
rectangle to materialize it, but I couldn't get it right. Here is the code:




NSPrintInfo* printInfo = [[NSPrintOperation currentOperation] 
printInfo];

NSSize paperSize = [printInfo paperSize];
NSSize printAreaSize = NSMakeSize(0.0, 0.0);

printAreaSize.height = paperSize.height - [printInfo topMargin]  - 
[printInfo bottomMargin];
printAreaSize.width  = paperSize.width  - [printInfo leftMargin] - 
[printInfo rightMargin];

// I tried with and without the code below. If I divide by (scale*2.0) 
then the rectangle fits the paper but is displayed across two pages
float scale = [[[printInfo dictionary] 
objectForKey:NSPrintScalingFactor] floatValue];
paperSize.width  = paperSize.width  / (scale);
paperSize.height = paperSize.height / (scale);

[NSBezierPath strokeRect:NSMakeRect(0, 0, paperSize.width, 
paperSize.height)];

Currently, the size I get for the with paper size is way too large, even when 
divided by scale. This code is executed in parent view.


On 21 janv. 2013, at 18:36, Keary Suska  wrote:

> On Jan 21, 2013, at 8:17 AM, Jean Suisse wrote:
> 
>> I have a non-document based application to which I would like to add 
>> printing support.
>> The main window (the one in the .xib created by default by Xcode) contains a 
>> split view.
>> 
>> Currently, when printing, I get only the left pane of the split view (at 
>> best) or the control that has the focus (a textfield for instance) at worse.
> 
> This likely has to do with which view is the first responder, and so is 
> receiving a -print: action that has a nil target. Although that is how the 
> menu is wired by default, I rarely find it useful. I generally use a custom 
> method (one not implemented by any NSResponder class), so you can capture the 
> print request.
> 
>> What would be the minimum change to perform in order to get the view in the 
>> right side of the split view to print itself in landscape (I would like to 
>> offer landscape by default to the user) ? I am happy with the rest of the 
>> print flow the way it is.
> 
> IIRC, unless otherwise specified, all built-in printing methods will use 
> +[NSPrintInfo sharedPrintInfo] to determine page settings. You can customize 
> your own NSPrintInfo and call +setSharedPrintInfo:. Or you can create your 
> own printing session and pass the print info to it.
> 
>> P.S.: I saw the Laying Out Page Content section in Printing Programming 
>> Guide, but I don't get how it is decided that the content of the view 
>> exceeds the size of a single page. I would prefer my view to be told to fit 
>> the selected page size (It is possible in my particular situation. I am 
>> printing graphics that can be resized to any size, to any ratio).
> 
> AFAIK, fit-to-page is not a Cocoa printing system feature. You will have to 
> do that yourself. In theory, the easiest way would be to determine the 
> scaling factor needed and set that in the NSPrintInfo. NSPrintInfo will tell 
> you the paper size and margins, from which you can determine the printable 
> area, then dividing that by the view frame or bounds.
> 
> 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: Printing a view + landscape printing

[Graham Cox]

All you should need to do is to set the (h,v) pagination mode of the 
NSPrintInfo to NSFitPagination. That's all I do to scale my entire document to 
a single piece of paper, and it "just works" in that it takes into account the 
paper orientation and everything for you.

Note that the view doesn't need to be especially aware of printing unless you 
have some special requirements such as headers, footers, or alternate 
formatting. You shouldn't need to examine print info settings to adjust the 
view's scale - the print system adjusts the coordinate system of the context it 
manages and the view just blindly works as if it were doing its normal thing.


On 22/01/2013, at 7:50 PM, Jean Suisse  wrote:

> Thank you very much for your reply.
> I can now print the right view. This view (Parent View) has only two large 
> custom subviews in which I display graphics.
> 
>> AFAIK, fit-to-page is not a Cocoa printing system feature.

It is.

--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: Printing a view + landscape printing

[Jean Suisse]

On 22 janv. 2013, at 10:29, Graham Cox wrote:

> On 22/01/2013, at 7:50 PM, Jean Suisse wrote:
> 
>> Thank you very much for your reply.
>> I can now print the right view. This view (Parent View) has only two large 
>> custom subviews in which I display graphics.
>> 
>>> AFAIK, fit-to-page is not a Cocoa printing system feature.
> 
> It is.

Indeed it is. 
Thank you so much for this valuable piece of information.
Here's the code that made it work:

NSPrintInfo* sharedPrintInfo = [NSPrintInfo sharedPrintInfo];
[sharedPrintInfo setHorizontalPagination:NSFitPagination];
[sharedPrintInfo setVerticalPagination:NSFitPagination];
[sharedPrintInfo setOrientation:NSLandscapeOrientation];

Now, the result fits one page, in landscape mode. However, the aspect/ratio of 
the view remains the same as displayed on screen.
How can I change the size (bounds) of the view and its subview but for printing 
only ? I could stretch the result, but the text on the graphics would appear 
stretched. ..
___

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: NSPointerArray on iOS - truly __weak?

[Mike Abdullah]

On 10 Dec 2012, at 20:26, Matt Neuburg  wrote:

> Bump. I'd still like to hear about this. The docs have a *huge* box saying 
> that iOS NSPointerArray is not doing __weak references, but it sure looks to 
> me like it is. But I don't know how to test. Thanks for any help. m.
> 
> On Fri, 30 Nov 2012 07:51:57 -0800, Matt Neuburg  said:
>> The docs for NSPointerArray say, in a big bold box right at the top:
>> 
>>> Important: NSPointerArray does not support weak references under Automatic 
>>> Reference Counting (ARC).
>> 
>> However, a [NSPointerArray weakObjectsPointerArray] does NULL an element 
>> that has been released through ARC; I can test this directly, and I've also 
>> been using NSPointerArray successfully to break retain cycles. So are the 
>> docs just lying (in a big bold box right at the top), or is this some other 
>> kind of weak reference (i.e. somehow weak, but not ARC-__weak)?

I spotted this elsewhere in the docs today:

> Starting in OS X v10.8, the Foundation framework offers the following 
> features and enhancements:
> 
> Support for zeroing weak references with enhancements to the NSMapTable, 
> NSHashTable, and NSPointerArray classes.

So I guess the regular docs just haven't been updated yet.
___

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: How can I get rid of this warning message?

[Matt Neuburg]

Well discussed here:

http://stackoverflow.com/questions/7017281/performselector-may-cause-a-leak-because-its-selector-is-unknown

m.

On Jan 22, 2013, at 1:29 AM, cocoa-dev-requ...@lists.apple.com wrote:

> Date: Mon, 21 Jan 2013 15:20:44 -0500
> From: Rick Aurbach 
> To: "cocoa-dev@lists.apple.com" 
> Subject: How can I get rid of this warning message?

> I am attempting to use the RTPTimer wrapper that Gordon Apple contributed to 
> this list. (Thanks, Gordon!)
> 
> It appears to work great, but I find that the class's executeSelector: method 
> generates a warning message.
> 
>> - (void) executeSelector:(NSTimer*)timer {
>>   if(self.target != nil) {
>>   if([self.target respondsToSelector:self.sel]) 
>>   [self.target performSelector:self.sel withObject:self];
>>   }
>>   else
>>   [self invalidate];
>> }
> 
> where sel is defined as @property(nonatomic) SEL sel;
> 
> The line containing the performSelector:withObject: method generates
> "PerformSelector may cause a leak because its selector is unknown".

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: Printing a view + landscape printing

[Kyle Sluder]

On Tue, Jan 22, 2013, at 02:20 AM, Jean Suisse wrote:
> Now, the result fits one page, in landscape mode. However, the
> aspect/ratio of the view remains the same as displayed on screen.
> How can I change the size (bounds) of the view and its subview but for
> printing only ? I could stretch the result, but the text on the graphics
> would appear stretched. ..

1. Implement -knowsPageRange: and -rectForPage: and do all the
pagination yourself.

2. Create a new instance of your view offscreen with the appropriate
dimensions and print _that_.

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

How do I use CGDisplayCapture() to capture an NSOpenGLView in a XIB?

[Clay Heaton]

OS X / Cocoa question:

I have a subclass of NSOpenGLView in a XIB (working with cocos2d). I want to 
capture the screen to disable the function keys, process switching, etc. while 
the app is running.

Given that I have an IBOutlet to the NSOpenGLView, how do I capture the screen 
in the App Delegate's  -(void) applicationDidFinishLaunching: method?

I've read through the Apple display capturing guide, yet I always end up with a 
black screen (instead of the proper contents of my NSOpenGLView) when I try to 
capture the display. I suspect that I'm not assigning the proper context when 
using CGDisplayCapture(), but I'm getting confused with contexts and can't 
figure out what's gone awry. 

For reference, here's the link to Apple's guide:
https://developer.apple.com/library/mac/#documentation/graphicsimaging/Conceptual/QuartzDisplayServicesConceptual/Articles/DisplayCapture.html

Thanks for any help,
Clay
___

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: NSPointerArray on iOS - truly __weak?

[Matt Neuburg]

That just repeats the question - as I said (and you quoted), "are the docs just 
lying?" The point is that I prefer not to guess. I would like to be told 
officially that on iOS (not Mac OS X) these classes are doing ARC-__weak 
references under ARC when asked for weak behavior. m.

On Jan 22, 2013, at 7:08 AM, Mike Abdullah  wrote:

> 
> On 10 Dec 2012, at 20:26, Matt Neuburg  wrote:
> 
>> Bump. I'd still like to hear about this. The docs have a *huge* box saying 
>> that iOS NSPointerArray is not doing __weak references, but it sure looks to 
>> me like it is. But I don't know how to test. Thanks for any help. m.
>> 
>> On Fri, 30 Nov 2012 07:51:57 -0800, Matt Neuburg  said:
>>> The docs for NSPointerArray say, in a big bold box right at the top:
>>> 
 Important: NSPointerArray does not support weak references under Automatic 
 Reference Counting (ARC).
>>> 
>>> However, a [NSPointerArray weakObjectsPointerArray] does NULL an element 
>>> that has been released through ARC; I can test this directly, and I've also 
>>> been using NSPointerArray successfully to break retain cycles. So are the 
>>> docs just lying (in a big bold box right at the top), or is this some other 
>>> kind of weak reference (i.e. somehow weak, but not ARC-__weak)?
> 
> I spotted this elsewhere in the docs today:
> 
>> Starting in OS X v10.8, the Foundation framework offers the following 
>> features and enhancements:
>> 
>> Support for zeroing weak references with enhancements to the NSMapTable, 
>> NSHashTable, and NSPointerArray classes.
> 
> So I guess the regular docs just haven't been updated yet.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: How do I use CGDisplayCapture() to capture an NSOpenGLView in a XIB?

[Kyle Sluder]

On Tue, Jan 22, 2013, at 07:50 AM, Clay Heaton wrote:
> 
> I've read through the Apple display capturing guide, yet I always end up
> with a black screen (instead of the proper contents of my NSOpenGLView)
> when I try to capture the display. I suspect that I'm not assigning the
> proper context when using CGDisplayCapture(), but I'm getting confused
> with contexts and can't figure out what's gone awry. 

Don't capture the display. It's discouraged nowadays because it will
prevent the user from seeing important things like the "Your battery is
about to die" message. It also doesn't get you any net performance gain;
fullscreen OpenGL contexts have been deprecated for a couple OS releases
now.

Send -enterFullScreenMode:withPresentationOptions: to your OpenGL view.
You can pass a ton of arguments to it to disable the menu bar, app
switching, etc.  If you want to render at a lower resolution than the
display, render to a texture of the appropriate size and then draw that
texture in a fullscreen quad.

--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: NSPointerArray on iOS - truly __weak?

[Kyle Sluder]

On Tue, Jan 22, 2013, at 07:54 AM, Matt Neuburg wrote:
> That just repeats the question - as I said (and you quoted), "are the
> docs just lying?" The point is that I prefer not to guess. I would like
> to be told officially that on iOS (not Mac OS X) these classes are doing
> ARC-__weak references under ARC when asked for weak behavior. m.

The OS X Release Notes are considered part of the official
documentation.

File a bug against the docs, but don't assume that the Release Notes are
lying to you.

--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: How do I use CGDisplayCapture() to capture an NSOpenGLView in a XIB?

[Clay Heaton]

That's actually what I'm doing at the moment:

NSApplicationPresentationOptions options = 
NSApplicationPresentationHideDock + 
NSApplicationPresentationDisableProcessSwitching + 
NSApplicationPresentationHideMenuBar;
NSNumber *presentationOptions = [NSNumber numberWithUnsignedLong:options];
NSArray *keys   = [NSArray arrayWithObjects:@"NSFullScreenModeAllScreens", 
@"NSFullScreenModeApplicationPresentationOptions", nil];
NSArray *values = [NSArray arrayWithObjects:[NSNumber numberWithBool:YES], 
presentationOptions, nil];
NSDictionary *fullScreenOptions = [[NSDictionary alloc] 
initWithObjects:values forKeys:keys];

[glView_ enterFullScreenMode:[NSScreen mainScreen] 
withOptions:fullScreenOptions];

There are a few problems:
- The F4 key still allows process switching (Kiosk mode bug with 
NSApplicationPresentationDisableProcessSwitching; radar ID 12358575)
- The function keys still pass through to the system (iTunes, brightness, etc.)

The application is for toddlers 
(https://itunes.apple.com/us/app/toddler-typer/id566326332?mt=12). Several 
months of use and feedback show that they find and find joy from pressing the 
keys that pass through to the system. Since I'm trying to create an environment 
where they won't mess up anything on the computer, I don't really want them 
switching processes, etc.

I tried to subclass NSApplication to capture the system keys, but they are 
dispatched to the system regardless of what I do therein.

Hence, I was trying to capture the screen. Any other ideas?

Thanks,
Clay

On Jan 22, 2013, at 11:00 AM, Kyle Sluder  wrote:

> On Tue, Jan 22, 2013, at 07:50 AM, Clay Heaton wrote:
>> 
>> I've read through the Apple display capturing guide, yet I always end up
>> with a black screen (instead of the proper contents of my NSOpenGLView)
>> when I try to capture the display. I suspect that I'm not assigning the
>> proper context when using CGDisplayCapture(), but I'm getting confused
>> with contexts and can't figure out what's gone awry. 
> 
> Don't capture the display. It's discouraged nowadays because it will
> prevent the user from seeing important things like the "Your battery is
> about to die" message. It also doesn't get you any net performance gain;
> fullscreen OpenGL contexts have been deprecated for a couple OS releases
> now.
> 
> Send -enterFullScreenMode:withPresentationOptions: to your OpenGL view.
> You can pass a ton of arguments to it to disable the menu bar, app
> switching, etc.  If you want to render at a lower resolution than the
> display, render to a texture of the appropriate size and then draw that
> texture in a fullscreen quad.
> 
> --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: Issue with Core Data Mapping Model

[Sean McBride]

On Thu, 17 Jan 2013 21:45:51 -0500, John Brayton said:

>I am building a mapping model between two versions of my Core Data
>model, and I am encountering a strange issue:
>
>* If I define six of the seven entity mappings I need in the mapping
>model, migrating the data works as expected.
>
>* When I add the seventh entity mapping, the migration fails with this error:
>  Persistent store migration failed, missing mapping model.
>
>* If I delete that seventh entity mapping, the migration works again.
>
>* I am trying to do the migration by calling addPersistentStoreWithType:
>… on the NSPersistentStoreCoordinator.  
>
>* Reading in both the source and destination models with
>NSManagedObjectModel initWithContentsOfURL:... works as expected.
>
>* Reading in the NSMappingModel with initWithContentsOfURL:… works as
>expected.
>
>* With the seventh entity mapping added, reading in the mapping model
>with [NSMappingModel mappingModelFromBundles:@[bundle]
>forSourceModel:source destinationModel:dest] returns null.

This sounds a lot like something I am seeing.  Do you see hash mismatches like 
described here:



I've spent hours on it, and as best as I can tell Xcode is generating invalid 
xcmappingmodel files.  Just the other day I've used a DTS incident on this, but 
have not heard back yet.  I'll follow up in this thread when I do.

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: How to avoid warning?

[Dave]

That's wont help because myClass is a variable created from a String.

as in:

-void methodXXX:(NSString*) theClassName

myClass = NSClassFromString(theClassName);
if (myClass == nil)
return;

myObj = [[myClass alloc] initWithManager:self]];
}


To whoever said write better code that has types defined, this code  
is fine. You can't know the Class here which is why I'm checking to  
see if the Class supports the selector first. I could use  
performSelector but not sure how that would work with the alloc method:


myObj = [[myClass alloc] performSelector(@selector 
("initWithManager:") withObject:self];


Would this work?

Cheers
Dave


On 21 Jan 2013, at 18:42, Quincey Morris wrote:


On Jan 21, 2013, at 10:14 , Dave  wrote:


myObj = [[myClass alloc] initWithManager:sel]];


I get a warning on the initWithManager: statement (Obviously), how  
to avoid the warning or otherwise fix it?


You need to #import a header file with an @interface declaration  
for the 'initWithManager:' method.


The rule is that when the compiler sees a message send to a  
receiver of type 'id' (which is the return type of 'alloc'), it  
needs to have seen *some* declaration of that method. If it has  
seen more than one declaration, BTW, the declarations must all be  
compatible in terms of parameter and return types.




___

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: How to avoid warning?

[Dave]

On 21 Jan 2013, at 18:44, Steve Sisak wrote:


At 6:14 PM + 1/21/13, Dave wrote:
if (class_RespondsToSelector(myClass,@selector(initWithManager:)  
== NO)

myObj = [[myClass alloc] init];
else
myObj = [[myClass alloc] initWithManager:sel]];

I get a warning on the initWithManager: statement (Obviously), how  
to avoid the warning or otherwise fix it?


You could try declaring initWithManager: in a category on the class  
visible only to your implementation code. (i.e. at the top of  
your .m file)


The class name is passed in as a string and the class is formed from  
that, so I can't pre-declare it. Please see my other reply.


Cheers
Dave


___

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: How to avoid warning?

[Dave]

On 21 Jan 2013, at 22:12, Jens Alfke wrote:



On Jan 21, 2013, at 10:14 AM, Dave  wrote:

if (class_RespondsToSelector(myClass,@selector(initWithManager:)  
== NO)


Off-topic: instead of using the Obj-C runtime’s C API, you can  
express this as
	if ([myClass instancesRespondToSelector: @selector 
(initWithManager:)] == NO)


—Jens


Ok, cool, thanks for that, I still have the same problem though when  
I call the initWithManager.


Cheers
Dave

___

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: How to avoid warning?

[Jean Suisse]

> myObj = [[myClass alloc] performSelector(@selector("initWithManager:") 
> withObject:self];
> 
> Would this work?
> 


You could do :

id myObj =[myClass alloc];
myObj = [myObj performSelector(@selector("initWithManager:") withObject:myObj];
___

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: How to avoid warning?

[Jean Suisse]

On 22 janv. 2013, at 18:34, Jean Suisse  wrote:

> 
>> myObj = [[myClass alloc] performSelector(@selector("initWithManager:") 
>> withObject:self];
>> 
>> Would this work?
>> 
> 
> 
> You could do :
> 
> id myObj =[myClass alloc];
> myObj = [myObj performSelector(@selector("initWithManager:") 
> withObject:myObj];


[Sorry, I did hit send by mistake]

This (above) implies that the manager is self. Not that myObj is used as self 
when calling init.

Or you could declare a protocol myProtocol that defines initWithManager: and 
have the following declaration for myObj:
id  myObj = …
This would avoid the use of @selector.
You could also test if myObj responds to the selector selector just after 
calling alloc.

Jean

___

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: How to avoid warning?

[Keary Suska]

On Jan 22, 2013, at 10:23 AM, Dave wrote:

> 
> On 21 Jan 2013, at 18:44, Steve Sisak wrote:
> 
>> At 6:14 PM + 1/21/13, Dave wrote:
>>> if (class_RespondsToSelector(myClass,@selector(initWithManager:) == NO)
>>> myObj = [[myClass alloc] init];
>>> else
>>> myObj = [[myClass alloc] initWithManager:sel]];
>>> 
>>> I get a warning on the initWithManager: statement (Obviously), how to avoid 
>>> the warning or otherwise fix it?
>> 
>> You could try declaring initWithManager: in a category on the class visible 
>> only to your implementation code. (i.e. at the top of your .m file)
> 
> The class name is passed in as a string and the class is formed from that, so 
> I can't pre-declare it. Please see my other reply.


If in fact myClass may be any number of classes that may implement certain 
methods, the "right" way to do this is using a protocol. Protocols are designed 
to fit this purpose. I don't recall, however, the exact method to hint to the 
compiler enough to avoid the warning. Importing the protocol header may be 
sufficient.

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: How to avoid warning?

[Dave]

On 22 Jan 2013, at 17:34, Jean Suisse wrote:



myObj = [[myClass alloc] performSelector(@selector 
("initWithManager:") withObject:self];


Would this work?




You could do :

id myObj =[myClass alloc];
myObj = [myObj performSelector(@selector("initWithManager:")  
withObject:myObj];


Thanks for this, I was wondering if that would work too. I want to  
pass self (the instance of the current class) to initWithManager  
though. So can I just use:


myObj = [myObj performSelector(@selector("initWithManager:")  
withObject:self];


Thanks
Dave


___

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: How to avoid warning?

[Dave]

On 22 Jan 2013, at 18:07, Keary Suska wrote:



On Jan 22, 2013, at 10:23 AM, Dave wrote:



On 21 Jan 2013, at 18:44, Steve Sisak wrote:


At 6:14 PM + 1/21/13, Dave wrote:
if (class_RespondsToSelector(myClass,@selector(initWithManager:)  
== NO)

myObj = [[myClass alloc] init];
else
myObj = [[myClass alloc] initWithManager:sel]];

I get a warning on the initWithManager: statement (Obviously),  
how to avoid the warning or otherwise fix it?


You could try declaring initWithManager: in a category on the  
class visible only to your implementation code. (i.e. at the top  
of your .m file)


The class name is passed in as a string and the class is formed  
from that, so I can't pre-declare it. Please see my other reply.



If in fact myClass may be any number of classes that may implement  
certain methods, the "right" way to do this is using a protocol.  
Protocols are designed to fit this purpose. I don't recall,  
however, the exact method to hint to the compiler enough to avoid  
the warning. Importing the protocol header may be sufficient.


This has to work with classes that exist already as well as classes  
that don't. If initWithManager is defined in the class in question  
"knows" what it is being called like this, if not then it defaults to  
the regular NSObject init.


For instance it could be NSString or NSArray that is the class, in  
which case it won't have "initWithManager" so it calls init instead.


All the Best
Dave


___

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: How to avoid warning?

[Jens Alfke]

On Jan 22, 2013, at 9:24 AM, Dave  wrote:

> Ok, cool, thanks for that, I still have the same problem though when I call 
> the initWithManager.

Others answered this already. To recap: The compiler needs to see a declaration 
of an -initWithManager: method before it parses this line. So you have to 
either #import the header that declares that method, or if there’s no such 
header, put a category interface at the top of this .m file that defines the 
method.

—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: How to avoid warning?

[Dave]

On 22 Jan 2013, at 18:26, Jens Alfke wrote:



On Jan 22, 2013, at 9:24 AM, Dave  wrote:

Ok, cool, thanks for that, I still have the same problem though  
when I call the initWithManager.


Others answered this already. To recap: The compiler needs to see a  
declaration of an -initWithManager: method before it parses this  
line. So you have to either #import the header that declares that  
method, or if there’s no such header, put a category interface at  
the top of this .m file that defines the method.


That won't work either, you have to use "performSelector:withObject:"  
which seems to do the trick nicely!


Cheers
Dave


___

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: How to avoid warning?

[John McCall]

On Jan 22, 2013, at 9:23 AM, Dave  wrote:
> That's wont help because myClass is a variable created from a String.

But it will help, because Quincey's suggestion is not contingent on the type of 
the object that you send the message to.  The compiler is merely asking that 
you have declared a method with that selector *somewhere* in this translation 
unit so that it knows (or at least has a really good guess) about the formal 
signature of the method you're calling.

This is because (1) we would like to do at least some minimal type-checking on 
the method call, like whether 'self' can be passed as that argument, and (2) 
calling conventions can differ depending on the formal signature of the method, 
and we need to get that right for the call to succeed.

You could argue that in the specific case of an init method, we should guess 
about what this signature is;  but (1) there really are exceptions to the 
conventions, even with init methods, and (2) there's really no good reason for 
you to not have at least one declaration somewhere in the translation unit.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to avoid warning?

[Andy Lee]

On Jan 22, 2013, at 1:26 PM, Jens Alfke  wrote:
> 
> On Jan 22, 2013, at 9:24 AM, Dave  wrote:
> 
>> Ok, cool, thanks for that, I still have the same problem though when I call 
>> the initWithManager.
> 
> Others answered this already. To recap: The compiler needs to see a 
> declaration of an -initWithManager: method before it parses this line. So you 
> have to either #import the header that declares that method, or if there’s no 
> such header, put a category interface at the top of this .m file that defines 
> the method.

To spell it out even more... when the compiler sees this:

myObj = [[myClass alloc] initWithManager:self];

...it knows that [myClass alloc] returns an id. Since it doesn't have any hint 
as to the class of that id, the compiler will be permissive/optimistic/trusting 
and allow any message to be sent to it without warning -- *IF* it has seen a 
declaration of that message somewhere, anywhere, for any class. So you need to 
force the compiler to see such a declaration. Even importing a totally 
unrelated class will do.

As has been suggested, you could import a class that declares initWithManager:. 
Or you could add your own declaration of something else -- it could be a 
category, a protocol, *anything* -- that declares the method.

// This works (category).
@interface NSObject (AvoidCompilerWarning)
- (id)initWithArg:(id)arg;
@end

// Or this also works (protocol).
@protocol AvoidCompilerWarning
- (id)initWithArg:(id)arg;
@end

--Andy


___

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

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

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

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

object.struct.element as lvalue

[Matt Neuburg]

We have dot-syntax for accessors, and we have dot-syntax for struct elements, 
and we can chain them, but not as an lvalue. It is legal to say

 x = object.struct.element

and

 object.struct = f

and

 struct.element = x

but not

 object.struct.element = x

I suppose this is because you can't use the very same accessor as a getter and 
a setter simultaneously, but really it's quite obvious what this means: it 
means means

 temp = object.struct
 temp.element = x
 object.struct = temp

So *why* can't the compiler just allow it to mean that, instead of making me 
write it all out by hand? There's no ambiguity as far as I can tell. The ARC 
compiler is supplying plenty of code behind the scenes, including temporary 
variables, so surely it wouldn't be onerous to do the same sort of thing here. 
m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: How to avoid warning?

[Jens Alfke]

On Jan 22, 2013, at 9:23 AM, Dave  wrote:

>> You could try declaring initWithManager: in a category on the class visible 
>> only to your implementation code. (i.e. at the top of your .m file)
> 
> The class name is passed in as a string and the class is formed from that, so 
> I can't pre-declare it. Please see my other reply.

Sure you can:

@interface SomeFictionalClassName
- (id) initWithManager: (Foo*)manager;
@end

Put that at the top of your source file and the warning will go away, because 
the compiler is now confident that there exists an -initWithManager: method. 
(The fact that you’ve declared it on a completely fictional class doesn’t 
matter.)

As others have said, though, it really sounds like what you want is a protocol 
that defines the -initWithManager: method. This is a better solution because it 
adds more type-safety — if you ever rename -initWithManager:, but don’t fix all 
the places it’s used, the compiler will then be able to complain about the 
places you missed, so you’ll avoid confusing runtime errors.

—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: How to avoid warning?

[Charles Srstka]

On Jan 22, 2013, at 12:58 PM, Andy Lee  wrote:

> // Or this also works (protocol).
> @protocol AvoidCompilerWarning
> - (id)initWithArg:(id)arg;
> @end

Really, a protocol is what you ought to be doing. Make a protocol with 
-initWithManager: in it, and then make all the classes that might get passed to 
this method comply with your protocol. Then, do this:

if ([myClass conformsToProtocol:@protocol(MyProtocol)])
myObj = [[myClass alloc] initWithManager:sel]];
else
myObj = [[myClass alloc] init];

The advantage to this method is a simple one: Suppose some random class happens 
to implement a method named -initWithManager:, but that method has nothing to 
do with your -initWithManager: other than a coincidental title, and takes a 
completely different type of object. Your original code will result in 
unpredictable behavior in this case (and probably throw an exception leading to 
a crash). If you use a protocol, you'll know not just that the method responds 
to something named -initWithManager:, but that it's *your* -initWithManager:

Charles

___

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: object.struct.element as lvalue

[John McCall]

On Jan 22, 2013, at 11:03 AM, Matt Neuburg  wrote:
> We have dot-syntax for accessors, and we have dot-syntax for struct elements, 
> and we can chain them, but not as an lvalue. It is legal to say
> 
> x = object.struct.element
> 
> and
> 
> object.struct = f
> 
> and
> 
> struct.element = x
> 
> but not
> 
> object.struct.element = x
> 
> I suppose this is because you can't use the very same accessor as a getter 
> and a setter simultaneously, but really it's quite obvious what this means: 
> it means means
> 
> temp = object.struct
> temp.element = x
> object.struct = temp
> 
> So *why* can't the compiler just allow it to mean that, instead of making me 
> write it all out by hand? There's no ambiguity as far as I can tell. The ARC 
> compiler is supplying plenty of code behind the scenes, including temporary 
> variables, so surely it wouldn't be onerous to do the same sort of thing 
> here. m.

You are correct that it is absolutely implementable with these semantics.  I 
think we have bugs open on it already, but you can "vote" by filing a new one.

One obvious concern with supporting this is the fear that somebody's going to 
write:
  obj.dimensions.x = x;
  obj.dimensions.y = y;
  obj.dimensions.width = width;
  obj.dimensions.height = height;
which is, yes, admittedly convenient, but which is massively less efficient 
than the alternative:
  obj.dimensions = (struct Dimensions) { x, y, width, height };
both because it does eight message sends instead of one and because it's likely 
to cause four separate notifications, three of them totally unnecessary, 
instead of one.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to avoid warning?

[Andy Lee]

On Jan 22, 2013, at 2:19 PM, Charles Srstka  wrote:

> On Jan 22, 2013, at 12:58 PM, Andy Lee  wrote:
> 
>> // Or this also works (protocol).
>> @protocol AvoidCompilerWarning
>> - (id)initWithArg:(id)arg;
>> @end
> 
> Really, a protocol is what you ought to be doing. Make a protocol with 
> -initWithManager: in it, and then make all the classes that might get passed 
> to this method comply with your protocol. Then, do this:
> 
> if ([myClass conformsToProtocol:@protocol(MyProtocol)])
>   myObj = [[myClass alloc] initWithManager:sel]];
> else
>   myObj = [[myClass alloc] init];
> 
> The advantage to this method is a simple one: Suppose some random class 
> happens to implement a method named -initWithManager:, but that method has 
> nothing to do with your -initWithManager: other than a coincidental title, 
> and takes a completely different type of object. Your original code will 
> result in unpredictable behavior in this case (and probably throw an 
> exception leading to a crash). If you use a protocol, you'll know not just 
> that the method responds to something named -initWithManager:, but that it's 
> *your* -initWithManager:

Makes sense, especially since it sounds like you have enough control of the 
class to declare it as conforming to the protocol.

To be extra fail-safe, you might want to perform a cast to be sure the right 
initWithManager: gets called:

if ([myClass conformsToProtocol:@protocol(MyProtocol)])
myObj = [(id )[myClass alloc] initWithManager:self];
else
myObj = [[myClass alloc] init];

--Andy

___

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

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

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

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

Re: How to avoid warning?

[Charles Srstka]

On Jan 22, 2013, at 1:28 PM, Andy Lee  wrote:

> On Jan 22, 2013, at 2:19 PM, Charles Srstka  wrote:
> 
>> On Jan 22, 2013, at 12:58 PM, Andy Lee  wrote:
>> 
>>> // Or this also works (protocol).
>>> @protocol AvoidCompilerWarning
>>> - (id)initWithArg:(id)arg;
>>> @end
>> 
>> Really, a protocol is what you ought to be doing. Make a protocol with 
>> -initWithManager: in it, and then make all the classes that might get passed 
>> to this method comply with your protocol. Then, do this:
>> 
>> if ([myClass conformsToProtocol:@protocol(MyProtocol)])
>>  myObj = [[myClass alloc] initWithManager:sel]];
>> else
>>  myObj = [[myClass alloc] init];
>> 
>> The advantage to this method is a simple one: Suppose some random class 
>> happens to implement a method named -initWithManager:, but that method has 
>> nothing to do with your -initWithManager: other than a coincidental title, 
>> and takes a completely different type of object. Your original code will 
>> result in unpredictable behavior in this case (and probably throw an 
>> exception leading to a crash). If you use a protocol, you'll know not just 
>> that the method responds to something named -initWithManager:, but that it's 
>> *your* -initWithManager:
> 
> Makes sense, especially since it sounds like you have enough control of the 
> class to declare it as conforming to the protocol.
> 
> To be extra fail-safe, you might want to perform a cast to be sure the right 
> initWithManager: gets called:
> 
> if ([myClass conformsToProtocol:@protocol(MyProtocol)])
>   myObj = [(id )[myClass alloc] initWithManager:self];
> else
>   myObj = [[myClass alloc] init];
> 
> --Andy

That's a good fix. In addition to being more fail-safe, that also lets clang 
and Xcode know exactly what you intend here, so that if you decide someday to 
do something like rename the initWithManager: method using Xcode's Refactor 
feature, it should get this invocation of the method as well.

Charles

___

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: How can I get rid of this warning message?

[Rick Aurbach]

Thank you for the explanation. I only started learning Objective-C, Cocoa, iOS, 
etc in August, so I'm still pretty much a newbie and appreciate learning 
something new.

In this particular case, the selector that is the argument to the 
performSelector: method is a callback selector for NSTimer and hence is known 
to return void. Therefore, using the #pragma to turn off this message is safe.

Thanks for the insight.

Rick Aurbach
Aurbach & Associates, Inc.

On Jan 21, 2013, at 2:45 PM, Greg Parker  wrote:

> On Jan 21, 2013, at 12:20 PM, Rick Aurbach  wrote:
>> It appears to work great, but I find that the class's executeSelector: 
>> method generates a warning message.
>> 
>>> - (void) executeSelector:(NSTimer*)timer {
>>>  if(self.target != nil) {
>>>  if([self.target respondsToSelector:self.sel]) 
>>>  [self.target performSelector:self.sel withObject:self];
>>>  }
>>>  else
>>>  [self invalidate];
>>> }
>> 
>> where sel is defined as @property(nonatomic) SEL sel;
>> 
>> The line containing the performSelector:withObject: method generates
>> "PerformSelector may cause a leak because its selector is unknown".
>> 
>> Ok, I agree that the selector is unknown, but we know from the previous line 
>> that the target responds to it.
> 
> That's not what it's complaining about. It's complaining because the ARC 
> compiler cannot see the name of the method you are calling, so ARC doesn't 
> know whether its return value needs to be released. 
> 
> 
>> So I'd like to prevent this particular warning. I'm sure I ought to know how 
>> do do this, but how do I go about removing this warning message? Ideally, 
>> I'd like to do this on a file (or occurrence) basis, so that I can make sure 
>> that other similar usages are similarly safe.
> 
> If you know the selectors you are calling do not return a retained object, 
> you can use #pragma clang diagnostic to disable warning 
> -Warc-performSelector-leaks around that line.
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler


___

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: object.struct.element as lvalue

[Matt Neuburg]

On Jan 22, 2013, at 11:25 AM, John McCall  wrote:

> On Jan 22, 2013, at 11:03 AM, Matt Neuburg  wrote:
>> We have dot-syntax for accessors, and we have dot-syntax for struct 
>> elements, and we can chain them, but not as an lvalue. It is legal to say
>> 
>> x = object.struct.element
>> 
>> and
>> 
>> object.struct = f
>> 
>> and
>> 
>> struct.element = x
>> 
>> but not
>> 
>> object.struct.element = x
>> 
>> I suppose this is because you can't use the very same accessor as a getter 
>> and a setter simultaneously, but really it's quite obvious what this means: 
>> it means means
>> 
>> temp = object.struct
>> temp.element = x
>> object.struct = temp
>> 
>> So *why* can't the compiler just allow it to mean that, instead of making me 
>> write it all out by hand? There's no ambiguity as far as I can tell. The ARC 
>> compiler is supplying plenty of code behind the scenes, including temporary 
>> variables, so surely it wouldn't be onerous to do the same sort of thing 
>> here. m.
> 
> You are correct that it is absolutely implementable with these semantics.  I 
> think we have bugs open on it already, but you can "vote" by filing a new one.
> 
> One obvious concern with supporting this is the fear that somebody's going to 
> write:
>  obj.dimensions.x = x;
>  obj.dimensions.y = y;
>  obj.dimensions.width = width;
>  obj.dimensions.height = height;
> which is, yes, admittedly convenient, but which is massively less efficient 
> than the alternative:
>  obj.dimensions = (struct Dimensions) { x, y, width, height };
> both because it does eight message sends instead of one and because it's 
> likely to cause four separate notifications, three of them totally 
> unnecessary, instead of one.
> 

I did think of that - though it wouldn't surprise me if the compiler were so 
smart that it could fix even that. :)

I'll file a bug; thanks. Would this be a bugreporter bug or do I need to talk 
to the clang people?

The real reason for my asking this question is that I'm having trouble 
justifying to the naive reader exactly *why* object.struct.element can't be an 
lvalue. At the moment, my proposed "you can't use the very same accessor as a 
getter and a setter simultaneously" is the best I've come up with. m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: How can I get rid of this warning message?

[Charles Srstka]

(Resending since I accidentally sent the first one from the wrong e-mail 
address. Please reply to this one instead of the other to avoid re-posting my 
private e-mail address to the list, where it will be vulnerable to spambots. 
Thanks!)

On Jan 22, 2013, at 1:38 PM, Rick Aurbach  wrote:

> Thank you for the explanation. I only started learning Objective-C, Cocoa, 
> iOS, etc in August, so I'm still pretty much a newbie and appreciate learning 
> something new.
> 
> In this particular case, the selector that is the argument to the 
> performSelector: method is a callback selector for NSTimer and hence is known 
> to return void. Therefore, using the #pragma to turn off this message is safe.
> 
> Thanks for the insight.

I'd still use GCD instead. Not only do you not need a #pragma, but you also get 
compile-time checking that will warn you if the method you're calling ever gets 
changed or removed. Using @selector can be a huge pain when the selector it 
refers to gets renamed or removed — the compiler doesn't check @selector at 
all, so everything will seem fine until you start noticing exceptions and 
crashes at runtime.

Plus, it's less code. Here's a timer in GCD:

int64_t delayInSeconds = 2;
dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * 
NSEC_PER_SEC);
dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
   [foo doSomethingWith:bar];
});

And, the first three lines of that code is auto-completed for you as soon as 
you start typing "dispatch_after" in Xcode, so the only thing you actually have 
to write is the contents of the block of code that should run when the timer 
fires (well, and changing the 2 to whatever time interval you're going for). No 
passing around selectors, no packing extra info into the timer's userInfo, no 
implementing a separate method to run when the timer fires. Simple and 
straightforward.

Charles
___

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: How can I get rid of this warning message?

[David Duncan]

On Jan 22, 2013, at 12:34 PM, Charles Srstka  wrote:

> int64_t delayInSeconds = 2;
> dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * 
> NSEC_PER_SEC);
> dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
>   [foo doSomethingWith:bar];
> });


Just note that the template has a bug – if you want to delay for a fractional 
number of seconds, be certain to change the type of 'delayInSeconds' to a 
floating point type.
--
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to avoid warning?

[Jens Alfke]

On Jan 22, 2013, at 10:15 AM, Dave  wrote:

> This has to work with classes that exist already as well as classes that 
> don't. If initWithManager is defined in the class in question "knows" what it 
> is being called like this, if not then it defaults to the regular NSObject 
> init.
> 
> For instance it could be NSString or NSArray that is the class, in which case 
> it won't have "initWithManager" so it calls init instead.

That will still work fine with protocols. NSString doesn’t implement your 
protocol, so your code skips the custom init and just calls -init instead.

If you don’t believe us, then try typing in and compiling the examples people 
have given, and experiment with them until you’re convinced. But this thread is 
kind of going around in circles, with you asking us for advice and then not 
accepting it.

—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: How to avoid warning?

[Dave]

On 22 Jan 2013, at 21:27, Jens Alfke wrote:



On Jan 22, 2013, at 10:15 AM, Dave  wrote:

This has to work with classes that exist already as well as  
classes that don't. If initWithManager is defined in the class in  
question "knows" what it is being called like this, if not then it  
defaults to the regular NSObject init.


For instance it could be NSString or NSArray that is the class, in  
which case it won't have "initWithManager" so it calls init instead.


That will still work fine with protocols. NSString doesn’t  
implement your protocol, so your code skips the custom init and  
just calls -init instead.


If you don’t believe us, then try typing in and compiling the  
examples people have given, and experiment with them until you’re  
convinced. But this thread is kind of going around in circles, with  
you asking us for advice and then not accepting it.




I just wanted rid of the warning which I have, so I'm happy. I tried  
with the protocols etc. but it makes the method very messy and I have  
to double up on local variables etc. The fact is that it's a one  
parameter method that accepts an id and returns an id. If someone did  
define "initWithManager" on a class then it's likely to match the  
method pattern anyway, so it probably wouldn't help stop problems  
like that occurring anyway, and I'm not defining the classes that  
have the "initWithManager" method in them, so I can't define the  
class as conforming to a protocol.


Bottom line, it works as it is and it isn't that fragile, so it ain't  
broke and ain't likely to break then leave it alone is my motto.


Thanks a lot for all your help
All the Best
Dave


___

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: object.struct.element as lvalue

[John McCall]

On Jan 22, 2013, at 11:59 AM, Matt Neuburg  wrote:
> On Jan 22, 2013, at 11:25 AM, John McCall  wrote:
>> On Jan 22, 2013, at 11:03 AM, Matt Neuburg  wrote:
>>> We have dot-syntax for accessors, and we have dot-syntax for struct 
>>> elements, and we can chain them, but not as an lvalue. It is legal to say
>>> 
>>> x = object.struct.element
>>> 
>>> and
>>> 
>>> object.struct = f
>>> 
>>> and
>>> 
>>> struct.element = x
>>> 
>>> but not
>>> 
>>> object.struct.element = x
>>> 
>>> I suppose this is because you can't use the very same accessor as a getter 
>>> and a setter simultaneously, but really it's quite obvious what this means: 
>>> it means means
>>> 
>>> temp = object.struct
>>> temp.element = x
>>> object.struct = temp
>>> 
>>> So *why* can't the compiler just allow it to mean that, instead of making 
>>> me write it all out by hand? There's no ambiguity as far as I can tell. The 
>>> ARC compiler is supplying plenty of code behind the scenes, including 
>>> temporary variables, so surely it wouldn't be onerous to do the same sort 
>>> of thing here. m.
>> 
>> You are correct that it is absolutely implementable with these semantics.  I 
>> think we have bugs open on it already, but you can "vote" by filing a new 
>> one.
>> 
>> One obvious concern with supporting this is the fear that somebody's going 
>> to write:
>> obj.dimensions.x = x;
>> obj.dimensions.y = y;
>> obj.dimensions.width = width;
>> obj.dimensions.height = height;
>> which is, yes, admittedly convenient, but which is massively less efficient 
>> than the alternative:
>> obj.dimensions = (struct Dimensions) { x, y, width, height };
>> both because it does eight message sends instead of one and because it's 
>> likely to cause four separate notifications, three of them totally 
>> unnecessary, instead of one.
>> 
> 
> I did think of that - though it wouldn't surprise me if the compiler were so 
> smart that it could fix even that. :)

To optimize this, we'd need some new and very strong language guarantees about 
what property accessors can actually do — essentially, that they're really just 
decorators on loads and stores to some logical object somewhere.  I can promise 
that there's a lot of existing code that wouldn't satisfy those rules.

In general, the compiler has to treat any message send, including those done as 
part of property accesses, as a hard abstraction barrier, even when we can see 
the class's implementation of the method.  That's because (1) we can't prove 
the non-existence of formal subclasses, and even if we could, (2) method and 
class swizzling are part of the language model.  So we can't ever devirtualize 
an ObjC message send or treat it as anything except a hard abstraction barrier, 
unless it's somehow annotated on the method declaration.

> I'll file a bug; thanks. Would this be a bugreporter bug or do I need to talk 
> to the clang people?

You're requesting an enhancement to the Objective-C language as implemented in 
Apple products;  you should file it with bugreporter.

> The real reason for my asking this question is that I'm having trouble 
> justifying to the naive reader exactly *why* object.struct.element can't be 
> an lvalue. At the moment, my proposed "you can't use the very same accessor 
> as a getter and a setter simultaneously" is the best I've come up with.

Heh.  And even that is actually incorrect, because you can do things like 
x.count += 6, which is translated as [x setCount: [x count] + 6] (except only 
evaluating 'x' once).

I would say that object.struct is a special kind of l-value that's limited in 
how it can be used.  You can use it as the l-value operand of a simple 
assignment, compound assignment, increment, or decrement operator, but any 
other use causes it to be converted to an r-value.

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Best guess at expressing a string as a variable

[jonat...@mugginsoft.com]

I have a generic descriptive title of a parameter and want to express it as a 
variable name within a script.

So if my title is "No more awesome today, please!" I will likely render this as 
"no-more-awesome-today-please" ( I can define the separator style).

I am targeting about 20 or so scripting languages so the range of what each 
will deem is a valid variable name is rather wide.
However I would like to deliver a reasonable default rendering.

Dealing with English seems not too troublesome but titles composed in other 
languages might be a different matter.

My current thinking is, regardless of the language, is to exclude all 
characters that are not members of NSCharacterSet + (id)letterCharacterSet.

Is  + (id)letterCharacterSet the best choice here?

Regards

Jonathan Mitchell
Mugginsoft LLP










___

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: Best guess at expressing a string as a variable

[Jean Suisse]

On 23 janv. 2013, at 00:28, "jonat...@mugginsoft.com"  
wrote:


> I have a generic descriptive title of a parameter and want to express it as a 
> variable name within a script.
> 
> So if my title is "No more awesome today, please!" I will likely render this 
> as "no-more-awesome-today-please" ( I can define the separator style).
> 
> I am targeting about 20 or so scripting languages so the range of what each 
> will deem is a valid variable name is rather wide.
> However I would like to deliver a reasonable default rendering.
> 
> Dealing with English seems not too troublesome but titles composed in other 
> languages might be a different matter.

Do you want to deal with other languages ? For instance Japanese, Chinese, 
Korean, Arabic, etc. ?
> 
> My current thinking is, regardless of the language, is to exclude all 
> characters that are not members of NSCharacterSet + (id)letterCharacterSet.
> 
> Is  + (id)letterCharacterSet the best choice here?

I don't know. Does it include characters in "すごくやる気がある" ?
I can only guess what your goal is. But can't you associate some unique 
variable name to strings you can't translate (for instance the hex 
representation of the bytes in the UTF8 string) ?

Jean





---
Jean Suisse
Institut de Chimie Moléculaire de l’Université de Bourgogne
(ICMUB) — UMR 6302


___

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: How do I use CGDisplayCapture() to capture an NSOpenGLView in a XIB?

[Ken Thomases]

On Jan 22, 2013, at 10:16 AM, Clay Heaton wrote:

> That's actually what I'm doing at the moment:
> 
>NSApplicationPresentationOptions options = 
> NSApplicationPresentationHideDock + 
> NSApplicationPresentationDisableProcessSwitching + 
> NSApplicationPresentationHideMenuBar;
>NSNumber *presentationOptions = [NSNumber numberWithUnsignedLong:options];
>NSArray *keys   = [NSArray arrayWithObjects:@"NSFullScreenModeAllScreens", 
> @"NSFullScreenModeApplicationPresentationOptions", nil];
>NSArray *values = [NSArray arrayWithObjects:[NSNumber numberWithBool:YES], 
> presentationOptions, nil];
>NSDictionary *fullScreenOptions = [[NSDictionary alloc] 
> initWithObjects:values forKeys:keys];
> 
>[glView_ enterFullScreenMode:[NSScreen mainScreen] 
> withOptions:fullScreenOptions];
> 
> There are a few problems:
> - The F4 key still allows process switching (Kiosk mode bug with 
> NSApplicationPresentationDisableProcessSwitching; radar ID 12358575)
> - The function keys still pass through to the system (iTunes, brightness, 
> etc.)
> 
> The application is for toddlers 
> (https://itunes.apple.com/us/app/toddler-typer/id566326332?mt=12). Several 
> months of use and feedback show that they find and find joy from pressing the 
> keys that pass through to the system. Since I'm trying to create an 
> environment where they won't mess up anything on the computer, I don't really 
> want them switching processes, etc.

Given that you're using -enterFullScreenMode:withOptions: and you do want to 
capture the screen, you should leave out 
NSFullScreenModeApplicationPresentationOptions.  The options that you're 
passing are all implicit in capturing the display anyway.

Also, NSFullScreenModeApplicationPresentationOptions and 
NSFullScreenModeAllScreens are identifiers.  You should use them as such, not 
as the contents of strings.  (I don't know if the value of the string values 
named by those identifiers happens to match the identifiers themselves.  Even 
if they do, you shouldn't rely on that.)

Cheers,
Ken


___

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

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

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

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

Re: Best guess at expressing a string as a variable

[Jens Alfke]

On Jan 22, 2013, at 3:28 PM, jonat...@mugginsoft.com wrote:

> Is  + (id)letterCharacterSet the best choice here?

The API docs say "Informally, this set is the set of all characters used as 
letters of alphabets and ideographs.”
Which very strongly implies it is not just ASCII, but covers all Unicode 
alphabets.

Some languages, like Java and Go, can handle non-ASCII letters in identifiers, 
but most can’t. I would stick with a character set consisting of only upper and 
lowercase ASCII letters, digits and the underscore. And you’d probably want to 
force the first character to be a lowercase letter since some languages assign 
special meaning to identifiers that start with a capital letter or with an 
underscore.

—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: Best guess at expressing a string as a variable

[Keary Suska]

On Jan 22, 2013, at 4:28 PM, jonat...@mugginsoft.com wrote:

> I have a generic descriptive title of a parameter and want to express it as a 
> variable name within a script.
> 
> So if my title is "No more awesome today, please!" I will likely render this 
> as "no-more-awesome-today-please" ( I can define the separator style).
> 
> I am targeting about 20 or so scripting languages so the range of what each 
> will deem is a valid variable name is rather wide.
> However I would like to deliver a reasonable default rendering.
> 
> Dealing with English seems not too troublesome but titles composed in other 
> languages might be a different matter.
> 
> My current thinking is, regardless of the language, is to exclude all 
> characters that are not members of NSCharacterSet + (id)letterCharacterSet.
> 
> Is  + (id)letterCharacterSet the best choice here?

+ alphanumericCharacterSet might be a better choice, and you also want to 
consider case-sensitivity. If your application is handling all tokenization and 
interpretation then it doesn't really matter what do you as long as it is 
sufficiently tokenize-able.

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: Best guess at expressing a string as a variable

[Keary Suska]

On Jan 22, 2013, at 6:18 PM, Jens Alfke wrote:

> On Jan 22, 2013, at 3:28 PM, jonat...@mugginsoft.com wrote:
> 
>> Is  + (id)letterCharacterSet the best choice here?
> 
> The API docs say "Informally, this set is the set of all characters used as 
> letters of alphabets and ideographs.”
> Which very strongly implies it is not just ASCII, but covers all Unicode 
> alphabets.
> 
> Some languages, like Java and Go, can handle non-ASCII letters in 
> identifiers, but most can’t. I would stick with a character set consisting of 
> only upper and lowercase ASCII letters, digits and the underscore. And you’d 
> probably want to force the first character to be a lowercase letter since 
> some languages assign special meaning to identifiers that start with a 
> capital letter or with an underscore.


I was thinking that by "language" the OP meant linguistic rather than 
programming. For the latter it is a bit easier to find the lowest common 
denominator, which is probably strictly ascii alpha and numbers, beginning with 
lowercase alpha and probably even a character limit of around 12. That would 
automatically exclude the identifier pattern example provided as most languages 
do not permit dashes in identifier names (that I know of). Additionally, for 
higher-level interpreted languages the app would need to understand identifier 
prefixes such as $, @ and % (and maybe &).

Best,

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: object.struct.element as lvalue

[Matt Neuburg]

On Jan 22, 2013, at 2:51 PM, John McCall  wrote:

> Heh.  And even that is actually incorrect, because you can do things like 
> x.count += 6, which is translated as [x setCount: [x count] + 6] (except only 
> evaluating 'x' once).

Ouch!

> 
> I would say that object.struct is a special kind of l-value that's limited in 
> how it can be used.  You can use it as the l-value operand of a simple 
> assignment, compound assignment, increment, or decrement operator, but any 
> other use causes it to be converted to an r-value.

Okay, I'll think of some new wording... :) Thx - m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: How do I use CGDisplayCapture() to capture an NSOpenGLView in a XIB?

[Clay Heaton]

Thanks, Ken.

I read the docs more carefully and looked at the full screen demo projects. As 
you mentioned, my understanding is that -enterFullScreenMode:withOptions: 
should capture the screen as long as 
NSFullScreenModeApplicationPresentationOptions is not present. That is 
confirmed in the NSView documents for the -enterFullScreenMode:withOptions:.

Looking at the CoreAnimationKioskStyleMenu sample project, there's this bit of 
code:
// go full screen, as a kiosk application 
[self enterFullScreenMode:[self.window screen] withOptions:NULL];

While that goes full screen and does prevent process switching, it still allows 
the iTunes function keys to pass through to the system (as well as the volume 
controls). Pressing F8 (play/pause) launches iTunes and causes music to play. 

I would like to intercept all key presses and only send the volume control keys 
through to the system. 

Things I have tried include:
- subclassing NSApplication and overriding - sendEvent: to capture all keys. 
The iTunes keys still pass through, though nothing else does.
- capturing the display with 
...
CGDirectDisplayID display = kCGDirectMainDisplay;
CGError err = CGCaptureAllDisplaysWithOptions(kCGCaptureNoFill);
...
- capturing the display with -enterFullScreenMode:withOptions:
- reading your posts from here 
http://www.cocoabuilder.com/archive/cocoa/231645-disabling-key-bindings.html

I'm at a loss - is there any way to intercept and disable the iTunes function 
keys?

Thanks,
Clay


On Jan 22, 2013, at 7:17 PM, Ken Thomases  wrote:

> 
> On Jan 22, 2013, at 10:16 AM, Clay Heaton wrote:
> 
>> That's actually what I'm doing at the moment:
>> 
>>   NSApplicationPresentationOptions options = 
>> NSApplicationPresentationHideDock + 
>> NSApplicationPresentationDisableProcessSwitching + 
>> NSApplicationPresentationHideMenuBar;
>>   NSNumber *presentationOptions = [NSNumber numberWithUnsignedLong:options];
>>   NSArray *keys   = [NSArray arrayWithObjects:@"NSFullScreenModeAllScreens", 
>> @"NSFullScreenModeApplicationPresentationOptions", nil];
>>   NSArray *values = [NSArray arrayWithObjects:[NSNumber numberWithBool:YES], 
>> presentationOptions, nil];
>>   NSDictionary *fullScreenOptions = [[NSDictionary alloc] 
>> initWithObjects:values forKeys:keys];
>> 
>>   [glView_ enterFullScreenMode:[NSScreen mainScreen] 
>> withOptions:fullScreenOptions];
>> 
>> There are a few problems:
>> - The F4 key still allows process switching (Kiosk mode bug with 
>> NSApplicationPresentationDisableProcessSwitching; radar ID 12358575)
>> - The function keys still pass through to the system (iTunes, brightness, 
>> etc.)
>> 
>> The application is for toddlers 
>> (https://itunes.apple.com/us/app/toddler-typer/id566326332?mt=12). Several 
>> months of use and feedback show that they find and find joy from pressing 
>> the keys that pass through to the system. Since I'm trying to create an 
>> environment where they won't mess up anything on the computer, I don't 
>> really want them switching processes, etc.
> 
> Given that you're using -enterFullScreenMode:withOptions: and you do want to 
> capture the screen, you should leave out 
> NSFullScreenModeApplicationPresentationOptions.  The options that you're 
> passing are all implicit in capturing the display anyway.
> 
> Also, NSFullScreenModeApplicationPresentationOptions and 
> NSFullScreenModeAllScreens are identifiers.  You should use them as such, not 
> as the contents of strings.  (I don't know if the value of the string values 
> named by those identifiers happens to match the identifiers themselves.  Even 
> if they do, you shouldn't rely on that.)
> 
> Cheers,
> Ken
> 

___

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

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

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

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

Re: Best guess at expressing a string as a variable

[jonat...@mugginsoft.com]

On 23 Jan 2013, at 00:05, Jean Suisse  wrote:

>> 
>> Dealing with English seems not too troublesome but titles composed in other 
>> languages might be a different matter.
> 
> Do you want to deal with other languages ? For instance Japanese, Chinese, 
> Korean, Arabic, etc. ?
The user can enter any text as a descriptive title describing a script input.
At present the app UI is English but the text fields are free form.
So any character in any script is valid.
Many scripting languages can accept UTF-8 variable names but my knowledge wanes 
when it comes to dealing with a wide range of languages.

>> 
>> My current thinking is, regardless of the language, is to exclude all 
>> characters that are not members of NSCharacterSet + (id)letterCharacterSet.
>> 
>> Is  + (id)letterCharacterSet the best choice here?
> 
> I don't know. Does it include characters in "すごくやる気がある" ?
That is the question. I don't know what range of character ranges + 
letterCharacterSet includes.
A better question might be what is the intended use of + letterCharacterSet. Is 
it locale dependent?

> I can only guess what your goal is. But can't you associate some unique 
> variable name to strings you can't translate (for instance the hex 
> representation of the bytes in the UTF8 string) ?
> 

Hmm. Maybe not. I want to keep the generated variable name legible.

Jonathan


___

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

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

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

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

Re: How do I use CGDisplayCapture() to capture an NSOpenGLView in a XIB?

[Ken Thomases]

On Jan 22, 2013, at 8:33 PM, Clay Heaton wrote:

> While that goes full screen and does prevent process switching, it still 
> allows the iTunes function keys to pass through to the system (as well as the 
> volume controls). Pressing F8 (play/pause) launches iTunes and causes music 
> to play. 
> 
> I would like to intercept all key presses and only send the volume control 
> keys through to the system. 

> I'm at a loss - is there any way to intercept and disable the iTunes function 
> keys?

Some research suggests the answer is "no".

The keys are routed to "rcd", the remote control daemon, very early in their 
processing.  rcd is hard-coded to know about various Apple apps and to route 
the keys to them.  Strangely, although it does actually have checks for the 
displays being captured, it only uses that for specific cases (like controlling 
Aperture and iPhoto) and routing of volume up and down keys.

Apparently, not even an event tap at the HID tap location sees the key events.
http://stackoverflow.com/questions/1053351/binding-to-media-keys-on-apple-keyboards-under-osx-10-5#answer-1055446

There are various horrible hacks floating around, like removing iTunes, 
patching iTunes, or patching rcd.  There are also workarounds like launching 
iTunes and putting it on a page where "play" is not a meaningful action, like 
the store.  Or launching QuickTime Player and leaving it idle, since rcd 
prefers a running app to a non-running one (among the ones it knows about).

I see that you previously tried PushSymbolicHotKeyMode() but it wasn't 
available in 64-bit.  You might try an experiment with a 32-bit test program 
just to see if it works.  That might be your only option.

Finally, you can open a Technical Support Incident with Apple Developer 
Technical Support.  Explain what you're trying to do and why and ask if they 
have a mean to accomplish it.

Good luck,
Ken


___

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

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

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

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

Re: Coordinate conversions in CALayer

[Graham Cox]

On 22/01/2013, at 4:35 PM, Andy Lee  wrote:

> On Jan 21, 2013, at 5:12 PM, Graham Cox  wrote:
>> My question is, is there a way to directly convert coordinates between two 
>> unrelated layers in a tree, or are these methods implemented by recursion up 
>> to a common parent node and then back down to the target layer? If I had 
>> some hint of how this was done in the real CALayer architecture it would 
>> help me avoid wasting time trying various blind alleys.
> 
> Unless and until someone chimes in with a more sophisticated solution, you 
> could convert the rect from layer A to the root layer, and from the root 
> layer to layer B, then find out if that bogs down performance.


Thanks Andy,

I'm doing something rather like this, and it works well enough. In fact I'm not 
sure there really is a need to translate between arbitrary layers across the 
tree - 99 times out of 100 I'm just transforming up or down one branch in the 
tree, and in practice the tree is usually shallow.

I think I need to change the focus of my question though, because before I can 
get to this, I need to work out precisely how I should be manipulating my 
transforms. As usual with transforms, what starts off looking straightforward 
turns into a mindbending nightmare quite quickly.

My model looks pretty similar to CALayer, so my layer objects have a bounds, 
frame, an anchor point, a transform and a position exactly as they are defined 
for CALayer.

When a layer draws its sublayer, it applies the following transformations to 
the context:

CGPoint anch = layer.anchorPoint;
CGRect  br = layer.bounds;
CGPoint pos = layer.position;

CGContextTranslateCTM( ctx, pos.x, pos.y );
CGContextConcatCTM( ctx, layer.transform );
CGContextTranslateCTM(ctx, -(br.origin.x + anch.x * br.size.width), 
-(br.origin.y + anch.y * br.size.height));


That works fine.

Where I'm getting into trouble is translating a rect from the layer's local 
coordinates back up to super. It works until I have a transform property that 
does something. So I'm doing this:

CGRect br = self.bounds;
CGPoint anch = self.anchorPoint;

CGAffineTransform tfm = CGAffineTransformMakeTranslation( 
-self.position.x, -self.position.y );

tfm = CGAffineTransformConcat( tfm, self.transform );   
//<-- this screws things up if it's not the identity matrix

return CGAffineTransformTranslate( tfm, (br.origin.x + anch.x * 
br.size.width), (br.origin.y + anch.y * br.size.height));

To create a transform that supposedly will transform from the superlayer TO the 
layer, and I then invert it to go back the other way. It works in the simple 
case, but a rotation transform upsets things. I've tried pretty much every 
combination of ordering different things in constructing the transform but this 
is the "best" result I get. Still wrong though. Funny, every time I think I 
have transforms figured out something turns up to show me I don't.


I just need someone to point out my error, then I think I'll be in business.


--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: Cococa-Dev : was [coredata count not fulfill fault after object delete]

[Martin Hewitson]

OK, finally near the bottom of this problem.

It turned out that I had an override of -didTurnIntoFault in my tree item 
entity. In there I was nil'ing out a couple of relationships (which are in 
principle nil'ed out by the nullify delete rule) - I did this while trying to 
track down some other document closing bug. These 3 lines of code made it into 
my test app, so I saw the problem there too. It's not clear to me why doing 
this caused this problem on 10.6.8 (and not on 10.7 or 10.8) but the Apple 
support guy said I shouldn't do it in -didTurnIntoFault.

Anyway, removing that override (which is not needed anyway) fixes the problem. 
Simple when you know!

Best wishes,

Martin

On Jan 15, 2013, at 05:41 PM, Martin Hewitson  
wrote:

> 
> On 14, Jan, 2013, at 03:31 PM, Jerry Krinock  wrote:
> 
>>> Will -autorelease work with ARC?
>> 
>> I don't think so.  I didn't realize you were using ARC.  I suppose you could 
>> opt out of ARC in your Method Replacement file, in order to compile that 
>> -autorelease.
>> 
>>> Could you hint how to do that? A category on NSTreeController?
>> 
>> 
>> I can't find the article on Apple's site any more, but here it is from the 
>> horses's mouth, probably written better…
>> 
>> http://mikeash.com/pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html
>> 
>> Method Replacement is a good occasional last resort, particularly in 
>> troubleshooting, but you can ship it if necessary.
> 
> Thanks for the pointers. Though after some further work, the test app now has 
> only a very few lines of custom code, and the 'bug' is still there. The use 
> of [NSTreeController selectedObjects] is gone, so that was a red herring 
> (though the retaining may still be going on behind the scenes). 
> 
> So I've opened a ticket with Apple to get some support. I'll post back if 
> they come up with a solution.
> 
> Many thanks,
> 
> Martin
> 
> 
> 
> 
> 


Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer 
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: martin.hewit...@aei.mpg.de
WWW: http://www.aei.mpg.de/~hewitson







___

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