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
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
> 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 sl
> 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 locat
>
> 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 surprise
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 everyo
*** -[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
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 y
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.
--
Ri
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
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 2
> 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 differen
> 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
> 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
> 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 m
> 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 sc
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 s
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 Dat
> 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 d
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 cl
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
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 acti
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 be
23 matches
Mail list logo
