Re: Non-sandboxed Cocoa app accessing current user preferences using NSTask fails when launched outside Xcode.

Why launch sqlite command? Why not link directly to the sqlite library and access the data base directly? Further, preference files in ~/Library/Preferences are typically XML key-value plist files. Why not use [NSUserDefaults standardUserDefaults]? Paul On Jul 23, 2013, at 10:04 AM, Public w

RE: Constraining a mouse cursor to a rect / window

Thanks for your responses, Seth & Ken. Ken: I don't think we can use LGPL code in SDL2, as the license for v2 is MIT. Have you measured to see if using CGAssociateMouseAndMouseCursorPosition and CGWarpMouseCursorPosition incurs any latency on cursor movements? Our customers are very .. sensitiv

Re: Non-sandboxed Cocoa app accessing current user preferences using NSTask fails when launched outside Xcode.

Why launch sqlite command? Why not link directly to the sqlite library and access the data base directly? Further, preference files in ~/Library/Preferences are typically XML key-value plist files. Why not use [NSUserDefaults standardUserDefaults]? Paul On Jul 23, 2013, at 10:04 AM, Public wr

How to make text view treat colon as word boundary

I have a text view that's used for editing code, and I want the user to be able to double-click within "foo:fie" and have only foo or fie selected. I overrode mouseDown: and mouseDragged: and thought I was home free -- but I now realise that's not going to work with completion. Changing the sy

Re: Observing Time

On Jul 26, 2013, at 12:09 PM, Ken Thomases wrote: > On Jul 25, 2013, at 9:26 PM, dangerwillrobinsondan...@gmail.com wrote: > >> Yep, I know of these, but this is tied to the run loop and timers on the >> runloop can be delayed. >> The reason I went with dispatch_timer is because it can be done

Apple Developer update phishing

Sigh… Stay alert folks. I saw reports that scammers are already sending out emails trying to trick devs into logging in to validate their accounts on a fake web site. You don't want to wind up in a race with some scumbag on another continent to see who can notice and log in to your account the

Re: Apple Developer Update

While I agree with you, I think it is also essential to keep a thread open to sort of discharge the overflow of emotional frustration - we're not Vulcans! :) Here's a better forum for that: :-) ___ Cocoa-dev ma

Re: Observing Time

On Jul 25, 2013, at 9:26 PM, dangerwillrobinsondan...@gmail.com wrote: > Yep, I know of these, but this is tied to the run loop and timers on the > runloop can be delayed. > The reason I went with dispatch_timer is because it can be done with its own > thread and if I understand correctly, frees

Re: Observing Time

On Jul 26, 2013, at 11:08 AM, Rick Mann wrote: > > On Jul 25, 2013, at 18:52 , dangerwillrobinsondan...@gmail.com wrote: > >> I'm getting about a half second lag behind the system clock. >> This is actually reasonable for my purposes, but I wonder if I'm missing >> something that might be mo

Re: Observing Time

On Jul 25, 2013, at 18:52 , dangerwillrobinsondan...@gmail.com wrote: > I'm getting about a half second lag behind the system clock. > This is actually reasonable for my purposes, but I wonder if I'm missing > something that might be more in sync. You can do this using NSTimers, but you need

Observing Time

Hi all Is there something obvious I am missing, or is there no Cocoa API for observing the current time? I've found dispatch_timer to be reasonably accurate in doing this, but naturally lagging a little. The interval is pretty reliable, but I wonder if there is a hook to the time as updated on

Re: storage for context: value

