On 12/08/2012, at 4:37 PM, Andy Lee wrote:
>> There's a really annoying bug in the Xcode 4.4 version of IB where it
>> sometimes fails to notice that I added an action method to the "Files Owner"
>> class. Try as I might I cannot make it see the added method.
>
> Clean build? Delete Derived D
On Aug 12, 2012, at 1:33 AM, Graham Cox wrote:
> There's a really annoying bug in the Xcode 4.4 version of IB where it
> sometimes fails to notice that I added an action method to the "Files Owner"
> class. Try as I might I cannot make it see the added method.
Clean build? Delete Derived Data i
If developers should transition to 64-bit (as Greg says they should), then:
* The docs are outdated and misleading.
* This is bad for developers who assume the docs are up-to-date and reliable.
* Right or wrong, some developers will fall into this category.
* It behooves Apple to update the docs,
An argument on the internet is like arguing with an idiot.. Even if you win you
were arguing with an idiot.
~ Erik
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact t
There's a really annoying bug in the Xcode 4.4 version of IB where it sometimes
fails to notice that I added an action method to the "Files Owner" class. Try
as I might I cannot make it see the added method. This used to be easy - just
drag the header into the old IB!
I'm having to quite and r
On Aug 11, 2012, at 7:24 PM, Graham Cox wrote:
>
> On 12/08/2012, at 12:08 PM, Jayson Adams wrote:
>
>> As Greg Parker's comments are tangential to the issue I am raising, my point
>> is proven again.
>
>
> No they aren't.
>
> The fact is, that if the documentation was always up to date, a
On 12/08/2012, at 12:09 PM, koko wrote:
> Is 64-bit the end or will there be 128-bit?
64-bit should be enough for anybody oh, wait.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderato
On 12/08/2012, at 12:08 PM, Jayson Adams wrote:
> As Greg Parker's comments are tangential to the issue I am raising, my point
> is proven again.
No they aren't.
The fact is, that if the documentation was always up to date, always perfect,
and complete then mailing lists and forums would no
Anybody know of any good PubSub framework alternatives? My usage works OK with
PubSub, except I'm running into assertions inside the framework for no fault of
my own, and I can't see a workaround yet.
The only other framework I've really found is Kevin Ballard's FeedParser.
Wondering if there
Is 64-bit the end or will there be 128-bit?
-koko
On Aug 11, 2012, at 7:25 PM, Graham Cox wrote:
>
> On 12/08/2012, at 11:16 AM, Jayson Adams wrote:
>
>> Poor reading skills are keeping this thread alive.
>
>
> Well, indeed. I quote Greg Parker:
>
>> We recommend that you transition you
On Aug 11, 2012, at 6:25 PM, Graham Cox wrote:
>
> On 12/08/2012, at 11:16 AM, Jayson Adams wrote:
>
>> Poor reading skills are keeping this thread alive.
>
>
> Well, indeed. I quote Greg Parker:
As Greg Parker's comments are tangential to the issue I am raising, my point is
proven again.
On Aug 11, 2012, at 6:16 PM, Jayson Adams wrote:
> If Apple is considering dropping 32-bit support they need to change this
> piece of documentation. And no, I am not going to file a bug on it.
Why the hell not?! Apple has a channel for providing feedback; why do you
refuse to use it?
We've
On 12/08/2012, at 11:16 AM, Jayson Adams wrote:
> Poor reading skills are keeping this thread alive.
Well, indeed. I quote Greg Parker:
> We recommend that you transition your app to 64-bit. Many of the caveats in
> the 64-Bit Transition Guide are no longer applicable.
>
>
> --
> Greg Par
I am needing to write an native extension for air and Flash builder that needs
to be 32bit. However when i call ioctl in a 32 bit application it fails with
-1. If i flip the app to 64 bit it works. I need a bit of help understanding
why 32bit ioctl doesn't work.
My questions, maybe someone at
On Aug 11, 2012, at 4:51 PM, Graham Cox wrote:
> On 12/08/2012, at 4:18 AM, Jayson Adams wrote:
>
>> the porting guide currently states, which is that you may not want to move
>> to 64-bit
>
>
> What's so hard about moving to 64-bit anyway? The time you've wasted ranting
> and raving about
On Aug 11, 2012, at 7:56 PM, Graham Cox wrote:
> On 12/08/2012, at 10:46 AM, Charles Srstka wrote:
>
>> Well, that's not necessarily true — if one's codebase is heavily dependent
>> on Carbon or any of the other various technologies that didn't make the
>> 64-bit transition, porting to 64-bit
On 12/08/2012, at 10:46 AM, Charles Srstka wrote:
> Well, that's not necessarily true — if one's codebase is heavily dependent on
> Carbon or any of the other various technologies that didn't make the 64-bit
> transition, porting to 64-bit may be quite involved. However, this even
> further u
On 12/08/2012, at 10:41 AM, Gerriet M. Denkmann wrote:
> What could I do to get rid of this warning?
Nothing. It's being logged by NSWindow, indicating that Apple are using a
deprecated method themselves. I see the same thing when I set my screen to
HiDPI mode. We'll just have to wait for an
On Aug 11, 2012, at 6:51 PM, Graham Cox wrote:
> On 12/08/2012, at 4:18 AM, Jayson Adams wrote:
>
>> the porting guide currently states, which is that you may not want to move
>> to 64-bit
>
>
> What's so hard about moving to 64-bit anyway? The time you've wasted ranting
> and raving about
On 11 Aug 2012, at 20:20, Mike Abdullah wrote:
>
> On 11 Aug 2012, at 13:55, "Gerriet M. Denkmann" wrote:
>
>> I have an app which, when I first use File → Open..., writes:
>> "2012-08-11 19:48:16.710 MyApp[5380:303] *** WARNING: Method
>> userSpaceScaleFactor in class NSWindow is deprecated
On 12/08/2012, at 4:18 AM, Jayson Adams wrote:
> the porting guide currently states, which is that you may not want to move to
> 64-bit
What's so hard about moving to 64-bit anyway? The time you've wasted ranting
and raving about it, you could have had it running by now.
--Graham
On Aug 11, 2012, at 11:50 AM, Alex Kac wrote:
> Apple's system is a mutually beneficial one but it also requires both parties
> to do their part. Apple probably does have a bug on this already, but unless
> you file one as well – and for that matter everyone else that knows about
> this – then
Apple's system is a mutually beneficial one but it also requires both parties
to do their part. Apple probably does have a bug on this already, but unless
you file one as well – and for that matter everyone else that knows about this
– then it may not bubble up. Apple has said many times that th
On Aug 11, 2012, at 12:38 PM, Jayson Adams wrote:
>>> What it doesn't say anything about is the timing of the demise of 32-bit
>>> support.
>>
>> Of course we don't know the exact timing, but it's entirely plausible that
>> it could be removed in 10.9 or 10.10, and if you don't want to get a r
On Aug 11, 2012, at 11:02 AM, Gwynne Raskind wrote:
> On Sat, Aug 11, 2012 at 1:38 PM, Jayson Adams wrote:
>> I say again, Apple's official 64-bit porting document states, right now,
>> that you may or may not want to move to 64 bit. If Apple is planning on
>> removing 32-bit support in the n
File a bug on that doc then. The docs are so big that I'm sure Apple doesn't
keep track of every page that needs updating and some like this one may not be
editable easily without giving up their plans. Since Apple is well known not to
give away their plans, reading tea leaves is what a good App
On Sat, Aug 11, 2012 at 1:38 PM, Jayson Adams wrote:
> I say again, Apple's official 64-bit porting document states, right now, that
> you may or may not want to move to 64 bit. If Apple is planning on removing
> 32-bit support in the near future, they will be partly to blame for any rude
> su
Try "br -[NSWindow userSpaceScaleFactor]" and see who's calling it.
- Original Message -
From: "Gerriet M. Denkmann"
To: cocoa-dev@lists.apple.com
Sent: Saturday, August 11, 2012 5:55:56 AM
Subject: userSpaceScaleFactor in class NSWindow is deprecated - so what?
I have an app which, when
On Aug 10, 2012, at 10:22 PM, Charles Srstka wrote:
>> Tell me what exactly? That 32-bit is going away in 10.9? That doesn't
>> follow. That 32-bit will get dropped eventually? That was already obvious.
>
>
> It tells us that Apple is no longer putting effort into 32-bit, which in turn
> tell
Apparently, MPMoviePlayerController isn't the way to go for this. What I ended
up doing was using MPMoviePlayerViewController and overrode the
remoteControlReceivedWithEvent to customize the controls.
Below is my current code which I am using.
@interface MGMMoviePlayerViewController : MPMovieP
WOW!!! Talk about out of the frying pan and into the fire! Running my app using
the code below to speak phrases hosed my whole system! It wouldn't respond to a
mouse movement or any keyboard input nor would it reboot properly even from a
power down/power up restart. I had to reinstall from a sav
On 2012-08-10, at 7:30 PM, Andy Lee wrote:
> If there's one specific control class that you want to detect focus for, you
> can subclass it and override becomeFirstResponder. If super returns true, do
> your thing.
>
> If you want to apply this to a bunch of varied controls, you might want to
>From the docs:
Returns the scale factor applied to the window. (Deprecated. Use
convertRectToBacking: and backingScaleFactor instead.)
On 2012-08-11, at 5:55 AM, Gerriet M. Denkmann wrote:
> userSpaceScaleFactor
___
Cocoa-dev mailing list (Cocoa
On 11 Aug 2012, at 13:55, "Gerriet M. Denkmann" wrote:
> I have an app which, when I first use File → Open..., writes:
> "2012-08-11 19:48:16.710 MyApp[5380:303] *** WARNING: Method
> userSpaceScaleFactor in class NSWindow is deprecated on 10.7 and later. It
> should not be used in new applica
I have an app which, when I first use File → Open..., writes:
"2012-08-11 19:48:16.710 MyApp[5380:303] *** WARNING: Method
userSpaceScaleFactor in class NSWindow is deprecated on 10.7 and later. It
should not be used in new applications. Use convertRectToBacking: instead."
I asked Xcode about "u
On Aug 11, 2012, at 7:26 AM, Ken Thomases wrote:
> On Aug 11, 2012, at 6:10 AM, Koen van der Drift wrote:
>
>> I'd … like to be able to change all values in the same NSTableColumn based
>> on a check box.
>>
>> Say my entity has two properties valueA and valueB; if the checkbox is
>> checked
On Aug 11, 2012, at 6:10 AM, Koen van der Drift wrote:
> I'd … like to be able to change all values in the same NSTableColumn based on
> a check box.
>
> Say my entity has two properties valueA and valueB; if the checkbox is
> checked, then the column should show valueA, otherwise it should sho
A follow up question.
Now I got the filtering sorted out, I'd also like to be able to change all
values in the same NSTableColumn based on a check box.
Say my entity has two properties valueA and valueB; if the checkbox is checked,
then the column should show valueA, otherwise it should show va
On Aug 10, 2012, at 1:44 PM, Ken Thomases wrote:
> return [NSPredicate predicateWithFormat:@"%f < value && value < %f",
> self.minimumValue, self.maximumValue];
And we have a winner.
Thanks everyone for thinking along, looks like we all learned something ;-)
- Koen.
___
Le 11 août 2012, à 05:05, Eric Wing écrivit:
> There are actually other compelling reasons to move to 64-bit that
> have nothing to do with the amount of addressable memory or max int.
> For example, i386 is register starved which has implications on
> performance. The modern CPU architectures co
40 matches
Mail list logo
