On 14.04.2013, at 20:20, Pax <45rpmli...@googlemail.com> wrote:
> [[NSApplication sharedApplication] activateIgnoringOtherApps : YES];
>
> Thanks for the suggestion. If it breaks something else I'll be sure you let
> you know.
Cool, it'd be appreciated!
Cheers,
-- Uli Kusterer
http://stacksmi
On 15 Apr 2013, at 00:25, Graham Cox wrote:
>
> On 14/04/2013, at 2:08 PM, YT wrote:
>
>> My struggle is partially due to my lack of experience in OOP. I just have
>> not written enough OO code as of yet. AND I'm very new to Objective-C.
>> Hence my lack of experience and working knowledge
On Apr 15, 2013, at 12:01 AM, Glenn L. Austin wrote:
> You can't have the full 320 pixels in width and still have the disclosure
> indicator. Well, you can, but you won't be happy with the result (and likely
> won't get it past Apple's reviewers).
I see, thanks.
It doesn't have to be 320, 3
On Apr 15, 2013, at 1:27 AM, Luke Hiesterman wrote:
> In general, if you want to put custom stuff in a cell, you should do it by
> adding views - like labels, image views, etc. Only if you find a scrolling
> performance problem and only if via profiling analysis you can show that the
> perfor
On Apr 14, 2013, at 6:25 PM, Jerry Krinock wrote:
> Has anyone ever seen any behavior like this? (More data follows below.)
Yes. I haven't checked to see if this was addressed in later cats, but I did
notice that CoreData is a memory hog in Snow Leopard. Specifically, it
allocates up to twic
On 2013 Apr 15, at 10:54, Nick Zitzmann wrote:
> Yes. I haven't checked to see if this was addressed in later cats, but I did
> notice that CoreData is a memory hog in Snow Leopard. Specifically, it
> allocates up to twice the size of the managed object when updating or
> deleting (!) the obj
On Apr 12, 2013, at 16:16:53, Quincey Morris
wrote:
> You can just override "autosavesInPlace" to return NO, to turn off the new
> behavior.
>
> It's also possible that just overriding "autosavesDrafts" to return NO might
> disable the untitled document behavior, if that's all you need, but
On Apr 15, 2013, at 4:49 PM, Steve Mills wrote:
> I don't see an autosavesDrafts method anywhere. Ah, I just found it in
> NSDocument. Strange that searching for that term in the help window didn't
> find it.
It might be that your Xcode doc window is searching the 10.7 docset. The
autosavesDra
Hi Steve,
On Apr 12, 2013, at 1:10 PM, Steve Mills wrote:
> If I have an unsaved doc open in my app (I mean one that has never been saved
> to disk), and I kill the app, upon relaunch, the OS attempts to restore that
> document, but it does so incorrectly. First of all, the data was never save
On Apr 15, 2013, at 16:06:51, Andy Lee
wrote:
> On Apr 15, 2013, at 4:49 PM, Steve Mills wrote:
>> I don't see an autosavesDrafts method anywhere. Ah, I just found it in
>> NSDocument. Strange that searching for that term in the help window didn't
>> find it.
>
> It might be that your Xcode
On Apr 15, 2013, at 13:49 , Steve Mills wrote:
> I have the following overrides in my NSDocument subclass:
> […]
You didn't mention "autosavesInPlace". This is the one to override if you don't
want any (new-style) autosaving.
> The data was never saved anywhere, so opening a new document is t
On Apr 15, 2013, at 2:22 PM, Jerry Krinock wrote:
>> Yes. I haven't checked to see if this was addressed in later cats, but I did
>> notice that CoreData is a memory hog in Snow Leopard. Specifically, it
>> allocates up to twice the size of the managed object when updating or
>> deleting (!)
On Apr 15, 2013, at 3:36 AM, Uli Kusterer wrote:
> On 14.04.2013, at 20:20, Pax <45rpmli...@googlemail.com> wrote:
>> [[NSApplication sharedApplication] activateIgnoringOtherApps : YES];
>>
>> Thanks for the suggestion. If it breaks something else I'll be sure you let
>> you know.
>
> Cool, i
On 2013 Apr 15, at 14:20, Nick Zitzmann wrote:
> Okay, that's pretty bizarre and I haven't seen that happen before. I don't
> suppose your user could use Instruments' object allocation instrument to
> figure out what's going on…?
Oh, I don't need the user. I've reproduced the problem on an o
On 15/04/2013, at 8:44 PM, Tom Davie wrote:
> Wow, I really can't get my head around this one. You make bold statements
> like "GLOBALS ARE BAD NEWS" (which I 100% agree with), but then follow up
> with effectively "use singletons instead". Singletons bring with them 95% of
> the problems g
On 16/04/2013, at 10:18 AM, Graham Cox wrote:
> I don't know what you mean by "dependency injection", it's not a term I've
> heard of
OK, I looked it up. I hadn't heard the term but I'm very familiar with the
concept it refers to. Sometimes the service or dependent entity should be a
singl
On 15.04.2013, at 12:44, Tom Davie wrote:
> Note also – simply using your app delegate as a store for things that aren't
> singletons, but only one of them is pointed at by your app delegate is also
> horrific – you're just substituting one singleton for another.
If it were only that! At least
On 15.04.2013, at 13:20, Koen van der Drift wrote:
> The reason I was using drawRect is that my cell contains some text, plus a
> small graph (a few changing lines, so I cannot use an static image) at the
> bottom. Therefore I was using CoreGraphics, and I decided then to also draw
> the string
18 matches
Mail list logo