On Jul 25, 2013, at 12:08 , Matt Neuburg wrote: > Well, and discussions of the issue often fail to take into account the > problem of distinguishing the context on an instance-by-instance basis. > Passing "self" as a context does that, obviously; but the "static void*" > trick does not (there

Re: NSTask interrupt exception

Scott, Thanks for your detailed message. This lead me to search for -interrupt calls and I found one on another NSTask. I was assuming that this typesetting task was the issue, but maybe it's really this other task. My biggest problem is that I've never managed to reproduce the exception/crash

Re: storage for context: value

Well, and discussions of the issue often fail to take into account the problem of distinguishing the context on an instance-by-instance basis. Passing "self" as a context does that, obviously; but the "static void*" trick does not (there is one storage per class, not per instance of that class).

Re: Leak when "drawing too fast"

Am 25.07.2013 um 19:36 schrieb Uli Kusterer : > Have you considered using a display link callback instead of a timer? Yes. Moving to the display link callback was when I noticed the issue in the first place. Calling -setNeedsDisplay: in the display link callback is too fast. It gives smooth a

Re: NSTextView's MarkedText

Thanks. That actually worked, at least for standard background drawing. I thought I had my custom attribute working, but I was mistaken. More work to do on that. fillBackgroundRectArray:count:forCharacterRange:color: , which I use for my custom selection highlighting, only gets called for selec

Re: Leak when "drawing too fast"

On Jul 25, 2013, at 7:09 PM, Andreas Mayer wrote: > I tried different ways to limit the drawing frequency but ended up with > either timers piling up or jittery animation. Have you considered using a display link callback instead of a timer? That should call you just in time. Or CALayer, which

Re: Leak when "drawing too fast"

A followup: Am 10.07.2013 um 02:10 schrieb Uli Kusterer : > I don’t think the timers leak. Instead, I think they probably just queue up > on the event loop because their fire interval is greater than that at which > you add new timers by calling setNeedsDisplay. Could that be it? You are right

Re: storage for context: value

On Jul 25, 2013, at 07:20 , Matt Neuburg wrote: > storage of the value passed as context:(void*), not just in addObserver:, but > in general I think I'd take this in a different direction. In *all* of these scenarios the context parameter is a mechanism for passing a pointer to a data structur

Re: NSTask interrupt exception

On Jul 25, 2013, at 8:24 AM, Martin Hewitson wrote: > Dear list, > > I have a couple of users reporting exceptions (and crashes) which I think are > associated with my interrupting an NSTask when they close a document. I get > exceptions like this: > > *** -[NSConcreteTask interrupt]: task no

Re: Apple Developer Update

On 25 Jul 2013, at 15:54, Fritz Anderson wrote: > > Those of us who have been on the net for 30+ years have seen valuable, even > beloved, fora die as the essential contributors decide they have better uses > for their energy than sorting through (often unpleasant) noise. I'm not > saying it's

Re: storage for context: value

On Jul 25, 2013, at 8:50 AM, Matt Neuburg wrote: > But surely that can't work, since you set up the call once but you can get > called back many times - or am I misunderstanding? m. Sorry, that depends on the callback, and I was thinking specifically of one-shot ones. (Think of beginSheetModal

Re: Apple Developer Update

On 25 Jul 2013, at 2:56 AM, Vincent Habchi wrote: > While I agree with you, I think it is also essential to keep a thread open to > sort of discharge the overflow of emotional frustration – we’re not Vulcans! > :) I admit it is an off-topic and maybe off-color and whatever-off-you-like > threa

Re: storage for context: value

Well the second two examples of those are rather different from the first. In the case of sortedArrayUsingFunction:context: and beginAnimations:context: the context is there really as an opaque pointer to pass data into the function. That pattern of function + was the pre-blocks way to pass co

Re: storage for context: value

On Jul 25, 2013, at 7:33 AM, Scott Ribe wrote: > If you alloc an object per callback setup, right where you set up the > callback, and release it in the callback, you're safe--and that's a very > common pattern I think But surely that can't work, since you set up the call once but you can get

Re: storage for context: value

On Jul 25, 2013, at 8:20 AM, Matt Neuburg wrote: > Is this the only safe/sensible storage? Could it be an actual object, cast > back and forth between id and void*? Could it be stored as an ivar? Thx as > always - m. No, of course, and yes ;-) Now the static idiom you mentioned is nice in tha

NSTask interrupt exception

Dear list, I have a couple of users reporting exceptions (and crashes) which I think are associated with my interrupting an NSTask when they close a document. I get exceptions like this: *** -[NSConcreteTask interrupt]: task not launched In the code I do the following to cancel the NSTask when

storage for context: value

I'd like to hear some arguments / opinions / essays on storage of the value passed as context:(void*), not just in addObserver:, but in general - so, including things like beginAnimations:context: and sortedArrayUsingFunction:context:. Must it always be an external variable? Must it always be s

Re: Apple Developer Update

Vincent, I respectfully disagree. If we encourage anyone who feels entitled to "discharge overflow of emotional frustration" to vent here, what's to stop anyone who disagree with Apple's policy to spam our mailboxes with tirades. I am frustrated too, but do something constructive. Blogging is a

Re: Apple Developer Update

Kyle, > Following that line of thought, how many of you actually think griping > on this list is going to accomplish anything other than filling up > everyone else's inboxes from what would otherwise be one of the > remaining useful channels? While I agree with you, I think it is also essential t