Re: FileWrapper & iCloud
On 2012-12-01, at 5:05 PM, Mike Abdullah wrote:
> On 1 Dec 2012, at 20:21, Dave Fernandes wrote:
>
>>> NSPersistentDocument always creates a MOC of type
>>> NSMainQueueConcurrencyType, even if it is created on a background thread.
>>> So as long as things don't go wrong during document opening, everything
>>> will be the same as a document opened on the main thread forever after.
>>
>> Whoops! I meant to say NSPersistentDocument always creates a MOC of type
>> **NSConfinementConcurrencyType** -- the legacy type that assumes you know
>> what you are doing and will manage access accordingly.
>
> But the Core Data team have said for years that MOCs created on the main
> thread get some special treatment.
I guess I missed that somewhere. Was it on this list?
> Of course they’ve never given us any specifics. The docs state very clearly
> that MOCs (using the non-private queue types) should be created on the same
> thread/queue that they’ll be used on.
They do say that clearly, and if you follow that you are less likely to get
into trouble; but they go on to explain that you *can* access a MOC from
different threads as long as you take responsibility for serializing access.
("If You Don’t Use Thread Containment" section from the Core Data Programming
Guide)
With concurrent opening, there is no way to use NSLocking in the background
thread if the frameworks are not doing it for you, but since you only get hold
of the MOC after the background thread has completed its work, you should not
need to lock from that point on.
-d
___
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: FileWrapper & iCloud
On 2012-12-01, at 5:12 PM, Mike Abdullah wrote: > - is comprised of a single Core Data store > - has a single managed object context This definitely limits your options. But, is it necessary to support file wrappers and iCloud? (Just trying to educate myself about how documents work.) >>> >>> I don't understand your question here. Are you asking if my list of >>> assumptions are necessary conditions for iCloud and file wrapper support? >> >> Yes, that was basically the question. For example, what if you were just >> using file wrappers to store images outside the persistent store. > > My understanding is that if you want anything to be persisted outside of Core > Data, you get treated just like a regular NSDocument subclass. i.e. no > attempt to sync by SQLite changes. > > On OS X the docs state that NSPersistentDocument is flat-out not supported > for iCloud. > > On iOS, the docs state that UIManagedDocument does not support additional > content when used for iCloud. I assume the reason is that the moment you add > into the mix some data outside of Core Data’s control/knowledge, iCloud has > no smart way to sync it, so you’re giving up that major benefit of Core Data. > Of course Core Data supports externally stored data attributes these days, so > that does improve the situation. > > At that point I figure it’s best and easiest to subclass NSDocument afresh to > add Core Data support, rather than try to bend NSPersistentDocument to your > bidding. This is what I have done with BSManagedDocument. Looks like an extremely useful class. Thank you for sharing it! Dave ___ 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: FileWrapper & iCloud
On 1 Dec 2012, at 20:12, Dave Fernandes wrote: > > On 2012-12-01, at 11:42 AM, Mike Abdullah wrote: >> One way to look at it is that NSPersistentDocument pretty much painted >> itself into a corner from day 1, and it's too messy for Apple to >> untangle that. > > Can you elaborate? Well it makes the assumptions that your document: - is comprised of a single Core Data store - has a single managed object context >>> >>> This definitely limits your options. But, is it necessary to support file >>> wrappers and iCloud? (Just trying to educate myself about how documents >>> work.) >> >> I don't understand your question here. Are you asking if my list of >> assumptions are necessary conditions for iCloud and file wrapper support? > > Yes, that was basically the question. For example, what if you were just > using file wrappers to store images outside the persistent store. My understanding is that if you want anything to be persisted outside of Core Data, you get treated just like a regular NSDocument subclass. i.e. no attempt to sync by SQLite changes. On OS X the docs state that NSPersistentDocument is flat-out not supported for iCloud. On iOS, the docs state that UIManagedDocument does not support additional content when used for iCloud. I assume the reason is that the moment you add into the mix some data outside of Core Data’s control/knowledge, iCloud has no smart way to sync it, so you’re giving up that major benefit of Core Data. Of course Core Data supports externally stored data attributes these days, so that does improve the situation. At that point I figure it’s best and easiest to subclass NSDocument afresh to add Core Data support, rather than try to bend NSPersistentDocument to your bidding. This is what I have done with BSManagedDocument. > I believe, the window controller and view objects are always created on the > main thread after the MOC has been initialized, so there won't be any > contention with trying to access the MOC from different threads at the same > time. Correct. The UI doesn’t get created until -makeWindowControllers is called, which happens on the main thread and is a standard feature of the document architecture. ___ 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: FileWrapper & iCloud
On 1 Dec 2012, at 20:21, Dave Fernandes wrote: >> NSPersistentDocument always creates a MOC of type >> NSMainQueueConcurrencyType, even if it is created on a background thread. So >> as long as things don't go wrong during document opening, everything will be >> the same as a document opened on the main thread forever after. > > Whoops! I meant to say NSPersistentDocument always creates a MOC of type > **NSConfinementConcurrencyType** -- the legacy type that assumes you know > what you are doing and will manage access accordingly. But the Core Data team have said for years that MOCs created on the main thread get some special treatment. Of course they’ve never given us any specifics. The docs state very clearly that MOCs (using the non-private queue types) should be created on the same thread/queue that they’ll be used on. ___ 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: NSUserUnixTask and com.apple.foundation.UserScriptService crash
On 1 Dec 2012, at 4:13 PM, "jonat...@mugginsoft.com"
wrote:
>NSURL *scriptsFolderURL = [[NSFileManager defaultManager]
...
> error:error];
>
>if (*error) {
>MLogInfo(@"Error: %@", *error);
...
Stop.
Go no further till you fix this. The return-by-reference NSError variable is
NEVER, EVER* an indication that the call that returns it failed. The API does
not guarantee (as you seem to assume) that *error will be nilled-out on
success; in fact, the general rule kind of promises that it _won't_. It may
still contain the garbage you passed in. It may be a scratch NSError object
that the callee filled in as a contingency — so even if you nil-out *error
yourself, it may be non-nil even if the method succeeded.
* (I believe there are a couple of methods that do use the indirect NSError as
the error indicator, but I've forgotten what they are, and they are mistakes.)
The _only_ indication that a method failed is its principal return value. It
that's nil (or 0, or NSNotFound, or NO, or whatever the API defines for that
call), _then_ you can examine the error return. Check scriptsFolderURL == nil.
By the way, apparently "error" came in as a parameter. You don't control
whether it is NULL, which is legal under the coding standard for
return-by-reference NSError. Don't dereference it until you know. I'm surprised
that got past the analyzer (unless you assert it's nonnull earlier in the
method).
Amend your code and tell us how that affects the bug.
— 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
NSUserUnixTask and com.apple.foundation.UserScriptService crash
I am trying to run the following one line echo bash script using NSUserUnixTask:
echo "hello" >/dev/stderr
The Script file is named TaskLauncher and I have dropped it into my apps code
signed id folder in NSApplicationScriptsDirectory.
The task fails to launch and com.apple.foundation.UserScriptService crashes
leaving a report in the console.
I am doing something simple wrong, either that or my expectations are wrong.
There is no sample code for this class.
The error says "Invalid argument" but I don't see what the issue is.
My code is :
// get scripts folder
NSURL *scriptsFolderURL = [[NSFileManager defaultManager]
URLForDirectory:NSApplicationScriptsDirectory
inDomain:NSUserDomainMask
appropriateForURL:nil
create:NO
error:error];
if (*error) {
MLogInfo(@"Error: %@", *error);
errMsg = NSLocalizedString(@"Cannot access applications scripts
directory: ", @"Return by server when cannot access application scripts folder
in sandboxed app.");
[NSException raise:MGSTaskStartException format:@"%@ %@",
errMsg, *error];
}
MLogInfo(@"NSApplicationScriptsDirectory = %@", scriptsFolderURL);
// form task runner path.
NSString *taskRunnerExec = @"TaskLauncher";
NSURL *taskRunnerURL = [NSURL fileURLWithPathComponents:
@[[scriptsFolderURL path], taskRunnerExec]];
MLogInfo(@"taskRunnerURL = %@", taskRunnerURL);
// initialise the task
_unixTask = [[NSUserUnixTask alloc] initWithURL:taskRunnerURL
error:error];
if (*error) {
errMsg = NSLocalizedString(@"Cannot create unix task launcher:
", @"Return by server when cannot access application scripts task launcher in
sandboxed app.");
[NSException raise:MGSTaskStartException format:@"%@ %@",
errMsg, *error];
}
void (^completionHandler)(NSError *err);
completionHandler = ^(NSError *err) {
if (err) {
NSLog(@"TaskLauncher failed: %@", err);
} else {
NSLog(@"TaskLauncher okay");
}
};
NSArray *taskArguments = @[@"hello", @"task"];
// execute the task.
[_unixTask executeWithArguments:taskArguments
completionHandler:completionHandler];
Console Log:
01/12/2012 21:50:33.966 com.apple.foundation.UserScriptService[5931]: ***
NSTask: Task create for path '/Users/Jonathan/Library/Application
Scripts/com.mysoft.myapp/TaskLauncher' failed: 22, "Invalid argument".
Terminating temporary process.
Crash report extract:
Process: com.apple.foundation.UserScriptService [5931]
Path:
/System/Library/Frameworks/Foundation.framework/Versions/C/XPCServices/com.apple.foundation.UserScriptService.xpc/Contents/MacOS/com.apple.foundation.UserScriptService
Identifier: com.apple.foundation.UserScriptService
Version: 6.8 (945.11)
Code Type: X86-64 (Native)
Parent Process: com.apple.foundation.UserScriptService [5930]
User ID: 502
Date/Time: 2012-12-01 21:50:33.979 +
OS Version: Mac OS X 10.8.2 (12C54)
Report Version: 10
Crashed Thread: 0 Dispatch queue: com.apple.NSXPCConnection.peer-user.(null)
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0002, 0x
Application Specific Information:
*** NSTask: Task create for path '/Users/Jonathan/Library/Application
Scripts/com.mysoft.myapp/TaskLauncher' failed: 22, "Invalid argument".
Terminating temporary process.
Thread 0 Crashed:: Dispatch queue: com.apple.NSXPCConnection.peer-user.(null)
0 com.apple.Foundation0x7fff93ca1258
___NEW_PROCESS_COULD_NOT_BE_EXECD___ + 5
1 com.apple.Foundation0x7fff93b7a911 -[NSConcreteTask
launchWithDictionary:] + 3544
2 com.apple.Foundation0x7fff93d60f59
-[NSUserScriptTaskRunner
executeScript:interpreter:arguments:standardInput:standardOutput:standardError::]
+ 794
3 com.apple.CoreFoundation0x7fff8912163c __invoking___ + 140
4 com.apple.CoreFoundation0x7fff891214d7 -[NSInvocation
invoke] + 263
5 com.apple.Foundation0x7fff93d49751 -[NSXPCConnection
_decodeAndInvokeMessageWithData:] + 1263
6 com.apple.Foundation0x7fff93d4b7da
__message_handler_block_invoke_0445 + 39
7 libdispatch.dylib 0x7fff8aac3f01
_dispatch_call_block_and_release + 15
8 libdispatch.dylib 0x7fff8aac00b6
_dispatch_client_callout + 8
9 libdispatch.dylib
Re: Strange observer problem (solved)
Well, its a rather complex control panel using 100% bindings through a number of generic object controllers and some fairly long binding paths. Plus, I have never figured out how to pass ³self² with a bound action, except that in one case I put in a link to from my window controller to a button just so I could bind the button view argument to position the popover. (The docks lie. You don¹t automatically get the sender using a bound action. It comes through as nil.) On 12/1/12 3:14 PM, "Kyle Sluder" wrote: > On Dec 1, 2012, at 1:09 PM, Gordon Apple wrote: > >> Re: Strange observer problem (solved) Apparently, you are right. You¹re not >> going to believe the solution I came up with. I added another button to the >> view with the same binding, linked the view to it instead of the original >> one, then hid the new button. Now, everything works correctly. If you can¹t >> skin a cat one way... > > The recommended solution would be to bind your button to a controller object > insteador better yet, stop using bindings and go back to target/action. > > --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: Strange observer problem (solved)
On Dec 1, 2012, at 1:09 PM, Gordon Apple wrote: > Apparently, you are right. You’re not going to believe the solution I came > up with. I added another button to the view with the same binding, linked > the view to it instead of the original one, then hid the new button. Now, > everything works correctly. If you can’t skin a cat one way... The recommended solution would be to bind your button to a controller object instead—or better yet, stop using bindings and go back to target/action. --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: Strange observer problem (solved)
Apparently, you are right. You¹re not going to believe the solution I came up with. I added another button to the view with the same binding, linked the view to it instead of the original one, then hid the new button. Now, everything works correctly. If you can¹t skin a cat one way... On 12/1/12 2:01 PM, "Ken Thomases" wrote: > On Dec 1, 2012, at 12:48 PM, Gordon Apple wrote: > >> > On 12/1/12 10:29 AM, "Kyle Sluder" wrote: >> > >>> >> Sounds like NSButton is not KVO-compliant for `state`. >> > >> > Well, its bindings certainly work, and the observers works when its state >> is >> > changed by the distant (also bound) button. > > Nothing about NSButton's bindings workings imply that its "state" property is > KVO-compliant. > > If something calls -setState: on the button (including KVC, while carrying out > -setValue:forKey:), then that will generate KVO change notifications. That's > because -setState: conforms to the accessor naming conventions, so KVO can > hook it. However, when the button changes its own state in response to mouse > events, it may not go through -setState: or otherwise be KVO-compliant. It > could just set an instance variable. That's invisible to KVO. > > Regards, > Ken > ___ 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: FileWrapper & iCloud
> NSPersistentDocument always creates a MOC of type NSMainQueueConcurrencyType, > even if it is created on a background thread. So as long as things don't go > wrong during document opening, everything will be the same as a document > opened on the main thread forever after. Whoops! I meant to say NSPersistentDocument always creates a MOC of type **NSConfinementConcurrencyType** -- the legacy type that assumes you know what you are doing and will manage access accordingly. ___ 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: FileWrapper & iCloud
On 2012-12-01, at 11:42 AM, Mike Abdullah wrote: > One way to look at it is that NSPersistentDocument pretty much painted > itself into a corner from day 1, and it's too messy for Apple to untangle > that. Can you elaborate? >>> >>> Well it makes the assumptions that your document: >>> >>> - is comprised of a single Core Data store >>> - has a single managed object context >> >> This definitely limits your options. But, is it necessary to support file >> wrappers and iCloud? (Just trying to educate myself about how documents >> work.) > > I don't understand your question here. Are you asking if my list of > assumptions are necessary conditions for iCloud and file wrapper support? Yes, that was basically the question. For example, what if you were just using file wrappers to store images outside the persistent store. >>> - works entirely on the main thread >> This one is already opt-in for both opening and saving, so fragility >> shouldn't be an issue to upgrading the class. >> >> [Aside: As far as I know you *can* actually open an NSPersistentDocument >> asynchronously. At least I haven't seen anything that says you can't, and it >> seems to work on every system I've tried it on.] > > Well you would appear to be breaking Core Data's threading contract by doing > so. In theory, MOCs know the thread they were created on. So by creating the > document on a background thread, you are also creating the MOC on that thread > and giving it the wrong idea about the thread it will be used on. NSPersistentDocument always creates a MOC of type NSMainQueueConcurrencyType, even if it is created on a background thread. So as long as things don't go wrong during document opening, everything will be the same as a document opened on the main thread forever after. I believe, the window controller and view objects are always created on the main thread after the MOC has been initialized, so there won't be any contention with trying to access the MOC from different threads at the same time. This is all identical on 10.6 and 10.7+. > > On 10.7+ you can of course tell the context at creation time it's for the > main thread, but I'd be a little surprised if NSPersistentDocument is doing > that. > > I also covered the topic fairly recently: > http://www.mikeabdullah.net/concurrently-open-core-data-docs.html > ___ 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: Strange observer problem
On Dec 1, 2012, at 12:48 PM, Gordon Apple wrote: > On 12/1/12 10:29 AM, "Kyle Sluder" wrote: > >> Sounds like NSButton is not KVO-compliant for `state`. > > Well, its bindings certainly work, and the observers works when its state is > changed by the distant (also bound) button. Nothing about NSButton's bindings workings imply that its "state" property is KVO-compliant. If something calls -setState: on the button (including KVC, while carrying out -setValue:forKey:), then that will generate KVO change notifications. That's because -setState: conforms to the accessor naming conventions, so KVO can hook it. However, when the button changes its own state in response to mouse events, it may not go through -setState: or otherwise be KVO-compliant. It could just set an instance variable. That's invisible to KVO. Regards, Ken ___ 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: Strange observer problem
Well, its bindings certainly work, and the observers works when its state is changed by the distant (also bound) button. On 12/1/12 10:29 AM, "Kyle Sluder" wrote: > Sounds like NSButton is not KVO-compliant for `state`. > > --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
"Dangling reference to an invalid object"
I've been trying to hunt down a problem where Core Data will occasionally refuse to save with the error " Dangling reference to an invalid object". I wrote up the details here: http://www.mikeabdullah.net/dangling-ref-to-an-invalid-object.html Can anyone shed some light on how this might happen? ___ 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: FileWrapper & iCloud
On 30 Nov 2012, at 23:05, Dave Fernandes wrote: > > On 2012-11-30, at 4:46 PM, Mike Abdullah wrote: > >> >> On 30 Nov 2012, at 18:59, Dave Fernandes wrote: >> >>> >>> On 2012-11-30, at 6:42 AM, Mike Abdullah wrote: >>> One way to look at it is that NSPersistentDocument pretty much painted itself into a corner from day 1, and it's too messy for Apple to untangle that. >>> >>> Can you elaborate? >> >> Well it makes the assumptions that your document: >> >> - is comprised of a single Core Data store >> - has a single managed object context > > This definitely limits your options. But, is it necessary to support file > wrappers and iCloud? (Just trying to educate myself about how documents work.) I don't understand your question here. Are you asking if my list of assumptions are necessary conditions for iCloud and file wrapper support? > >> - works entirely on the main thread > This one is already opt-in for both opening and saving, so fragility > shouldn't be an issue to upgrading the class. > > [Aside: As far as I know you *can* actually open an NSPersistentDocument > asynchronously. At least I haven't seen anything that says you can't, and it > seems to work on every system I've tried it on.] Well you would appear to be breaking Core Data's threading contract by doing so. In theory, MOCs know the thread they were created on. So by creating the document on a background thread, you are also creating the MOC on that thread and giving it the wrong idea about the thread it will be used on. On 10.7+ you can of course tell the context at creation time it's for the main thread, but I'd be a little surprised if NSPersistentDocument is doing that. I also covered the topic fairly recently: http://www.mikeabdullah.net/concurrently-open-core-data-docs.html ___ 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: Strange observer problem
Sounds like NSButton is not KVO-compliant for `state`. --Kyle Sluder On Dec 1, 2012, at 7:55 AM, Gordon Apple wrote: > Seemingly simple problem. View in a panel window has a push-on/push-off > button. View has link to button (so I don¹t have to find it by tag). View > observes button state. Observer sets a color property according to button > state and calls [self setNeedsDisplay:YES]. Draw method fills view with > color. Problem: Goes through the motions, but doesn¹t work. > > Button is bound to property elsewhere. Another view has same button > function bound to same property. Clicking second button visible changes > first button state and containing view changes color appropriately. Why > doesn¹t clicking first button work? I¹ve even tried a delayed invocation on > setNeedsDisplay. What¹s going on here that¹s defeating the redraw when its > own button is pushed? > > (Panel is non-activating, hide on deactivate, which makes tracing in xcode > debugging difficult. Have to do it with NSLogs.) > > > > ___ > > 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/kyle%40ksluder.com > > This email sent to k...@ksluder.com ___ 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
Strange observer problem
Seemingly simple problem. View in a panel window has a push-on/push-off button. View has link to button (so I don¹t have to find it by tag). View observes button state. Observer sets a color property according to button state and calls [self setNeedsDisplay:YES]. Draw method fills view with color. Problem: Goes through the motions, but doesn¹t work. Button is bound to property elsewhere. Another view has same button function bound to same property. Clicking second button visible changes first button state and containing view changes color appropriately. Why doesn¹t clicking first button work? I¹ve even tried a delayed invocation on setNeedsDisplay. What¹s going on here that¹s defeating the redraw when its own button is pushed? (Panel is non-activating, hide on deactivate, which makes tracing in xcode debugging difficult. Have to do it with NSLogs.) ___ 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: enhancing NSTextView for optionally-hidden text
On 11/21/12 7:56 AM, Kyle Sluder wrote: On Wed, Nov 21, 2012, at 07:25 AM, Ross Carter wrote: The way to do this is by subclassing NSGlyphGenerator to return null glyphs for text that has your custom Hidden attribute. A WWDC video from a few years back shows how. Specifically, start watching from around 21:00 in the video for Session 114—Advanced Cocoa Tips and Tricks from WWDC 2010. --Kyle Sluder Thanks, got it. They make you work a little to get those videos. I had no luck doing a search, e.g. for WWDC 2010 Session 114—Advanced Cocoa Tips and Tricks, which only brought up irrelevant results. Instead searching for WWDC produced some results, but none from 2010, after which WWDC 2010 got me in the ballpark. This page is a step: https://developer.apple.com/videos/wwdc/2010/ but is misleading because after selecting the particular video (and they are not numbered by session) to watch you get instead the entire collection and have to once again find and select the same video within iTunes you had already selected on the page linked above. (Fortunately at least I did not have to sign up to be a member.) But I'd have never found this without your help, so thanks! -Kurt ___ 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
