Re: NSController controllerEditor:didCommit :… exception
Kyle: > The main menu nib is kind of funny. It's loaded differently (or at > least at a different time) than the other nibs. It's much more > sensitive to timing issues like this. > > Who provides the MOC for the controller (another object in the nib?), > and how is it provided (bindings, -setManagedObjectContext:)? Yes, the MOC is provided through a binding to the AppController, itself part of the NIB. But the MOC iVar is set to nil until the user successfully opens a persistent store file. So I imagine the init code for the NSArrayController protests against finding a MOC set to nil. But since I don't actually need the array before the MOC is initialized, ignoring the exception it raises does not lead to a fatal error. I worked around this annoyance by opening a temporary MOC. I imagine I could also decide to remove the controller from the NIB and create it programmatically only when a proper store is opened. Cheers and thanks for help! Vincent___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [iPhone] Toolbar button and "Touch Down"
Interesting idea, probably a little beyond me. :) I was hoping there might be a direct way of having the UIBarButtonItem respond immediately to a user's touch, instead of waiting until the user's finger is lifted. On Nov 12, 2010, at 8:53 PM, Dave DeLong wrote: > Random idea (untested, just spouting here) > > What about initing a barButtonItem with a custom view (that view being a > UIButton that has the target/action set on the appropriate touch down inside > [the end zone! - sorry, couldn't resist]), and then setting the target/action > of the barButtonItem itself to nil? > > In other words, let a different control handle the target/action instead of > the bar button item itself. > > Dave > > On Nov 12, 2010, at 11:57 AM, Jon Sigman wrote: > >> I struggled this too, but without solution. It seems that toolbar 'buttons' >> aren't real buttons -- they're class UIBarButtonItem from UIBarItem from >> NSObject. Since they're not really buttons, there doesn't appear any way to >> modify their behavior. If there is a way, I'd like to know, too... >> >> >> >> >> >> From: Jonathon Kuo >> To: Cocoa-Dev List >> Sent: Fri, November 12, 2010 10:02:15 AM >> Subject: [iPhone] Toolbar button and "Touch Down" >> >> I'm doing an iPhone 4.1 app and I have a toolbar at the bottom with bar >> buttons. >> The problem is that I need to set one of the bar buttons to "Touch Down" >> instead >> of the default "Touch Up Inside" but IB doesn't show any touch options for >> toolbar buttons (it does for buttons not in the toolbar). >> >> Is there a programmatic way to set this? >> Thx >> >> ___ >> >> 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: >> http://lists.apple.com/mailman/options/cocoa-dev/rf_egr%40yahoo.com >> >> This email sent to rf_...@yahoo.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: >> http://lists.apple.com/mailman/options/cocoa-dev/davedelong%40me.com >> >> This email sent to davedel...@me.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSController controllerEditor:didCommit: … exception
On Nov 15, 2010, at 5:32 AM, Vincent Habchi wrote: > > Yes, the MOC is provided through a binding to the AppController, itself part > of the NIB. But the MOC iVar is set to nil until the user successfully opens > a persistent store file. So I imagine the init code for the NSArrayController > protests against finding a MOC set to nil. But since I don't actually need > the array before the MOC is initialized, ignoring the exception it raises > does not lead to a fatal error. > > I worked around this annoyance by opening a temporary MOC. I imagine I could > also decide to remove the controller from the NIB and create it > programmatically only when a proper store is opened. This sounds like a perfect candidate for factoring out your MOC-dependent UI and loading it only after the MOC has been successfully created. If your app is simple enough, your app delegate could initialize the MOC and act as the nib's File's Owner. In more complicated applications, I would instead recommend the app delegate still be in charge of creating the MOC, but also creating an NSWindowController that loaded the window's nib and acted as File's Owner. This is quite like the NSDocument architecture. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSController controllerEditor:didCommit :… exception
Kyle: > If your app is simple enough, your app delegate could initialize the MOC and > act as the nib's File's Owner. In more complicated applications, I would > instead recommend the app delegate still be in charge of creating the MOC, > but also creating an NSWindowController that loaded the window's nib and > acted as File's Owner. This is quite like the NSDocument architecture. My app is neither very simple, nor very complex. Your first solution should be more than adequate. Thanks a lot, have a great day! Vincent___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Releasing static variable & concurrent data protection questions...
Environment: OS X (10.6.5) & iOS4+...
Scenario:
I have a static object (myNumber) that I use to accumulate a value through
multiple iterations from concurrent blocks.
Here's what I have learned:
1) Best way to 'share' variables is via heap vs stack.
Hence, I've created a static object 'myNumber' that accumulates value.
The following is the code:
#import "ObjcBlocksViewController.h"
@implementation ObjcBlocksViewController
- (void)myPrintResults:(NSString *)desc {
static NSNumber *myNumber = nil;
if (myNumber == nil) {
myNumber = [[NSNumber alloc] initWithInt:0];
}
NSInteger myInteger = [myNumber integerValue];
myInteger += 5;
myNumber = [NSNumber numberWithInteger:myInteger];
NSLog(@"{myPrintResults} %@ myNumber = %@", desc, myNumber);
}
- (IBAction)buttonAction:(id)sender {
NSLog(@"{buttonAction} top");
dispatch_queue_t queue =
dispatch_queue_create("com.mycompany.myButton", NULL);
dispatch_async(queue, ^(void) {
NSLog(@"- {Outer-Block Operation} Top " );
[self myPrintResults:@"Main Loop"];
for (int k = 0; k < 10; k++) {
dispatch_async(dispatch_get_main_queue(), ^(void) {
[self myPrintResults:[NSString
stringWithFormat:@"(%d)-Inner Loop-",k]];
});
}
NSLog(@"- {Outer-Block Operation} Bottom " );
});
dispatch_release(queue);
NSLog(@"{buttonAction} bottom.");
} // end buttonAction().
- (void)dealloc {
[super dealloc];
}
@end
The output is expected:
...ObjcBlocks[1563:40b] {buttonAction} top
...ObjcBlocks[1563:40b] {buttonAction} bottom.
...ObjcBlocks[1563:1903] - {Outer-Block Operation} Top
...ObjcBlocks[1563:1903] {myPrintResults} Main Loop myNumber = 5
...ObjcBlocks[1563:40b] {myPrintResults} (0)-Inner Loop- myNumber = 10
...ObjcBlocks[1563:40b] {myPrintResults} (1)-Inner Loop- myNumber = 15
...
...ObjcBlocks[1563:40b] {myPrintResults} (9)-Inner Loop- myNumber = 55
...ObjcBlocks[1563:1903] - {Outer-Block Operation} Bottom
Questions:
1) How do I properly release my static NSNumber *myNumber after use?
It's static with a scope within an ObjC method so I can't release it in the
dealloc().
2) Is the @synchronized() directive required within myPrintResults() to protect
from possible thread crashes?
Regards,
Ric.
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSController controllerEditor:didCommit :… exception
On Mon, Nov 15, 2010 at 12:00 PM, vincent habchi wrote: > My app is neither very simple, nor very complex. Your first solution should > be more than adequate. > > Thanks a lot, have a great day! No problem. Just keep in mind that by avoiding NSWindowController, you lose its automatic breaking of bindings-related retain cycles. But if your app isn't a document based app, that's probably irrelevant since the bindings won't be torn down anyway until your app quits, at which point leaks are irrelevant. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Releasing static variable & concurrent data protection questions...
On Nov 15, 2010, at 1:06 PM, Frederick C.Lee wrote: > 1) How do I properly release my static NSNumber *myNumber after use? Why would you want to? The point of a static is to last the lifetime of the application. However, your code as you posted it, is quite messed up. You create a number that you own and store the pointer in myNumber. Then you repeatedly reassign myNumber with a new object which you do not own and which will be dealloc'd out from under you at some point in the future. > 2) Is the @synchronized() directive required within myPrintResults() to > protect from possible thread crashes? Well, if you insist on allocating new NSNumbers and reassigning them all them time, absolutely. Even if you fix the memory management, you still have to guard against simultaneous execution of the method body because, well, all sorts of things could go wrong with that code. Is this real code? Are you really just accumulating a counter? If so, I would suggest starting with a major simplification: static int mynum = 0; mynum += 5; Even then, you still have to guard against overlapping execution. Although at least the worst case is an increment operation being "lost", instead of crashing. You can avoid that problem easily with @synchronized, or you can take a peek at OSAtomic.h... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Releasing static variable & concurrent data protection questions...
This isn't 'real code'. This is merely an attempt to learn GCD & concurrency: sharing common data, etc. The reason for alloc a NSNumber is to work with the heap vs stack. I'll also be working with C structures as well. Yes, working with static int mynum is of course, much simpler. I'll peek at OSAtomic.h I'm in a learning phase, so I'll expect to 'flutter about' before I can fly. BTW: working with static variables - Is it possible to using 'static' within a 'task'; i.e., releasing it BEFORE the end of the application termination? Something like this: NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; ... static NSNumber *myNum = [[NSNumber alloc] initwithInt:0] autorelease]? ... [pool drain]; Ric. Concurrent Neophyte. On Nov 15, 2010, at 12:36 PM, Scott Ribe wrote: > > On Nov 15, 2010, at 1:06 PM, Frederick C.Lee wrote: > >> 1) How do I properly release my static NSNumber *myNumber after use? > > Why would you want to? The point of a static is to last the lifetime of the > application. > > However, your code as you posted it, is quite messed up. You create a number > that you own and store the pointer in myNumber. Then you repeatedly reassign > myNumber with a new object which you do not own and which will be dealloc'd > out from under you at some point in the future. > >> 2) Is the @synchronized() directive required within myPrintResults() to >> protect from possible thread crashes? > > Well, if you insist on allocating new NSNumbers and reassigning them all them > time, absolutely. Even if you fix the memory management, you still have to > guard against simultaneous execution of the method body because, well, all > sorts of things could go wrong with that code. > > Is this real code? Are you really just accumulating a counter? > > If so, I would suggest starting with a major simplification: > > static int mynum = 0; > mynum += 5; > > Even then, you still have to guard against overlapping execution. Although at > least the worst case is an increment operation being "lost", instead of > crashing. You can avoid that problem easily with @synchronized, or you can > take a peek at OSAtomic.h... > > > -- > Scott Ribe > scott_r...@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Releasing static variable & concurrent data protection questions...
On Nov 15, 2010, at 1:08 PM, Frederick C. Lee wrote: > I'll peek at OSAtomic.h > > I'm in a learning phase, so I'll expect to 'flutter about' before I can fly. In that case, do not peek at OSAtomic.h. Avoid OSAtomic.h until you understand the basics of coordinating access to shared data. > BTW: working with static variables - Is it possible to using 'static' within > a 'task'; i.e., releasing it BEFORE the end of the application termination? No. Use an instance variable. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Releasing static variable & concurrent data protection questions...
Thanks for the warning! Understood. Ric. On Nov 15, 2010, at 1:09 PM, Greg Parker wrote: > On Nov 15, 2010, at 1:08 PM, Frederick C. Lee wrote: >> I'll peek at OSAtomic.h >> >> I'm in a learning phase, so I'll expect to 'flutter about' before I can fly. > > In that case, do not peek at OSAtomic.h. Avoid OSAtomic.h until you > understand the basics of coordinating access to shared data. > > >> BTW: working with static variables - Is it possible to using 'static' within >> a 'task'; i.e., releasing it BEFORE the end of the application termination? > > No. Use an instance variable. > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Releasing static variable & concurrent data protection questions...
On Nov 15, 2010, at 2:08 PM, Frederick C. Lee wrote: > This isn't 'real code'. > This is merely an attempt to learn GCD & concurrency: sharing common data, > etc. OK. > The reason for alloc a NSNumber is to work with the heap vs stack. > I'll also be working with C structures as well. static int wouldn't be on the stack either, FYI. What exactly is the concern with heap vs stack? Just experimentation & learning? Or are you looking for heap allocation for a specific reason? > I'm in a learning phase, so I'll expect to 'flutter about' before I can fly. If you're learning threads, expect to crash & burn a few times ;-) > BTW: working with static variables - Is it possible to using 'static' within > a 'task'; i.e., releasing it BEFORE the end of the application termination? > > Something like this: > > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > ... > static NSNumber *myNum = [[NSNumber alloc] initwithInt:0] autorelease]? > ... > [pool drain]; That code would compile and run, and after the [pool drain] statement you'd have a pointer, myNum, to a deallocated NSNumber, which you couldn't (or, shouldn't) use for anything. Remember, in that code the *pointer* is static, not the object to which it points. Why do you care about deallocating statics? It's not something that's generally useful. Granted, there might be some situation where you want to replace a static pointer-to-object with a different pointer, so you'd need to release before assigning in order to avoid a leak... -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Releasing static variable & concurrent data protection questions...
Ultimate scenario:
Predicting satellites... one...many.
Each satellite is govern my Keplerian physics {drag,etc.}; so I'll be
working with a dozen+ variables, in parallel/concurrently.
Programming Scenario:
a) Satellites' identifiers stored in Core Data. <--- Done.
b) User select selects a one or more satellites to track/predict.
Calculating Data Vector: C structs vs ObjC objects.
Hence, I would like to use GCD in managing concurrent processes, sharing data.
The design is nascent: exploring various paradigms using ^blocks.
What I've learnt, know:
1) Static variables shouldn't be released, good for the entire life of the
application.
2) Static variables on stack <-- I was aware of this.
3) Heap data are easier (?) to share vs stack; hence considering working with
pointers to head objects.
My current ignorant design:
One current design is to iterate a ^block (rep. satellite's idiosyncrasies)
concurrently, with each iteration calculating accumulating data.
Hence I need to share persistent C-struct{} of data.
Something like this:
for (processData) {
dispatch_async(dispatch_get_main_queue(), ^(void) {
calcSat(dataVar); // where dataVar would be a C-struct.
});
}
Second (2nd) design:
Create one (1) ^block that exists for the ENTIRE iteration of the data.
That is, iterate the calculations WITHIN the block till a specific condition
is meet OR cancelled via outside request.
I'm thinking the 2nd design is better.
In the meantime, I'm toying with ObjC/C in various scenarios to learn the beast.
Ric.
On Nov 15, 2010, at 1:48 PM, Scott Ribe wrote:
> On Nov 15, 2010, at 2:08 PM, Frederick C. Lee wrote:
>
>> This isn't 'real code'.
>> This is merely an attempt to learn GCD & concurrency: sharing common data,
>> etc.
>
> OK.
>
>> The reason for alloc a NSNumber is to work with the heap vs stack.
>> I'll also be working with C structures as well.
>
> static int wouldn't be on the stack either, FYI. What exactly is the concern
> with heap vs stack? Just experimentation & learning? Or are you looking for
> heap allocation for a specific reason?
>
>> I'm in a learning phase, so I'll expect to 'flutter about' before I can fly.
>
> If you're learning threads, expect to crash & burn a few times ;-)
>
>> BTW: working with static variables - Is it possible to using 'static' within
>> a 'task'; i.e., releasing it BEFORE the end of the application termination?
>>
>> Something like this:
>>
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> ...
>> static NSNumber *myNum = [[NSNumber alloc] initwithInt:0] autorelease]?
>> ...
>> [pool drain];
>
> That code would compile and run, and after the [pool drain] statement you'd
> have a pointer, myNum, to a deallocated NSNumber, which you couldn't (or,
> shouldn't) use for anything. Remember, in that code the *pointer* is static,
> not the object to which it points.
>
> Why do you care about deallocating statics? It's not something that's
> generally useful. Granted, there might be some situation where you want to
> replace a static pointer-to-object with a different pointer, so you'd need to
> release before assigning in order to avoid a leak...
>
> --
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>
>
>
>
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Releasing static variable & concurrent data protection questions...
Frederick C. Lee wrote: 2) Static variables on stack <-- I was aware of this. "Static" and "on stack" are mutually exclusive. It's impossible to have a variable that is both, so "static variables on stack" is nonsense. BTW, the C storage specifier for "on stack" is "auto". You might want to look at a C reference book and learn the difference between the static and auto storage classes. You can have a static pointer that points to a stack (auto) location. This will invariably fail, and is simply wrong on any semantic level. That's because auto lifetime is limited to a function's lifetime; when the function returns all auto variables die. You can have a stack pointer (i.e. auto pointer) that points to a static location. There is nothing inherently wrong with this, unless you're expecting thread-safety. If you intend to perform concurrent calculations, I suggest read-only inputs (sharable without locking), and single-writer outputs (unshared, hence no locking needed). If the outputs must be delivered to a common location, such as a queue, then that (i.e. the queue) can be locked, but only for the duration of queueing the results data. If you employ locking, you can quite easily lose any concurrency gains by having contested locks. Then your threads are spending all their time coordinating access, instead of doing work. -- GG ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSSavePanel panel:shouldShowFilename:
Hello, Something doesn't seem right here. Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey out/de-activate an item in the file browser but the item can still be selected and doing so copies the file name string into the Save As: text field. Is this the expected behaviour? I'd expect that returning NO would prevent the user from selecting that item in any way. Which it does for folders at least. Thanks for any advice, Stephen ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel panel:shouldShowFilename:
On 16/11/2010, at 10:41 AM, Stephen Blinkhorn wrote: > Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey > out/de-activate an item in the file browser but the item can still be > selected and doing so copies the file name string into the Save As: text > field. > > Is this the expected behaviour? I'd expect that returning NO would prevent > the user from selecting that item in any way. Which it does for folders at > least. The SAVE panel always greys out all filenames, since you're not choosing a file, but saving one. As a convenience, it copies the name of anything you click - occasionally this is handy but it is somewhat odd (but clearly intentional) behaviour really. So I suspect that the delegate method is not contributing to the filename situation, only to stop you going into subfolders. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel panel:shouldShowFilename:
On Mon, Nov 15, 2010 at 3:41 PM, Stephen Blinkhorn wrote: > Hello, > > Something doesn't seem right here. > > Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey > out/de-activate an item in the file browser but the item can still be > selected and doing so copies the file name string into the Save As: text > field. > > Is this the expected behaviour? I'd expect that returning NO would prevent > the user from selecting that item in any way. Which it does for folders at > least. Yes. Try it yourself: Open TextEdit, save the document, and then choose Save As. The original location will be there but grayed out. You can still select it and choose to save, and the app will ask you if you want to overwrite the existing file. It doesn't make sense for individual files to be "unsaveable," unlike open dialogs in which it makes perfect sense for files to be "unopenable." So the gray appearance is used to denote that files already exist, while directories remain enabled to indicate navigability. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel panel:shouldShowFilename:
On Nov 15, 2010, at 15:41, Stephen Blinkhorn wrote: > Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey > out/de-activate an item in the file browser but the item can still be > selected and doing so copies the file name string into the Save As: text > field. > > Is this the expected behaviour? I'd expect that returning NO would prevent > the user from selecting that item in any way. Which it does for folders at > least. Graham and Kyle already answered the technical question but, FWIW, I believe there's some marginally interesting history here. It's possible that this delegate method did cause files to be hidden once upon a time (pre Mac OS System 7, at least), but at some point it was decided to show the files that were actually there, disabled, instead. It used to be true (until System 7, 8 or 9, I can't remember which) that clicking on disabled items had no effect. However, a number of system extensions (like Default Folder, but I think that wasn't the first) added the ability to option-click on a disabled item to prefill the text field with an existing name, typically so that you could change it slightly rather than retyping the whole thing. At some point (possibly Mac OS X 10.0), Apple quietly adopted this very useful convention. Note that this method is deprecated in 10.6, and its replacement is called 'panel:shouldEnableURL:' rather than 'panel:shouldShowURL:', but the useful click-to-prefill behavior survives. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel panel:shouldShowFilename:
Thanks for the comprehensive replies. On 15 Nov 2010, at 17:47, Graham Cox wrote: On 16/11/2010, at 10:41 AM, Stephen Blinkhorn wrote: Returning NO for NSSavePanel's panel:shouldShowFilename: delegate will grey out/de-activate an item in the file browser but the item can still be selected and doing so copies the file name string into the Save As: text field. Is this the expected behaviour? I'd expect that returning NO would prevent the user from selecting that item in any way. Which it does for folders at least. The SAVE panel always greys out all filenames, since you're not choosing a file, but saving one. As a convenience, it copies the name of anything you click - occasionally this is handy but it is somewhat odd (but clearly intentional) behaviour really. So I suspect that the delegate method is not contributing to the filename situation, only to stop you going into subfolders. --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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel panel:shouldShowFilename:
On Nov 15, 2010, at 18:48, Erik Buck wrote: > Mac OS 7,8,9 had no delegates at all. Cocoa was introduced with Mac OS X. > Before that, the technology had nothing to do with Mac OS (other than > Rhapsody pre-release and server) and was called Yellow Box. Before that it > was Openstep, and before that NeXTstep. The whole system including Interface > Builder and Objective-C shipped commercially as NeXTstep 0.8 in 1988. Oops, yes, silly of me to have said that about earlier Mac OS. I think what I was trying to say was that there may have been a time when the Save dialog didn't show files, or didn't show all files, (though I don't remember for sure), which might have had something to do with the Mac OS X delegate eventually being designed to control what files were shown. Or maybe not. However, the click-to-prefill thing did precede Cocoa, as a 3rd-party hack. The other thing I forgot to say earlier is that the new 'panel:shouldEnableURL:' method is explicitly documented to be *ignored* for Save panels, which makes more sense in terms of the OP's original question than the older delegate method. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSSavePanel panel:shouldShowFilename:
On 15 Nov 2010, at 22:06, Quincey Morris wrote: The other thing I forgot to say earlier is that the new 'panel:shouldEnableURL:' method is explicitly documented to be *ignored* for Save panels, which makes more sense in terms of the OP's original question than the older delegate method. That makes sense. I think having a delegate called panel:shouldShowFilename: that has no influence over which filenames are shown needed some attention! Perhaps it would make more sense to have implemented this solely in the NSOpenPanel class? Same goes for the new panel:shouldEnableURL: delegate? Stephen ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/stephen.blinkhorn%40audiospillage.com This email sent to stephen.blinkh...@audiospillage.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
