On 19/04/2013, at 4:35 PM, Greg Parker wrote:
> Another solution is to introduce a weak reference between the timer and your
> controller. Create a helper class that holds a weak reference to your
> Controller object.
Since Greg and I have offered the same solution, here's an implementation
On Apr 18, 2013, at 11:01 PM, Oleg Krupnov wrote:
> I recently encountered an alarming problem that I have never been
> aware of, and I'd like to ask about the best practice to handle it.
>
> Is it true that any object (let's call it Controller) that owns an
> NSTimer, scheduled to fire a method
On 19/04/2013, at 4:01 PM, Oleg Krupnov wrote:
> recently encountered an alarming problem that I have never been
> aware of, and I'd like to ask about the best practice to handle it.
>
> Is it true that any object (let's call it Controller) that owns an
> NSTimer, scheduled to fire a method (l
I recently encountered an alarming problem that I have never been
aware of, and I'd like to ask about the best practice to handle it.
Is it true that any object (let's call it Controller) that owns an
NSTimer, scheduled to fire a method (let's call it -timerDidFire) of
the same Controller, creates
Thanks :)
The crux of it is that you can bind global hotkeys to your own JavaScript
(or CoffeeScript) functions, and from your JS (or CS) config file, you have
access to an API[1] that lets you control and inspect all open windows and
apps.
On the wiki I have some examples of how you can use this
Fantastic! What does it do?
--Graham
On 18/04/2013, at 2:44 AM, Steven Degutis wrote:
> Called Windows.app. Source is on github:
> https://github.com/sdegutis/windowsapp
>
> What's particularly neat about it is how you configure it. It looks for a
> dotfile in your home dir, which can either
I have an application with a single window and that window's -restorable
property is NO (in the xib). If I force quit that application or otherwise
cause it to crash, when it is launched again the app asks me if I want to
restore its windows.
Is there any way to turn off that notice? In this a
Le 18 avr. 2013 à 18:31, Jens Alfke a écrit :
>
> On Apr 18, 2013, at 12:14 AM, Rick Mann wrote:
>
>> I had an NSAssert with varargs in a C routing in a .mm file. It compiled
>> fine in a Mac OS X app, but the same code in an iOS app bitches about too
>> many arguments. Is that right?
>
>
Well, it still builds correctly in the OS X project (it's common utility code I
use across projects). The line is:
enum AnchorRegion inRgn = ...;
NSCAssert(false, @"Unknown AnchorRegion %d", inRgn);
On Apr 18, 2013, at 09:31 , Jens Alfke wrote:
>
> On Apr 18, 2013, at 1
This message may be relevant for your issue:
http://prod.lists.apple.com/archives/cocoa-dev/2013/Feb/msg00426.html
Personally, I don't use auto layout in NSScrollView. I think that
NSScrollView doesn't support it, but it appears that many people have
gotten it to work.
Chuck
P.S. It looks like yo
On Apr 18, 2013, at 12:14 AM, Rick Mann wrote:
> I had an NSAssert with varargs in a C routing in a .mm file. It compiled fine
> in a Mac OS X app, but the same code in an iOS app bitches about too many
> arguments. Is that right?
Double-check that the warning isn't in fact correct. Clang has
True, but I'm confident they don't care. :)
On Thu, Apr 18, 2013 at 1:00 AM, Charles Srstka wrote:
> On Apr 17, 2013, at 11:44 AM, Steven Degutis wrote:
>
> Called Windows.app.
>
>
> ... I think someone may have used the name "Windows" already...
>
> Charles
>
__
I had an NSAssert with varargs in a C routing in a .mm file. It compiled fine
in a Mac OS X app, but the same code in an iOS app bitches about too many
arguments. Is that right? The iOS project where it's failing hasn't been built
in a few months, so I wonder if there might be some leftover cruf
13 matches
Mail list logo
