Re: window:willPositionSheet:usingRect: not called in full-screen mode
On Thu, Feb 26, 2015 at 2:45 PM, Uli Kusterer wrote: > On 25 Feb 2015, at 15:47, Arjan van Leeuwen wrote: > >> This method is useful in many situations. If your window has a toolbar, > for > >> example, you can specify a location for the sheet that is just below > it. If > >> you want the sheet associated with a certain control or view, you could > >> position the sheet so that it appears to originate from the object > (through > >> animation) or is positioned next to it. > > > > Great, because that's exactly what I'm using it for :). However, when my > > app is in full-screen mode, this function never gets called. Other > related > > delegate functions, like windowWillBeginSheet: and windowDidEndSheet: do > > get called correctly on the delegate, so the delegate is obviously still > > there and as far as I can see should be receiving a call to > > window:willPositionSheet:usingRect:. > > I wonder whether Apple's UI team know of this documentation. Positioning > a sheet next to any other UI element seems totally wrong for everything > we've seen in Mac UI so far. Especially given 10.7 introduced pop-overs, > which are designed exactly for that purpose and are not modal (or rather, > cancel their mode when you click outside them, at least by default). > > Are you sure it is a good idea to use a sheet for something like that? It > sounds more like a job for a popover, which also handles much more of the > required behaviour automatically. > I'm pretty sure a popover is not the way here, although a windowed dialog could be possible :). This is a browser, and we're talking about the dialog for saving a web page. That dialog is supposed to be either a sheet or a windowed dialog, and since it's attached in this case to a specific tab of the browser, we think it should be a sheet. And since it's related to a specific tab, we expect it the sheet to appear attached to that tab (or 'originating from it' to use the language of the documentation), not outside of it. It seems that only Safari has figured out the secret to making the sheet appear in the right place in full-screen mode as well as in windowed mode, in other applications I see behavior similar to what happens in our application (the sheet is well-positioned in windowed mode but hangs around at its standard location in full-screen mode). > > > Does anyone know what I can do to make the framework call > > window:willPositionSheet:usingRect:, even in full-screen mode? Or if not, > > what other way should I use to position the sheet that will work in all > > situations? > > Fullscreen has a lot of assumptions about your window. We have a custom > window title bar, yet when we're in fullscreen, the OS draws a fake > "standard" title bar and toolbar for us floating above the window when you > show the menu bar. Given you can't even inhibit that, I'm not surprised > that they would also show sheets in the standard location relative to these > fake window decorations. > Yes, I'm aware of that, and it makes some sense. Still would be nice to know if I could customize it somehow though. Thanks for your replies, Arjan ___ 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: Exception on launch when clicking on an NSUserNotification
On Thu, Feb 26, 2015, at 08:49 PM, Alex Kac wrote: > It would be a fantastic clue! Except … its not printed in the console, or > in the xcode console, or anywhere. So I have no idea. My guess is that > the OS is swallowing the exception for launch purposes, which does me no > good. You're trapped at objc_exception_throw. You can select frame 0 and print the first argument (`po $rdi` on x86-64). --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: window:willPositionSheet:usingRect: not called in full-screen mode
> On Feb 25, 2015, at 9:40 AM, Lee Ann Rucker wrote: > >> Great, because that's exactly what I'm using it for > > The toolbar case or the "certain control" one? When you're in fullscreen > mode, the toolbar isn't actually attached to your window. It's attached to a > separate one so it can slide down with the menubar. But if it’s the control, > it wouldn't surprise me if Apple forgot they'd mentioned that option and > didn't think about it when they decided whether this delegate method needed > to be called. This was thought about. The delegate isn’t called because, as you all noted, the sheet is appearing in another window that the application doesn’t own. AppKit takes care of drawing the titlebar, toolbar, and titlebar accessory views (new to 10.10). Sheets are designed to drop below all these, and move with the window when the menu bar drops down. Arjan: > Does anyone know what I can do to make the framework call > window:willPositionSheet:usingRect:, even in full-screen mode? Yes, I know, and the answer is no, you can’t in full screen mode get that delegate call. > Or if not, > what other way should I use to position the sheet that will work in all > situations? You shouldn’t have to… can you describe exactly what you are trying to do and log a bug requesting we start calling the delegate? Pictures would be extremely helpful in a case like this. corbin > > > From: cocoa-dev-bounces+lrucker=vmware@lists.apple.com > [cocoa-dev-bounces+lrucker=vmware@lists.apple.com] on behalf of Arjan van > Leeuwen [arj...@opera.com] > Sent: Wednesday, February 25, 2015 6:47 AM > To: cocoa-dev@lists.apple.com > Subject: window:willPositionSheet:usingRect: not called in full-screen mode > > Hi, > > To open a save file sheet, I'm starting an NSSavePanel as a sheet > via beginSheetModalForWindow:completionHandler:. Because my application > needs custom positioning for the sheet, the window delegate of my main > window overrides window:willPositionSheet:usingRect:. According to the > documentation, this > > Tells the delegate that the window is about to show a sheet at the >> specified location, giving it the opportunity to return a custom location >> for the attachment of the sheet to the window. > > > And > > This method is useful in many situations. If your window has a toolbar, for >> example, you can specify a location for the sheet that is just below it. If >> you want the sheet associated with a certain control or view, you could >> position the sheet so that it appears to originate from the object (through >> animation) or is positioned next to it. > > > Great, because that's exactly what I'm using it for :). However, when my > app is in full-screen mode, this function never gets called. Other related > delegate functions, like windowWillBeginSheet: and windowDidEndSheet: do > get called correctly on the delegate, so the delegate is obviously still > there and as far as I can see should be receiving a call to > window:willPositionSheet:usingRect:. > > Does anyone know what I can do to make the framework call > window:willPositionSheet:usingRect:, even in full-screen mode? Or if not, > what other way should I use to position the sheet that will work in all > situations? > > Thanks, > > Arjan > ___ > > 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/lrucker%40vmware.com > > This email sent to lruc...@vmware.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/corbind%40apple.com > > This email sent to corb...@apple.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: window:willPositionSheet:usingRect: not called in full-screen mode
> On Feb 27, 2015, at 12:14 AM, Arjan van Leeuwen wrote: > > On Thu, Feb 26, 2015 at 2:45 PM, Uli Kusterer > wrote: > >> On 25 Feb 2015, at 15:47, Arjan van Leeuwen wrote: This method is useful in many situations. If your window has a toolbar, >> for example, you can specify a location for the sheet that is just below >> it. If you want the sheet associated with a certain control or view, you could position the sheet so that it appears to originate from the object >> (through animation) or is positioned next to it. >>> >>> Great, because that's exactly what I'm using it for :). However, when my >>> app is in full-screen mode, this function never gets called. Other >> related >>> delegate functions, like windowWillBeginSheet: and windowDidEndSheet: do >>> get called correctly on the delegate, so the delegate is obviously still >>> there and as far as I can see should be receiving a call to >>> window:willPositionSheet:usingRect:. >> >> I wonder whether Apple's UI team know of this documentation. Positioning >> a sheet next to any other UI element seems totally wrong for everything >> we've seen in Mac UI so far. Especially given 10.7 introduced pop-overs, >> which are designed exactly for that purpose and are not modal (or rather, >> cancel their mode when you click outside them, at least by default). >> >> Are you sure it is a good idea to use a sheet for something like that? It >> sounds more like a job for a popover, which also handles much more of the >> required behaviour automatically. >> > > I'm pretty sure a popover is not the way here, although a windowed dialog > could be possible :). This is a browser, and we're talking about the dialog > for saving a web page. That dialog is supposed to be either a sheet or a > windowed dialog, and since it's attached in this case to a specific tab of > the browser, we think it should be a sheet. And since it's related to a > specific tab, we expect it the sheet to appear attached to that tab (or > 'originating from it' to use the language of the documentation), not > outside of it. > > It seems that only Safari has figured out the secret to making the sheet > appear in the right place in full-screen mode as well as in windowed mode, > in other applications I see behavior similar to what happens in our > application (the sheet is well-positioned in windowed mode but hangs around > at its standard location in full-screen mode). Safari uses the standard API. In particular, titlebarAccessoryViewControllers. These almost entirely alleviate the need for custom sheet positioning. The case where they don’t work is for a borderless window where you are drawing your own titlebar controls. Also, please be running the latest OS 10 SU, as some things have been fixed in this area of sheet positioning, mainly with people who use a custom contentBorderThicknessForEdge. corbin > > >> >>> Does anyone know what I can do to make the framework call >>> window:willPositionSheet:usingRect:, even in full-screen mode? Or if not, >>> what other way should I use to position the sheet that will work in all >>> situations? >> >> Fullscreen has a lot of assumptions about your window. We have a custom >> window title bar, yet when we're in fullscreen, the OS draws a fake >> "standard" title bar and toolbar for us floating above the window when you >> show the menu bar. Given you can't even inhibit that, I'm not surprised >> that they would also show sheets in the standard location relative to these >> fake window decorations. >> > > Yes, I'm aware of that, and it makes some sense. Still would be nice to > know if I could customize it somehow though. > > Thanks for your replies, > > Arjan > ___ > > 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/corbind%40apple.com > > This email sent to corb...@apple.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: window:willPositionSheet:usingRect: not called in full-screen mode
> > Fullscreen has a lot of assumptions about your window. We have a custom > window title bar, yet when we're in fullscreen, the OS draws a fake > "standard" title bar and toolbar for us floating above the window when you > show the menu bar. Given you can’t even inhibit that, I'm not surprised that > they would also show sheets in the standard location relative to these fake > window decorations. Please log bugs if you want to inhibit this, and please describe exactly why and what you are trying to do. corbin > > Sorry I'm not of more help, > -- Uli > ___ > > 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/corbind%40apple.com > > This email sent to corb...@apple.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: Exception on launch when clicking on an NSUserNotification
As I have written several times now - I have no user data. If the limit is 1k and it hits that with less than 100 characters for a title and informative string and an ID - then that’s a real bug. I really don’t think I’m hitting that. It would make NSUserNotifications pretty useless for everyone. > On Feb 26, 2015, at 11:04 PM, Graham Cox wrote: > > >> On 27 Feb 2015, at 4:27 pm, Alex Kac wrote: >> >> What’s not shown above is the identifier - which is a 64 character string, >> and the sound name which is a 10 character string. I’m pretty sure that’s >> not more than 1k > > > Right, but it's the resulting archive that has to come in under 1K (a > ridiculously small limit!). Archives include all sorts of stuff on top of the > actual string content - complete class names for all classes involved, all > the keys and a fairly complex structure. You might want to just archive your > user data with keyed archiver and check the resulting length of the NSData. > > --Graham > > Alex Kac - President and Founder Web Information Solutions, Inc. "If at first you don't succeed, skydiving is not for you." -- Francis Roberts ___ 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: Exception on launch when clicking on an NSUserNotification
*** -[NSKeyedUnarchiver decodeObjectForKey:]: data to unarchive contains class (NSArray) which has not been allowed However - the only array I’m setting is the additionalActions - a Yosemite property (this is on Yosemite of course). // An array of NSUserNotificationAction objects that describe the different actions that can be taken on a notification in addition to the default action described by actionButtonTitle @property (copy) NSArray *additionalActions NS_AVAILABLE(10_10, NA); And yup that is it. If I comment out the additionalActions, it works. I guess time to file a bug… # 19986044 > On Feb 27, 2015, at 9:35 AM, Kyle Sluder wrote: > > On Thu, Feb 26, 2015, at 08:49 PM, Alex Kac wrote: >> It would be a fantastic clue! Except … its not printed in the console, or >> in the xcode console, or anywhere. So I have no idea. My guess is that >> the OS is swallowing the exception for launch purposes, which does me no >> good. > > You're trapped at objc_exception_throw. You can select frame 0 and print > the first argument (`po $rdi` on x86-64). > > --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/alex%40webis.net > > This email sent to a...@webis.net Alex Kac - President and Founder Web Information Solutions, Inc. "It is useless for sheep to pass a resolution in favor of vegetarianism while wolves remain of a different opinion." -- William Randolph Inge ___ 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
titlebar accessory? window:willPositionSheet:usingRect: not called in full-screen mode
On Feb 27, 2015, at 9:24 AM, Corbin Dunn wrote: > >> On Feb 25, 2015, at 9:40 AM, Lee Ann Rucker wrote: >> >>> Great, because that's exactly what I'm using it for >> >> The toolbar case or the "certain control" one? When you're in fullscreen >> mode, the toolbar isn't actually attached to your window. It's attached to a >> separate one so it can slide down with the menubar. But if it’s the control, >> it wouldn't surprise me if Apple forgot they'd mentioned that option and >> didn't think about it when they decided whether this delegate method needed >> to be called. > > This was thought about. The delegate isn’t called because, as you all noted, > the sheet is appearing in another window that the application doesn’t own. > AppKit takes care of drawing the titlebar, toolbar, and titlebar accessory > views (new to 10.10). Sheets are designed to drop below all these, and move > with the window when the menu bar drops down. titlebar accessory? oooh. ... some hours later: Is there any way to configure its autolayout so it doesn't overlap the title text, and especially the buttons? ___ 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
CGFloat and NS_BUILD_32_LIKE_64
I thought setting NS_BUILD_32_LIKE_64 = 1 would make CGFloat be double, but CGFloat seems to be conditionalized on __LP64__ (at least, on iOS. I'm building iOS for both 32 and 64 bit devices. What should I do here? I'm trying to get rid of a bunch of implicit conversion warnings. Thanks. -- Rick Mann rm...@latencyzero.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
Converting from scalar to NSNumber*
I'm updating some older Core Data code in which I made liberal use of transient properties to map NSNumber* types to scalar types like uint32_t. In practice, this doesn't gain much, especially with boxing syntax, and it makes the Core Data classes messier (shadow attributes, etc.). The problem is, if I change an attribute's type to NSNumber*, and fail to modify every reference to that attribute, I often end up comparing pointers, not values: @property (strong) NSNumber*someAttribute; if (obj.someAttribute > 42) which needs to become: if (obj.someAttribute.integerValue > 42) I'd love an explicit warning for misuse of NSNumber*, but a pointer-integer comparison warning would be helpful. However, I don't see that among the available warnings in Xcode. Any suggestions on how to better deal with this? Thanks! -- Rick Mann rm...@latencyzero.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: CGFloat and NS_BUILD_32_LIKE_64
Because once upon a time I ran into an issue around the size of CGFloat and someone told me to use NS_BUILD_32_LIKE_64, and that took care of it. Ever since then, I believed NS_BUILD_32_LIKE_64 controlled the size of CGFloat. > On Feb 27, 2015, at 16:32 , Roland King wrote: > > >> On 28 Feb 2015, at 08:14, Rick Mann wrote: >> >> I thought setting NS_BUILD_32_LIKE_64 = 1 would make CGFloat be double, but >> CGFloat seems to be conditionalized on __LP64__ (at least, on iOS. > > Why did you think that? The docs say > > The NS_BUILD_32_LIKE_64 preprocessor macro works in a different manner. It > declares NSInteger to be long (instead of int) and NSUInteger to be long > unsigned int even on 32-bit portions of the source base. > > and that’s all they say. Nothing about CGFloat > >> >> I'm building iOS for both 32 and 64 bit devices. What should I do here? I'm >> trying to get rid of a bunch of implicit conversion warnings. Thanks. > > use explicit casts. > -- Rick Mann rm...@latencyzero.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: CGFloat and NS_BUILD_32_LIKE_64
> On 28 Feb 2015, at 08:14, Rick Mann wrote: > > I thought setting NS_BUILD_32_LIKE_64 = 1 would make CGFloat be double, but > CGFloat seems to be conditionalized on __LP64__ (at least, on iOS. Why did you think that? The docs say The NS_BUILD_32_LIKE_64 preprocessor macro works in a different manner. It declares NSInteger to be long (instead of int) and NSUInteger to be long unsigned int even on 32-bit portions of the source base. and that’s all they say. Nothing about CGFloat > > I'm building iOS for both 32 and 64 bit devices. What should I do here? I'm > trying to get rid of a bunch of implicit conversion warnings. Thanks. use explicit casts. ___ 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: CGFloat and NS_BUILD_32_LIKE_64
> On Feb 27, 2015, at 4:14 PM, Rick Mann wrote: > > I thought setting NS_BUILD_32_LIKE_64 = 1 would make CGFloat be double, but > CGFloat seems to be conditionalized on __LP64__ (at least, on iOS. > > I'm building iOS for both 32 and 64 bit devices. What should I do here? I'm > trying to get rid of a bunch of implicit conversion warnings. Thanks. NS_BUILD_32_LIKE_64 can't do that. `float` and `double` have different sizes on all architectures. If NS_BUILD_32_LIKE_64 redefined CGFloat then it would break things like struct CGRect. NS_BUILD_32_LIKE_64 does only one thing: it changes NSInteger from `long` to `int` and NSUInteger from `unsigned long` to `unsigned int`. That has no effect on storage size on 32-bit; it only changes things like C++ overloading and Objective-C @encode strings that most code won't notice. https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Cocoa64BitGuide/64BitChangesCocoa/64BitChangesCocoa.html#//apple_ref/doc/uid/TP40004247-CH4-SW2 -- 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: Converting from scalar to NSNumber*
> On Feb 27, 2015, at 4:28 PM, Rick Mann wrote:
>
> I'm updating some older Core Data code in which I made liberal use of
> transient properties to map NSNumber* types to scalar types like uint32_t. In
> practice, this doesn't gain much, especially with boxing syntax, and it makes
> the Core Data classes messier (shadow attributes, etc.).
>
> The problem is, if I change an attribute's type to NSNumber*, and fail to
> modify every reference to that attribute, I often end up comparing pointers,
> not values:
>
>@property (strong) NSNumber* someAttribute;
>
>if (obj.someAttribute > 42)
>
> which needs to become:
>
>if (obj.someAttribute.integerValue > 42)
>
> I'd love an explicit warning for misuse of NSNumber*, but a pointer-integer
> comparison warning would be helpful. However, I don't see that among the
> available warnings in Xcode.
Here's how to answer "is there a warning for X".
1. Write a test file with the line of code that you want to be warned about.
2. Compile that file with -Weverything which enables literally every warning
supported by the compiler.
3. If the compiler warns about the code then the diagnostic message will print
the name of the warning flag, if any. Example:
test.m:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
If it doesn't print a warning name then that warning is on all the time, I
think.
When I run a test of your code, I get a warning unconditionally. It's possible
that my compiler is newer than yours; in your compiler there might be no
warning, or there might be a warning behind some warning flag. Try it yourself.
test.m:12:13: warning: ordered comparison between pointer and integer
('NSNumber *' and 'int')
if (t.x > 42) printf("bigger");
~~~ ^ ~~
--
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: Converting from scalar to NSNumber*
> On Feb 27, 2015, at 16:45 , Greg Parker wrote:
>
>
>> On Feb 27, 2015, at 4:28 PM, Rick Mann wrote:
>>
>> I'm updating some older Core Data code in which I made liberal use of
>> transient properties to map NSNumber* types to scalar types like uint32_t.
>> In practice, this doesn't gain much, especially with boxing syntax, and it
>> makes the Core Data classes messier (shadow attributes, etc.).
>>
>> The problem is, if I change an attribute's type to NSNumber*, and fail to
>> modify every reference to that attribute, I often end up comparing pointers,
>> not values:
>>
>> @property (strong) NSNumber* someAttribute;
>>
>> if (obj.someAttribute > 42)
>>
>> which needs to become:
>>
>> if (obj.someAttribute.integerValue > 42)
>>
>> I'd love an explicit warning for misuse of NSNumber*, but a pointer-integer
>> comparison warning would be helpful. However, I don't see that among the
>> available warnings in Xcode.
>
> Here's how to answer "is there a warning for X".
> 1. Write a test file with the line of code that you want to be warned about.
> 2. Compile that file with -Weverything which enables literally every warning
> supported by the compiler.
> 3. If the compiler warns about the code then the diagnostic message will
> print the name of the warning flag, if any. Example:
>test.m:13:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> If it doesn't print a warning name then that warning is on all the time, I
> think.
>
> When I run a test of your code, I get a warning unconditionally. It's
> possible that my compiler is newer than yours; in your compiler there might
> be no warning, or there might be a warning behind some warning flag. Try it
> yourself.
>
> test.m:12:13: warning: ordered comparison between pointer and integer
> ('NSNumber *' and 'int')
>if (t.x > 42) printf("bigger");
>~~~ ^ ~~
Great suggestion. Some versions of GCC will also tell you the command-line
option that controls the warning it's emitting. I wish clang did that.
--
Rick Mann
rm...@latencyzero.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: Converting from scalar to NSNumber*
> On Feb 27, 2015, at 4:46 PM, Rick Mann wrote:
>
>
>> On Feb 27, 2015, at 16:45 , Greg Parker wrote:
>>
>>
>>> On Feb 27, 2015, at 4:28 PM, Rick Mann wrote:
>>>
>>> I'm updating some older Core Data code in which I made liberal use of
>>> transient properties to map NSNumber* types to scalar types like uint32_t.
>>> In practice, this doesn't gain much, especially with boxing syntax, and it
>>> makes the Core Data classes messier (shadow attributes, etc.).
>>>
>>> The problem is, if I change an attribute's type to NSNumber*, and fail to
>>> modify every reference to that attribute, I often end up comparing
>>> pointers, not values:
>>>
>>> @property (strong) NSNumber* someAttribute;
>>>
>>> if (obj.someAttribute > 42)
>>>
>>> which needs to become:
>>>
>>> if (obj.someAttribute.integerValue > 42)
>>>
>>> I'd love an explicit warning for misuse of NSNumber*, but a pointer-integer
>>> comparison warning would be helpful. However, I don't see that among the
>>> available warnings in Xcode.
>>
>> Here's how to answer "is there a warning for X".
>> 1. Write a test file with the line of code that you want to be warned about.
>> 2. Compile that file with -Weverything which enables literally every warning
>> supported by the compiler.
>> 3. If the compiler warns about the code then the diagnostic message will
>> print the name of the warning flag, if any. Example:
>> test.m:13:1: warning: control reaches end of non-void function
>> [-Wreturn-type]
>> If it doesn't print a warning name then that warning is on all the time, I
>> think.
>>
>> When I run a test of your code, I get a warning unconditionally. It's
>> possible that my compiler is newer than yours; in your compiler there might
>> be no warning, or there might be a warning behind some warning flag. Try it
>> yourself.
>>
>> test.m:12:13: warning: ordered comparison between pointer and integer
>> ('NSNumber *' and 'int')
>> if (t.x > 42) printf("bigger");
>> ~~~ ^ ~~
>
> Great suggestion. Some versions of GCC will also tell you the command-line
> option that controls the warning it's emitting. I wish clang did that.
Er, that's exactly what Clang does, when there is a command-line option.
Example:
test.m:13:1: warning: control reaches end of non-void function [-Wreturn-type]
Some of clang's warnings have no command-line option. Ordered comparison
between pointer and integer appears to be one of them, at least in my version
of the compiler.
--
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: Converting from scalar to NSNumber*
Ah yes. Same with mine.
Sent from my iPhone
> On Feb 27, 2015, at 16:53, Greg Parker wrote:
>
>
>> On Feb 27, 2015, at 4:46 PM, Rick Mann wrote:
>>
>>
>>> On Feb 27, 2015, at 16:45 , Greg Parker wrote:
>>>
>>>
On Feb 27, 2015, at 4:28 PM, Rick Mann wrote:
I'm updating some older Core Data code in which I made liberal use of
transient properties to map NSNumber* types to scalar types like uint32_t.
In practice, this doesn't gain much, especially with boxing syntax, and it
makes the Core Data classes messier (shadow attributes, etc.).
The problem is, if I change an attribute's type to NSNumber*, and fail to
modify every reference to that attribute, I often end up comparing
pointers, not values:
@property (strong) NSNumber*someAttribute;
if (obj.someAttribute > 42)
which needs to become:
if (obj.someAttribute.integerValue > 42)
I'd love an explicit warning for misuse of NSNumber*, but a
pointer-integer comparison warning would be helpful. However, I don't see
that among the available warnings in Xcode.
>>>
>>> Here's how to answer "is there a warning for X".
>>> 1. Write a test file with the line of code that you want to be warned about.
>>> 2. Compile that file with -Weverything which enables literally every
>>> warning supported by the compiler.
>>> 3. If the compiler warns about the code then the diagnostic message will
>>> print the name of the warning flag, if any. Example:
>>> test.m:13:1: warning: control reaches end of non-void function
>>> [-Wreturn-type]
>>> If it doesn't print a warning name then that warning is on all the time, I
>>> think.
>>>
>>> When I run a test of your code, I get a warning unconditionally. It's
>>> possible that my compiler is newer than yours; in your compiler there might
>>> be no warning, or there might be a warning behind some warning flag. Try it
>>> yourself.
>>>
>>> test.m:12:13: warning: ordered comparison between pointer and integer
>>>('NSNumber *' and 'int')
>>> if (t.x > 42) printf("bigger");
>>> ~~~ ^ ~~
>>
>> Great suggestion. Some versions of GCC will also tell you the command-line
>> option that controls the warning it's emitting. I wish clang did that.
>
> Er, that's exactly what Clang does, when there is a command-line option.
> Example:
> test.m:13:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>
> Some of clang's warnings have no command-line option. Ordered comparison
> between pointer and integer appears to be one of them, at least in my version
> of the compiler.
>
>
> --
> 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: Converting from scalar to NSNumber*
On Feb 27, 2015, at 6:28 PM, Rick Mann wrote: > > I'm updating some older Core Data code in which I made liberal use of > transient properties to map NSNumber* types to scalar types like uint32_t. In > practice, this doesn't gain much, especially with boxing syntax, and it makes > the Core Data classes messier (shadow attributes, etc.). > > The problem is, if I change an attribute's type to NSNumber*, and fail to > modify every reference to that attribute, I often end up comparing pointers, > not values: > >@property (strong) NSNumber* someAttribute; > >if (obj.someAttribute > 42) > > which needs to become: > >if (obj.someAttribute.integerValue > 42) > > I'd love an explicit warning for misuse of NSNumber*, but a pointer-integer > comparison warning would be helpful. However, I don't see that among the > available warnings in Xcode. > > Any suggestions on how to better deal with this? Thanks! A quick-and-dirty way to do this is to simply change the name of the property. This will cause every reference to that attribute to throw an error. Then you go fix all the errors, adding .integerValue in the process. After you’re done, you can use the refactoring tools to change the property name back. 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: Converting from scalar to NSNumber*
> On Feb 27, 2015, at 18:32 , Charles Srstka wrote: > > A quick-and-dirty way to do this is to simply change the name of the > property. This will cause every reference to that attribute to throw an > error. Then you go fix all the errors, adding .integerValue in the process. > After you’re done, you can use the refactoring tools to change the property > name back. Also a good suggestion. -- Rick Mann rm...@latencyzero.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: Converting from scalar to NSNumber*
On Fri, 27 Feb 2015 16:28:58 -0800, Rick Mann said: >I'm updating some older Core Data code in which I made liberal use of >transient properties to map NSNumber* types to scalar types like >uint32_t. In practice, this doesn't gain much, especially with boxing >syntax, and it makes the Core Data classes messier (shadow attributes, etc.). > >The problem is, if I change an attribute's type to NSNumber*, and fail >to modify every reference to that attribute, I often end up comparing >pointers, not values: > >@property (strong) NSNumber* someAttribute; > >if (obj.someAttribute > 42) Also watch out for booleans, where: if (obj.someAttribute) won't get any warning, whether it's BOOL or id. Also if you use mogenerator, it will automatically create methods for you named setSomeAttributeValue: and someAttributeValue, which take scalars. 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
Error migrating: "Unacceptable type of value for attribute"
Up until now I've been carefully migrating a few attributes at a time to my new schema. Part of this involved renaming some properties. I use a Mapping Model and automatic migration, and this has worked fine. Because Xcode forces me to start from scratch with the Mapping Model file each time I make a change to the schema, after I was confident I was going to be able to do the migration, I did all the remaining couple dozen attributes, updated the data model, created a new Mapping Model, and set all the value expressions. Now, when creating the persistent store coordinator and migrating from v2 to v3, I get this error: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Unacceptable type of value for attribute: property = "endDate"; desired type = NSDate; given type = __NSCFNumber; value = 0.' Thing is, endDate did not change. It has always been an NSDate. The underlying sql shows it as TIMESTAMP. The mapping model is: endDate $source.endDate The values for ZENDDATE are reasonable or null, as expected. "endDate" is an optional Date attribute. Any ideas? Thanks! -- Rick Mann rm...@latencyzero.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
-controllerWill/DidChangeContent: called for every change
According to the docs, it's supposed to be called once at the start, and again at the end. But it's being called for every single change. In these calls, I call beginUpdates and endUpdates on my table view. Partway through, my table view complains about mismatched inserts/deletes, etc. The action that initiates this is a bulk change to a bunch of the entities in the NSFetchedResultsController's set. The FRC has a predicate "removed == false". The bulk update changes "removed" to true. I get a deleted change type (not updated) for each object, bracketed by will/did change calls. All of this happens in the -[MOC save:] call after the updates. Am I missing something? -- Rick Mann rm...@latencyzero.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: -controllerWill/DidChangeContent: called for every change
Ah, nevermind. That's what happens when you save in your batch update loop. > On Feb 27, 2015, at 23:23 , Rick Mann wrote: > > According to the docs, it's supposed to be called once at the start, and > again at the end. But it's being called for every single change. In these > calls, I call beginUpdates and endUpdates on my table view. Partway through, > my table view complains about mismatched inserts/deletes, etc. > > The action that initiates this is a bulk change to a bunch of the entities in > the NSFetchedResultsController's set. The FRC has a predicate "removed == > false". The bulk update changes "removed" to true. I get a deleted change > type (not updated) for each object, bracketed by will/did change calls. > > All of this happens in the -[MOC save:] call after the updates. > > Am I missing something? > > -- > Rick Mann > rm...@latencyzero.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/rmann%40latencyzero.com > > This email sent to rm...@latencyzero.com -- Rick Mann rm...@latencyzero.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
