Re: NSSavePanel problem with sandboxing
On 05/09/2013, at 8:54 PM, Kyle Sluder wrote: > What happens if you ask one of your accessory controls for its -window > and ask _that_ object to -makeFirstResponder:? That window should be in > your own process. Works on 10.8, but in fact the control's window is the same object as the save panel. That makes sense, since I found the "well-defined times" note I remembered, it's in the 10.8 release notes. The completion block is indeed a valid time, but that isn't the case on 10.7. The mind boggles at the hacks being pulled behind the scenes here - the pointer value for the save panel never changes, but the object it points to has some serious changes of identity. Testing this on 10.7 is difficult, so I won't know if it works there for a while, but here's hoping…. thanks :) --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Auto layout semantics?
[this seems to have bounced earlier] Hi Kyle, Izak, On Aug 16, 2013, at 19:18 , Kyle Sluder wrote: > As Ken Ferry described in his Auto Layout session at WWDC 2011, the specific > solver used by Apple is based on the Cassowary constraint engine. Yes, the algorithm involved is a variant of the Simplex algorithm, optimized for incremental re-solves. http://www.badros.com/greg/papers/cassowary-tochi.pdf > So asking for the "algorithm" isn't really that helpful, because Auto Layout > is not defined or implemented imperatively. There's an algorithm involved, > but that algorithm is a general-purpose constraint solver that operates on > linear equations. Strictly speaking it has nothing to do with views. True, the behavior has nothing to do with views in particular, but the algorithm in question does have an effect on the results, particularly… On Aug 16, 2013, at 19:06 , Izak van Langevelde wrote: > I have only been able to sort this out by adding in code a constraint that > explicitly constrains the two fields as having the same width. My main > concern is that it feels too complicated for something this simple. …the simplex algorithm searches for optima in the “corners” of the multi-dimensional polyhedron (by walking along the edges). http://en.wikipedia.org/wiki/Cutting-plane_method This means that it will prefer solutions where one variable takes up all the slack over one where the slack is distributed equally between two variables. However, the fact that you are leaving this up to the algorithm does mean that your set of constraints is underconstrained and that adding the equality constraints is the right solution (probably with a lower priority than other constraints). So called “interior point” methods that do not follow the edges also exist, but despite the fact that these have theoretically better running times (polynomial, whereas the simplex is exponential), in practice the simplex is much faster, usually running in linear time. Cheers, Marcel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Threadsafe copy of objective c object
On Sep 3, 2013, at 12:52 , Jonathan Taylor
wrote:
> I have an objective c object which contains a number of properties that serve
> as parameters for an algorithm. They are bound to UI elements. I would like
> to take a snapshot copy of the object that will be used for one whole run of
> the algorithm (rather than risk parameters changing halfway through the run).
> i.e. I just want to do [myObject copy].
What are the property parameters? A bunch of numbers, maybe some strings?
> [complications]
> Is there any way, then, that I can take a copy in a threadsafe manner? If
> necessary I can do the copy on the main thread, but I would prefer not to
> have to do that for timing reasons.
Unless there is some dire reason not to do this, I would make a copy on the
main thread every time the UI changes, and stash that copy somewhere the worker
thread can access it easily.
The reasoning is that humans are generally slow compared to computers, so
changes are likely going to happen at reasonably slow rate.
-(void)uiDidChange
{
id newSnapshot=[[parameters copy] autorelease];
[self setSnapshot:newSnapshot];
}
Marcel
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSSavePanel problem with sandboxing
On Thu, Sep 5, 2013, at 11:33 AM, Graham Cox wrote: > > On 05/09/2013, at 8:31 PM, Kyle Sluder wrote: > > > Is this even necessary? The save panel's values should be correct at > > time of dismissal. > > > But fields in my accessory view might not be. That's the problem I'm > trying to solve - I've entered a value in a text field but have done > nothing to 'commit' the text, just hit 'Save'. So the problem is that your accessory views aren't firing their actions on panel dismissal? What happens if you ask one of your accessory controls for its -window and ask _that_ object to -makeFirstResponder:? That window should be in your own process. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel problem with sandboxing
On 5 Sep 2013, at 1:27 PM, Graham Cox wrote: > I'm using NSSavePanel in a sandboxed app. The panel includes a custom > accessory view, which works fine. > > I run the panel using -[NSSavePanel > beginSheetModalForWindow:completionHandler:]; > > In the completion handler, I call [savePanel makeFirstResponder:savePanel] so > that any text fields left in a 'pending' state commit their contents to > update the stuff they set via action methods. This is the usual way I commit > unsaved fields in any dialog or sheet, and that's always worked. > > This also works, except on 10.7 (10.6 and 10.8 seem OK). On 10.7, I get an > exception: -[NSRemoteSavePanel makeFirstResponder:]: unrecognized selector > sent to instance. The documentation for sandboxing suggests that this is > likely to be the case, though I've read somewhere that the full NSPanel > methods are available at some well-defined times (I can't however find the > documentation that mentions that, and whether the completion handler is one > of the sanctioned times). > > What can I do here to workaround this? The next thing I'd do is to see if the protocol would be of any comfort. I think it may even be preferred to resetting the window's first responder. 30 seconds' thought, take it for its worth. — F ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: UITextField access from outside the main thread
On Sep 5, 2013, at 9:23 AM, Aaron Montgomery wrote: > > which is now looking like an awful lot of work just to read a data value and > adding a lot of extra code just to accommodate Test Studio. Right. The solution seems to be to ditch a development app that apparently doesn't even bother to understand the threading requirements of the platform it targets. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSSavePanel problem with sandboxing
I'm using NSSavePanel in a sandboxed app. The panel includes a custom accessory view, which works fine. I run the panel using -[NSSavePanel beginSheetModalForWindow:completionHandler:]; In the completion handler, I call [savePanel makeFirstResponder:savePanel] so that any text fields left in a 'pending' state commit their contents to update the stuff they set via action methods. This is the usual way I commit unsaved fields in any dialog or sheet, and that's always worked. This also works, except on 10.7 (10.6 and 10.8 seem OK). On 10.7, I get an exception: -[NSRemoteSavePanel makeFirstResponder:]: unrecognized selector sent to instance. The documentation for sandboxing suggests that this is likely to be the case, though I've read somewhere that the full NSPanel methods are available at some well-defined times (I can't however find the documentation that mentions that, and whether the completion handler is one of the sanctioned times). What can I do here to workaround this? --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel problem with sandboxing
On 05/09/2013, at 8:31 PM, Kyle Sluder wrote: > Is this even necessary? The save panel's values should be correct at > time of dismissal. But fields in my accessory view might not be. That's the problem I'm trying to solve - I've entered a value in a text field but have done nothing to 'commit' the text, just hit 'Save'. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel problem with sandboxing
On Thu, Sep 5, 2013, at 11:27 AM, Graham Cox wrote: > What can I do here to workaround this? Is this even necessary? The save panel's values should be correct at time of dismissal. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
UITextField access from outside the main thread
Hi,
I'm currently running into this issue trying to use Telerik Test Studio (and am
asking about it there as well), but I think the issue is more general and would
like some ideas.
The situation: Test Studio drives my app's user interface from a background
thread. In some places where the Test Studio is just interacting wth UI
elements, I get a WebThreadLockFromAnyThread warnings (which is expected since
you shouldn't interact with the UI from another thread). I believe they've done
the coding to avoid the warning in most cases, but I've got some subclasses of
UITextField that are generating the warnings. Note, in all examples, self is an
object whose class is a subclass of UITextField.
In some places, the solution is to use blocks, replacing:
[self.objectField reloadInputViews];
with:
dispatch_async(dispatch_get_main_queue(), ^{ [self.objectField
reloadInputViews]; });
which works. The problem is places where I want to read the data. In those
cases, replacing:
NSString* theName = self.text;
with:
__block NSString* theName = nil;
dispatch_sync(dispatch_get_main_queue(), ^{ theName = self.text; });
will block the main thread if run from the main thread (note that I really need
a dispatch_sync so I can get the return value before continuing). So I end up
with the replacement:
__block NSString* theName = nil;
if ([NSThread isMainThread])
{
theName = self.text;
}
else
{
dispatch_sync(dispatch_get_main_queue(), ^{ theName =
self.text; });
}
which is now looking like an awful lot of work just to read a data value and
adding a lot of extra code just to accommodate Test Studio.
So the questions:
Are there any pitfalls to the replacements above that I'm missing?
Should I be doing this in any case to make my code safer?
Is there a better way to go about accessing self.text that works on any thread?
If I wanted to actually update self.text from any thread (haven't needed to do
this yet, but it may arise) would the code below be my best option?
if ([NSThread isMainThread])
{
self.text = theName;
}
else
{
dispatch_sync(dispatch_get_main_queue(), ^{ self.text =
theName; });
}
Thanks,
Aaron
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSTimezone and offset
Thank you for clearing that up. I have it now. On Sep 4, 2013, at 11:49 PM, dangerwillrobinsondan...@gmail.com wrote: > You are confusing the method with secondsFromGMT > > CDT is 3600 seconds is one hour ahead of CST and the docs could be more clear > about this method being self referential rather than GMT referential. > > Sent from my iPhone > > On 2013/09/05, at 13:21, Lorenzo Thurman wrote: > >> Im working with NSTimezone and I need to get the current timezone offset, >> but I'm finding this more difficult than I think it should be. I thought it >> might just be the way I'm looking at things, but I don't think so. >> >> If create an NSTimezone object and then send that object a >> daylightSavingTimeOffset message, I get back, for Chicago, 3600. This is >> wrong, at least for my purposes, for two reasons: >> 1) The offset should negative. >> 2) Chicago is currently observing DST >> >> The value I would expect to see returned should be -3000. I get why the >> value 3600 is correct at least with respect to the magnitude, as I can see I >> have this link setup for my system: >> /etc/localtime -> /usr/share/zoneinfo/America/Chicago >> >> But, why is it not negative? How do I get the correct offset. >> TIA >> ___ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Debugging kCGErrorIllegalArgument: CGSUnionRegionWithRect : Invalid region
> Do you have any secondary threads? I assume you do. Indeed! > Any code that touches a view, no matter how indirectly, could be the culprit. > Bear in mind that sending any message to any view (controls, etc) might > invoke -setNeedsDisplay: which in turn could be the trigger for the problem. > Try setting a breakpoint on -setNeedsDisplay: though of course it will be hit > a lot, so you might need a clever condition to avoid being overwhelmed. Even > one that excludes the main thread might help, e.g. [NSThread currentThread] > != [NSThread mainThread] That suggestion for a breakpoint is a great one. Sadly the condition you quoted doesn't seem to be parsed correctly by the debugger, even with casting. Even just "po (NSThread*)[NSThread currentThread]" fails on my machine. Fortunately, though, there were only a couple of dozen hits on the breakpoint per iteration of the code, and sure enough it immediately pinpointed a case where I was erroneously calling willChangeValueForKey from a secondary thread, which was causing a GUI update as a side-effect. Cheers Jonny. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Debugging kCGErrorIllegalArgument: CGSUnionRegionWithRect : Invalid region
On 05/09/2013, at 12:37 PM, Jonathan Taylor wrote: > Yes, I understand that. I am not aware of doing any drawing from secondary > threads, although evidently it appears that somewhere in the program this is > happening. My question is whether I can do anything to help track down the > problem, because right now I am limited to code reading and/or the very slow > process of disabling sections of code (slow because it's an intermittent > problem and each time I would need to run for long enough that I can be > reasonably sure I would have hit the error if I was going to...). Do you have any secondary threads? I assume you do. Any code that touches a view, no matter how indirectly, could be the culprit. Bear in mind that sending any message to any view (controls, etc) might invoke -setNeedsDisplay: which in turn could be the trigger for the problem. Try setting a breakpoint on -setNeedsDisplay: though of course it will be hit a lot, so you might need a clever condition to avoid being overwhelmed. Even one that excludes the main thread might help, e.g. [NSThread currentThread] != [NSThread mainThread] --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Threadsafe copy of objective c object
On 4 Sep 2013, at 16:46, Marcel Weiher wrote: >>> Unless there is some dire reason not to do this, I would make a copy on the >>> main thread every time the UI changes, and stash that copy somewhere the >>> worker thread can access it easily. >> >> That's a really good plan, I realised that last night. I had been stuck >> thinking about kind of the opposite approach (make a copy on each invocation >> of the processing algorithm), but this makes a lot of sense. How does this >> sound: >> >> When the UI leads to changes in the (mutable) primary object I'll make a >> copy stored in an immutable shadow object (from the main thread). >> Whenever the algorithm is invoked (from a secondary thread in response to >> receipt of a frame) I retain the immutable shadow object and pass this >> pointer to the algorithm. > > Sounds pretty good to me. I’d probably stash it in an instance variable. In > a sense, this is a variant of the immutability that Ian and Jens suggested: > create a copy that you won’t mutate. OK, thanks everyone for your input on this one. I've got something I'm fairly happy with now, which is working according to plan. I was a bit surprised at how much "glue" I ended up having to put together to make it work though. Maybe that's just the nature of the thing, but if anybody was interested enough to critique the code that I've come up with (on or off list) then I'd be very grateful to hear any comments. https://docs.google.com/file/d/0Bye8FKbpg3dYa1R2Z1hPWERmcjQ/edit Cheers Jonny. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Debugging kCGErrorIllegalArgument: CGSUnionRegionWithRect : Invalid region
> You can't do any UI-related updates from a secondary thread, you must ask the > main thread to do it. > > It might not be progress bars but anything at all that's being drawn from a > secondary thread. The error itself could indicate that an internal data > structure was used or updated by another thread while in an inconsistent > state. Yes, I understand that. I am not aware of doing any drawing from secondary threads, although evidently it appears that somewhere in the program this is happening. My question is whether I can do anything to help track down the problem, because right now I am limited to code reading and/or the very slow process of disabling sections of code (slow because it's an intermittent problem and each time I would need to run for long enough that I can be reasonably sure I would have hit the error if I was going to...). ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Debugging kCGErrorIllegalArgument: CGSUnionRegionWithRect : Invalid region
On 05/09/2013, at 12:21 PM, Jonathan Taylor wrote: > Searching for those terms finds suggestions that this may be associated with > updating progress bars from a secondary thread. I still see the error even > after removing the only progress bar from my program; I don't know whether > the cause is something genuinely associated with progress bars, or whether > it's just that it's easy to slip up and update them from a secondary thread, > triggering this error. You can't do any UI-related updates from a secondary thread, you must ask the main thread to do it. It might not be progress bars but anything at all that's being drawn from a secondary thread. The error itself could indicate that an internal data structure was used or updated by another thread while in an inconsistent state. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Debugging kCGErrorIllegalArgument: CGSUnionRegionWithRect : Invalid region
Can anybody help me diagnose an error that I see intermittently? The errors are as follows: Thu Sep 5 10:11:11 Jonathan-Taylors-Mac-Pro.local Spim GUI[34152] : kCGErrorIllegalArgument: CGSUnionRegionWithRect : Invalid region Thu Sep 5 10:11:11 Jonathan-Taylors-Mac-Pro.local Spim GUI[34152] : kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged. (gdb) continue Thu Sep 5 10:11:17 Jonathan-Taylors-Mac-Pro.local Spim GUI[34152] : kCGErrorIllegalArgument: CGSGetRegionBounds : Invalid region Searching for those terms finds suggestions that this may be associated with updating progress bars from a secondary thread. I still see the error even after removing the only progress bar from my program; I don't know whether the cause is something genuinely associated with progress bars, or whether it's just that it's easy to slip up and update them from a secondary thread, triggering this error. The error is very intermittent which makes narrowing it down hard, and setting the breakpoint as advised hasn't helped me since there isn't anything of mine in the call stack when the condition is encountered: #0 0x97a7610a in CGErrorBreakpoint #1 0x97b0b9e0 in CGSGlobalErrorv #2 0x978e96d5 in CGSUnionRegionWithRect #3 0x984ea84c in -[NSRegion addRegion:] #4 0x984ea69d in -[NSWindow _setNeedsDisplayInRegion:] #5 0x9843ae86 in -[NSWindow _absorbDeferredNeedsDisplayRegion] #6 0x98439a54 in -[NSView _sendViewWillDrawInRect:clipRootView:suppressRecursion:] #7 0x9839c80e in -[NSView displayIfNeeded] #8 0x98365b64 in -[NSWindow displayIfNeeded] #9 0x9839707e in _handleWindowNeedsDisplay #10 0x94f04dd2 in __CFRunLoopDoObservers #11 0x94ec0ced in __CFRunLoopRun #12 0x94ec03c4 in CFRunLoopRunSpecific #13 0x94ec01f1 in CFRunLoopRunInMode #14 0x92e8ce04 in RunCurrentEventLoopInMode #15 0x92e8cbb9 in ReceiveNextEventCommon #16 0x92e8ca3e in BlockUntilNextEventMatchingListInMode #17 0x9836d595 in _DPSNextEvent #18 0x9836cdd6 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] #19 0x9832f1f3 in -[NSApplication run] #20 0x98327289 in NSApplicationMain #21 0x2b69 in start at vector.tcc:244 Can anyone advise on anything I can do to help diagnose this? Even something that made it happen much more frequently would be some help, as I might then have more of a chance of narrowing down the cause by disabling chunks of code. Cheers Jonny ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
