Re: LSUIElement, NSStatusItem, and NSSearchField
Lee Ann, I have a similar requirement in my apps, and settled on adding a menu item titled “Search”. When user clicks “Search”, the menu disappears and a tiny window with a search field pops up. It would be nice to have a search field in the menu (like the standard “Help” menu does), but as you are finding, navigating between the limitations of NSMenu and the bugs in bringing apps foreground does not leave many alternatives. Don't waste too much time on it. The bugs in bringing apps foreground changed in OS X 10.9. So if you’re supporting 10.8-, be sure to test there too. And, or course, 10.10. ___ 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
LSUIElement, NSStatusItem, and NSSearchField
Questions on this date back to 2003, so I've tried a lot of things. I have an LSUIElement app, with an NSStatusItem and NSSearchField, and I'd much rather be using a menu item with a custom subview rather than showing a window when the status item gets clicked, because there's no way for the menubar to know that it got clicked and so in fullscreen the menubar slides out of the way even though the fake "menu" is still visible. Plus it looks better that way. The first time it runs from Xcode, everything's fine. [NSApp isActive] is true, the menu's window becomes key, search field and everything else accept mouse clicks and key events. Switch to another app and switch back, NSApp is not active, and activateIgnoringOtherApps doesn't do anything no matter where I put it. The menu appears and some mouse events get handled, but the search field doesn't take focus, key strokes dismiss the menu, etc. I did see one suggestion to have the statusItem's click handler call that and then call popUpStatusItemMenu:, that didn't work - the app didn't become active. The suggestion to delay the call to popUpStatusItemMenu until applicationDidBecomeActive sort of worked, but then the status item's menubar highlight got out of sync with the menu actually appearing. What nearly worked was to watch for the menu's window isVisible changing and activate the app then, but I had to click the status item twice to get my menu. ___ 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: Issue with -[NSOutlineView autosaveExpandedItems] - SOLVED
On 7/11/2014, 1:29 PM, "Bill Cheeseman" wrote: > And I've discovered another difficulty, although I think I can handle it. Sounds like it’s time to update Cocoa Recipes to a 3rd edition to fully share these nuggets. -- Gary L. Wade http://www.garywade.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
Re: Issue with -[NSOutlineView autosaveExpandedItems] - SOLVED
On Jul 11, 2014, at 3:10 PM, Lee Ann Rucker wrote: > On Jul 11, 2014, at 5:35 AM, Bill Cheeseman wrote: > >> 4. In -awakeFromNib or equivalent, set up the initial expanded/collapsed >> state of rows in the outline view only once, at first launch on a given >> computer. Thereafter, leave it to the datasource methods to expand or >> collapse the outline view at launch based on the autosaved information from >> a previous run. > > Also, don't use the presence or absence of the autosaved prefs item as an > indicator of whether you've autoexpanded already, because the pref only saves > the array of expanded items and if everything's collapsed, it'll just remove > the pref entirely. Right. And I've discovered another difficulty, although I think I can handle it. When you add, remove or edit a row that is a child of an expanded parent item, AppKit does not automatically call -outlineView:persistentObjectForItem: to update the autosaved data for the parent. Therefore, when you quit and relaunch the application, the new expanded parent item does not match the old expanded parent item autosaved in user defaults, and -outlineView:itemForPersistentObject: does not find a match. As a result, it returns nil and AppKit collapses the parent item on relaunch. The same thing will happen to an edited row if it was expanded before being edited. I think this issue is inherent in the autosave mechanism as Apple has implemented it. One way to handle this might be to collapse and expand the affected row programmatically (and invisibly to the user) in order to trigger the datasource methods. Not elegant, but I think it ought to work. Another way to handle it would be to retrieve the autosaved data when you add, delete or edit an expanded item, add the new data by calling -outlineView:persistentObjectForItem: explicitly, and saving it back to user defaults. I'm half way through doing this now, and it isn't quite as messy as I thought it might be -- but still pretty messy. A third way to handle it would be to go the autosaved UUID route. The autosaved UUIDs would still be correct after quit and relaunch, and you could retrieve the revised items directly from the datasource in your implementation of the -outlineView:itemForPersistentObject: method. The datasource is always up to date by definition, and you would never encounter a mismatch. I fear the third approach might be the best. I hate to have to add a UUID to every item in the datasource, but Apple does provide a Cocoa UUID class to make it easy. Can anybody suggest another approach? It's time for me to quit for the day. -- Bill Cheeseman - b...@cheeseman.name ___ 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: View-based outline view problem
> >On 11 Jul 2014, at 7:44 am, João Varela wrote: > >>Ithas been officially declared by Apple that cell-based NSOutlineView¹s >>and >>NSTableView's are deprecated. > >Would you care to point to where? I'm not arguing, but you wouldn't think >so from the documentation. I see: "NSCell-based tables continue to be >supported in OS X v10.7 and later, but they’re typically used only to >support legacy code." That hints at deprecation at some stage, but I >don't see that it has happened yet. First of all my apologies for not having changed the subject of my first email. You can check that formal declaration in the WWDC 2014 video called “What’s new in Cocoa”. Fast forward to 51:00 and you’ll see that formal declaration. Everything that is NSCell- and NSMatrix-based is deprecated or on its way to formal deprecation. HTH João Varela ___ 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: Issue with -[NSOutlineView autosaveExpandedItems] - SOLVED
On Jul 11, 2014, at 5:35 AM, Bill Cheeseman wrote: > > > 4. In -awakeFromNib or equivalent, set up the initial expanded/collapsed > state of rows in the outline view only once, at first launch on a given > computer. Thereafter, leave it to the datasource methods to expand or > collapse the outline view at launch based on the autosaved information from a > previous run. Also, don't use the presence or absence of the autosaved prefs item as an indicator of whether you've autoexpanded already, because the pref only saves the array of expanded items and if everything's collapsed, it'll just remove the pref entirely. ___ 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: Converting Database to Core Data
On Jul 11, 2014, at 1:34 AM, cocoa-dev-requ...@lists.apple.com wrote: > Message: 2 > Date: Thu, 10 Jul 2014 15:00:32 -0500 > From: William Squires > To: Cocoa Developers > Subject: Converting database to Core Data > Message-ID: > Content-Type: text/plain; charset=us-ascii > > I'm trying to convert the following. I have two tables in a database, > "TransactionEntry", and "ReasonCode". A "TransactionEntry" record is just a > posting from a POS (Point-of-Sale) terminal, and has these fields (of > interest): > > Table (TransactionEntry) > ID As Int32 > PrimaryReasonCode As Int32 // both of these link to .ID > SecondaryReasonCode As Int32 > ... > > and a "ReasonCode" record is used when a certain types of transactions occur, > such as POSItemReturned, POSItemVoided, POSCommError, and a few others. > > Table (ReasonCode) > ID As Int32 > Description As Varchar(50) > ReasonCode As Int16 // just an enum > ... > > All would be good and well if the TransactionEntry table had only one > reference (.PrimaryReasonCode) to the ReasonCode table, but some transactions > (such as a voided item) require the manager to fill in both the primary and > secondary reason codes. I can create the entities, and replace the Int32 > record numbers/IDs with a relationship. > I create the relationship in entity "TransactionEntry" and set it to > "ReasonCode", leaving the inverse relationship to "none" for now. I then > create an inverse relationship in entity "ReasonCode" to refer back to > "TransactionEntry". Now I can create the inverse relationships in both > directions. 1:1 for TransactionEntry -> ReasonCode, and 1:many for ReasonCode > -> TransactionEntry. All okay so far. > Primary ReasonCode records (entities) are re-used to save memory, and the > .Description fields are pre-set to values such as, "return item", "wrong key > hit", "cc reader not working", etc... Secondary ReasonCode entities are > (usually) created on-demand from the POS terminal when the manager logs in. A > few are re-used, but mostly new entities are created. The problem now comes > when I try to create the same relationships from TransactionEntry entities to > ReasonCode entities for the secondary reason code records (entities), since > it won't let me make both inverse relationships 1:many from ReasonCode back > to TransactionEntry. > Is this a limitation of CoreData? Or is there a way around this? Can I > ignore Xcode's warnings about not having inverse relationships, and simply > set the inverse relationships from the TransactionEntry entity(ies) to the > ReasonCode Entity to "none", and simply get rid of the inverse relationships > in the ReasonCode entity? > Please help! :) I think I can see where there is a problem. From the standpoint of your TransactionEntry record, you have two relationships to a secondary table. However, from the standpoint of the secondary table, you have two connections to the SAME object. I can imagine that this would be confusing. Suppose you tried a different approach. Let’s say you create a SINGLE many-many connection between the TransactionEntry table and the ReasonCode table. The primary and secondary reason codes then simply become items in the set of ReasonCodes. On the TransactionEntry side of things, use an OrderedSet, so you can always make the primary reason code the first item… (Theoretically, you could then have MORE than two reason codes, but you could easily prevent that if you didn’t want the feature.) Please note that if you take this approach, you will find that Core Data auto-generates a .h file for the TransactionEntry table that defines methods which don’t exist in Core Data. (This is an old, well-known problem. Google “Core Data Ordered Set”.) You can read more about this problem at http://cypressnorth.com/programming/nsinvalidargumentexception-with-nsorderedsets-using-coredata/ and find a “standard workaround” at https://github.com/CFKevinRef/KCOrderedAccessorFix. (Basically, the CocoaPod just implements the missing methods.) Cheers, Rick Aurbach Aurbach & Associates, Inc. ___ 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: [NSDictionary objectForKey] crash on x64
Hi Bavarious, Thanks a lot for the links and explanation. That was very helpful. ___ 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: View-based outline view problem
In case anyone's following along, I followed Ken's suggestion and made a subclass of NSTextField, and moved my textView:willChangeSelectionFromCharacterRange:toCharacterRange: delegate method there. I also followed Bill's suggestion of overriding becomeFirstResponder so that I could disallow editing of some names. For the editable names I had to include [self selectText:self] before returning YES, or the field rather than the text was selected. I presume I now need to replace outlineView:setObjectValue:forTableColumn:byItem: with an action method triggered by the text field. Thanks for the tips. -- Shane Stanley ___ 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: [NSDictionary objectForKey] crash on x64
On 11 Jul 2014, at 09:56, Cosmin Apreutesei wrote: > Hi, > > I have a strange problem. > > I am using C and the objc runtime on OSX 10.9.3 to get a value from a > NSDictionary. > > The objectForKey method returns an invalid pointer on x64 (not NULL, > but the same address 0x937 for _any_ valid key), but works fine on > i386. > > I attached a small test case to show the problem. > > Here's how to build and run the test case: > > echo "on 32bit works..." > gcc -arch i386 -O2 test5.c -o test5_32 -lobjc > ./test5_32 > > echo "on 64bit crashes..." > gcc -arch x86_64 -O2 test5.c -o test5 -lobjc > ./test5 > > > Any help would be appreciated, even to tell me that you can or can't > reproduce the problem or that you find problems with the code, or to > redirect me to a different forum/mailing list. Since Lion and on 64-bit programs, some NSNumber instances are not represented by full Objective-C objects. Instead, they are represented directly in the (tagged) pointer. I wrote about this when Lion came out: http://objectivistc.tumblr.com/post/7872364181/tagged-pointers-and-fast-pathed-cfnumber-integers-in and Mike Ash also wrote about it: https://www.mikeash.com/pyblog/friday-qa-2012-07-27-lets-build-tagged-pointers.html The layout has changed since then (IIRC type encoding is different now) but, in general, if you get an object pointer whose least significant bit is set (i.e., its integer representation is an odd number), then it’s a tagged pointer. Since the pointer does not point to a valid object, you cannot call an IMP on it directly. You should still be able to use it as the first argument to objc_msgSend(), though. Remember to cast objc_msgSend() to the corresponding function pointer type. For Objective-C questions, you can write to objc-language@lists. ___ 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: [NSDictionary objectForKey] crash on x64
On Jul 11, 2014, at 6:56 AM, Cosmin Apreutesei wrote: > The objectForKey method returns an invalid pointer on x64 (not NULL, > but the same address 0x937 for _any_ valid key), but works fine on > i386. Odds are, your dictionary is no longer there because it was dealloc'd. The fact that you did not (yet, at least) discover this bug on 32-bit is just coincidence. So check out your retain/release/autorelease handling of the dictionary. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[NSDictionary objectForKey] crash on x64
Hi,
I have a strange problem.
I am using C and the objc runtime on OSX 10.9.3 to get a value from a
NSDictionary.
The objectForKey method returns an invalid pointer on x64 (not NULL,
but the same address 0x937 for _any_ valid key), but works fine on
i386.
I attached a small test case to show the problem.
Here's how to build and run the test case:
echo "on 32bit works..."
gcc -arch i386 -O2 test5.c -o test5_32 -lobjc
./test5_32
echo "on 64bit crashes..."
gcc -arch x86_64 -O2 test5.c -o test5 -lobjc
./test5
Any help would be appreciated, even to tell me that you can or can't
reproduce the problem or that you find problems with the code, or to
redirect me to a different forum/mailing list.
Thanks,
Cosmin.
#include
#include
#include
typedef struct objc_class*Class;
typedef struct objc_object *id;
typedef struct objc_method *Method;
typedef struct objc_selector *SEL;
struct objc_class { Class isa; };
struct objc_object { Class isa; };
typedef id (*IMP) (id, SEL, ...);
Class objc_getClass(const char *name);
SEL sel_registerName(const char *str);
Method class_getInstanceMethod(Class aClass, SEL aSelector);
IMP method_getImplementation(Method method);
IMP cimp(const char* clsname, const char* selname) {
Class cls= objc_getClass(clsname) ; assert(cls != 0);
SELsel= sel_registerName(selname) ; assert(sel != 0);
Method method = class_getInstanceMethod(cls->isa, sel) ; assert(method != 0);
IMPimp= method_getImplementation(method) ; assert(imp != 0);
return imp;
}
IMP imp(id obj, const char* selname) {
Class cls= obj->isa ; assert(obj != 0); assert(cls != 0);
SELsel= sel_registerName(selname) ; assert(sel != 0);
Method method = class_getInstanceMethod(cls, sel) ; assert(method != 0);
IMPimp= method_getImplementation(method) ; assert(imp != 0);
return imp;
}
#define callc(clsname, selname, ctype, ...) (((ctype)cimp(clsname, selname)) ((id)objc_getClass(clsname), sel_registerName(selname), __VA_ARGS__))
#define callc0(clsname, selname, ctype) (((ctype)cimp(clsname, selname)) ((id)objc_getClass(clsname), sel_registerName(selname)))
#define call(obj, selname, ctype, ...) (((ctype)imp (obj, selname)) (obj, sel_registerName(selname), __VA_ARGS__))
#define call0(obj, selname, ctype) (((ctype)imp (obj, selname)) (obj, sel_registerName(selname)))
int main() {
setvbuf(stdout, NULL, _IONBF, 0);
dlopen("/System/Library/Frameworks/Foundation.framework/Foundation", RTLD_GLOBAL);
{
//making a NSNumber from scratch works...
id n = callc("NSNumber", "numberWithDouble:", id (*) (id, SEL, double), 12345); //make a NSNumber with value 12345
printf("%p\n", (void*)n); //note the high address
double x = call0(n, "doubleValue", double (*) (id, SEL)); //get back the value
printf("%f\n", x); //12345
}
//but getting a NSNumber from the dictionary below segfaults on 64bit (works on 32bit)...
const char* path = "/System/Library/Frameworks/ApplicationServices.framework/Versions/Current/Frameworks/HIServices.framework/Versions/Current/Resources/cursors/resizenorthwestsoutheast/info.plist";
//create a dictionary from the contents of the info.plist file
id spath = callc("NSString", "stringWithUTF8String:", id (*) (id, SEL, const char*), path); //make a NSString with the value of `path`
id d = callc("NSDictionary", "dictionaryWithContentsOfFile:", id (*) (id, SEL, id), spath); //make a NSDictionary with contents of `path`
//try to get the value of the key "hotx" from that dictionary
id s = callc("NSString", "stringWithUTF8String:", id (*) (id, SEL, const char*), "hotx"); //make a NSString with value "hotx"
id n = call(d, "objectForKey:", id (*) (id, SEL, id), s); //get the value of key "hotx"
printf("%p\n", (void*)n); //note the low address
s = callc("NSString", "stringWithUTF8String:", id (*) (id, SEL, const char*), "hoty"); //make a NSString with value "hoty"
n = call(d, "objectForKey:", id (*) (id, SEL, id), s); //get the value of key "hoty"
printf("%p\n", (void*)n); //note the same low address !!! what's going on here???
double x = call0(n, "doubleValue", double (*) (id, SEL)); //crash, of course...
printf("%f\n", x); //should be 9
return 0;
}
___
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: Issue with -[NSOutlineView autosaveExpandedItems] - SOLVED
On Jul 10, 2014, at 4:20 PM, Bill Cheeseman wrote: > How can I make an outline view reinstate the expanded and collapsed state of > its rows across application launches? I finally realized that older code in my -awakeFromNib method was undoing everything that the datasource method -outlineView:itemForPersistentObject: was doing at application launch. NSLog calls showed me that the datasource method is called at launch BEFORE -awakeFromNib is called. Because I had been populating my datasource and expanding all rows in -awakeFromNib, I was canceling out what the datasource method had done. I would guess that most developers do this in -awakeFromNib, just as I did, because that's how Apple's sample projects do it. I haven't found any sample projects that use these datasource methods, so it didn't matter until I started trying to work them into my project. As soon as I moved the code that populates the datasource into my view controller's designated initializer, and removed that code and the code that expanded the entire outline from -awakeFromNib, everything started working correctly. So here are the basic requirements for setting up autosaveExpandedItems in an outline view: 1. Set autosaveExpandedItems in the outline view nib file or by calling -setAutosaveExpandedItems:YES. (And NSTableView's autosaveName must also be set, which is well documented.) 2. Implement the outline view datasource methods -outlineView:itemForPersistentObject: and -outlineView:objectForPersistentItem: by returning the results from -[NSKeyedArchiver archiveDataWithRootObject:] and -[NSKeyedUnarchiver unarchiveObjectWithData:]. In these methods, it is only necessary to archive the datasource item passed in to -outlineView:objectForPersistentItem:; no other processing is required. AppKit calls this datasource method at the moment you expand or collapse any row in the outline view, adding the archived item to user defaults when you expand it and removing it from user defaults when you collapse it. The autosave user defaults entry is an array of NSData objects constituting the archived datasource items for expanded rows only. The user defaults entry is named "NSOutlineView Items ". When you quit and later relaunch the application, AppKit calls -outlineView:itemForPersistentObject: once for each NSData object in the user defaults autosave entry. It does this before -awakeFromNib, so your datasource must be populated before that (e.g., in the designated initializer) or nothing will happen. Apparently (just guessing here) AppKit compares or subsitutes the unarchived user defaults objects with the datasource contents and expands any and all rows that match. Object-equality only is required, not pointer-identity, because AppKit can handle that issue behind the scenes whether it uses comparison or substitution. (It would seem that you could archive UUIDs or any other kind of unique identifier instead of the datasource item itself in -outlineView:objectForPersistentItem:, as long as you find or reconstruct the datasource item itself and return it in -outlineView:itemForPersistentObject:. This would be the way to go in a Core Data application.) 3. Populate the outline view's datasource in the controller's designated initializer. 4. In -awakeFromNib or equivalent, set up the initial expanded/collapsed state of rows in the outline view only once, at first launch on a given computer. Thereafter, leave it to the datasource methods to expand or collapse the outline view at launch based on the autosaved information from a previous run. So simple. Too bad the reference document doesn't spell this out a little more clearly. (The problem faced by documentation writers is that, if they're any good, they know too much and it all seems perfectly obvious.) -- Bill Cheeseman - b...@cheeseman.name ___ 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: Cocoa-dev Digest, Vol 11, Issue 374
On 11 Jul 2014, at 9:01 pm, Yingshen Yu wrote: > It's in the 10.10 AppKit release notes. Also WWDC session "What's new in > Cocoa" has a fe slides. Thanks. -- Shane Stanley ___ 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: Cocoa-dev Digest, Vol 11, Issue 374
Hi Shane, It's in the 10.10 AppKit release notes. Also WWDC session "What's new in Cocoa" has a fe slides. -Jonny Shane Stanley 于2014年7月11日星期五写道： > On 11 Jul 2014, at 7:44 am, João Varela > wrote: > > > Ithas been officially declared by Apple that cell-based NSOutlineView¹s > and > > NSTableView's are deprecated. > > Would you care to point to where? I'm not arguing, but you wouldn't think > so from the documentation. I see: "NSCell-based tables continue to be > supported in OS X v10.7 and later, but they’re typically used only to > support legacy code." That hints at deprecation at some stage, but I don't > see that it has happened yet. > > -- > Shane Stanley > > > > > ___ > > 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/yingshen.yu%40gmail.com > > This email sent to yingshen...@gmail.com -- Yingshen(Jonny) Yu ___ 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: awakeFromNib multiple objects - all connected?
> On 11 Jul 2014, at 5:33 pm, Uli Kusterer wrote: > > On 06 Jul 2014, at 08:54, Roland King wrote: >> After awakeFromNib all the outlets are connected except for those to >> subviews of the UIViewController's view, they remain nil until after >> viewDidLoad. Other top-level object outlets are connected, but not the view >> nor its subviews. I always felt that broke the awakeFromNib contract; the >> objects are in the NIB, the outlets are in the NIB, surely they should be >> connected at awakeFromNib. > > The contract is that all outlets loaded from the current NIB are connected. > If you have cascading NIB loads, then you get an awakeFromNib call for each > NIB (at least on the Mac, I don’t think I’ve had nested NIBs on iOS in a > while). That means that e.g. a view controller in a NIB will get one > awakeFromNib because the items in the NIB it owns have been loaded and > connected, and then a second one when its parent NIB has finished loading and > it’s been connected to the other items surrounding it. > > Depending on when the inner view controller is asked to provide its view, it > may not have been loaded yet, so obviously there’s nothing to connect to yet. > E.g. if the surrounding NIB calls -view on the view controller in > -awakeFromNib, then of course it is until then that the remaining outlets are > connected. > > I don’t see how that would break any contracts, it is logical. The > alternative would be to somehow violate encapsulation and have an inner > object inform the outer object that it has a NIB that needs loading as well, > and then have it modify the load order and trigger awakeFromNib calls on > objects actually instantiated by its owner and … it would be very messy, at > the latest once you have a view controller inside the NIB of a view > controller inside of the app’s main NIB or whatever. ok so I wrote a test project for this. UIViewController subclass as file’s owner, a UIView subclass for its view, an extra test top-level object at the same level as the view, one button and one label as children of the view. I made the UIViewController subclass have outlets for the top-level object, the button and the label. Both the top-level object and the view had outlets for the button and the label and I hooked them all up. One NIB, all objects, 7 connected outlets. Breakpointing in awakeFromNIB in the view controller and the top-level object showed that the outlets to the button and label were not hooked up, they were nil in both places. The VC was hooked up to the top-level object but that was the only connection which had been made. That appears to violate that all outlets from the current NIB are connected. .. which made me wonder, so I looked at the actual project directory and found .. there are TWO nibs in there. Seems IB evilly splits the viewcontroller piece from the view piece and puts them in their own nibs, along with some extra information to hook the view’s objects in one NIB into the VC’s objects in the other when the view loads (ie hooking the button and label to the top-level object in the first NIB). That probably explains it. The original NIB just contains the VC and object, so awakeFromNIB only shows those two hooked up, the view load is a separate NIB load altogether. That is evil, thanks for the thought about more than one NIB, it make me check to see if my one NIB really was .. one NIB. ___ 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: View-based outline view problem
On Jul 11, 2014, at 2:54 AM, Quincey Morris wrote: > I guess you could solve it with a NSTextField subclass that overrides > becoming first responder. Or is there a more direct solution, do you think? Yes, that's exactly what I do, and it works. Override -[NSResponder becomeFirstResponder]. In fact, I think of that as the most "direct solution." The NSResponder reference document says "Subclasses can override this method to update state or perform some action such as highlighting the selection" The text fields in table and outline views attempt to become first responder when the user left clicks in them. That's wired into AppKit. This is explained somewhere in the documentation, but I forget where. -- Bill Cheeseman - b...@cheeseman.name ___ 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: Issue with -[NSOutlineView autosaveExpandedItems]
On Jul 10, 2014, at 4:57 PM, Ken Thomases wrote: > Are the items that result from unarchiving the persistent object the same > items as your data source returns via -outlineView:child:ofItem:? I believe > they have to be the same by pointer identity, not just equal as by -isEqual:. They are content-equal, but they can't be pointer-identical because I archive them to NSData objects and unarchive them using NSKeyedArchiver and NSKeyedUnarchiver. The reference document comes as close as possible to saying that we're supposed to use NSKeyedArchiver and NSKeyedUnarchiver without quite actually saying so. For example, according to the NSOutlineViewDataSource reference for -outlineView:persistentObjectForItem:, the return value should be "An archived representation of item." If this means we should use NSKeyedArchiver, which I assume it does, then pointer-identity couldn't be a requirement, could it? There is nothing in the reference document to suggest that pointer-identity is required, for what that's worth. My items are standard NSDictionary objects, and I have confirmed that they are properly reconstituted in -outlineView:itemForPersistentObject. > Rather than archiving the item itself, you should perhaps archive uniquely > identifying attributes of the item so that you can find the corresponding > item among the new model and return that. Online discussions of this problem in the past have suggested that archiving unique strings works, and discussions in the Core Data context have suggested that using UUIDs works. But the reference document makes no suggestion that this is required. In fact, just after the quotation above, it goes on to say "If the item is an archived object, this method may return the item." Having to implement UUIDs in my data source for the sole purpose of implementing expand/collapse state survival across application relaunches seems a bit much. I did try calling -outlineView:itemForPersistentObject: myself in -awakeFromNib, matching the unarchived items to their counterparts in the datasource and loading the object from the datasource, and it didn't work. However, that was late in the day yesterday and I may not have gotten it quite right. I'll try again this morning. But this seems counter-intuitive, because I have confirmed that AppKit calls -outlineView:itemForPersistentObject: itself at launch, once for each archived item in user defaults. The documentation does not suggest in any way that I should call it myself, which would be counter to the normal behavior of datasource methods. -- Bill Cheeseman - b...@cheeseman.name ___ 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: View-based outline view problem
On 11 Jul 2014, at 6:37 pm, Ken Thomases wrote: > In general, an NSCell is owned by a control (instance of some subclass of > NSControl). An NSCell uses the field editor, an instance of NSText or a > subclass (usually an NSTextView or subclass, more specifically), to handle > the actual editing. The field editor uses the control which owns the NSCell > as its delegate. That control receives the NSTextViewDelegate and, by > extension, NSTextDelegate method calls. Since an NSTextFieldCell is a kind > of NSCell, all of the above applies to it, too. > > In a cell-based outline view, the outline view is the control owning the > NSTextFieldCell. There's no actual NSTextField. The text view which is the > field editor uses the outline view as its delegate. That's why it gets that > delegate method. > > In your view-based outline view, there's an actual NSTextField (or subclass). > That's a control unto itself. So, it (and not the outline view) serves as > the field editor's delegate. You can use a custom subclass of NSTextField > and it will receive the delegate calls. If you want, you can make your > custom NSTextField forward the text view delegate methods to its own > delegate. So, your custom text field would not need to incorporate the logic > specific to your outline view, it could just be a generic utility class. Ken, Thanks for the detailed explanation. I'll look into this approach. > (I'm a bit surprised that NSTextField doesn't already do this for those > NSText[View]Delegate methods which don't already map to NSControlTextDelegate > or the informal NSControl delegate methods. Have you tried setting your text > field's delegate to your outline view or some appropriate controller?) Yes, I have, but with no joy. -- Shane Stanley ___ 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: awakeFromNib multiple objects - all connected?
On 06 Jul 2014, at 08:54, Roland King wrote: > After awakeFromNib all the outlets are connected except for those to subviews > of the UIViewController's view, they remain nil until after viewDidLoad. > Other top-level object outlets are connected, but not the view nor its > subviews. I always felt that broke the awakeFromNib contract; the objects are > in the NIB, the outlets are in the NIB, surely they should be connected at > awakeFromNib. The contract is that all outlets loaded from the current NIB are connected. If you have cascading NIB loads, then you get an awakeFromNib call for each NIB (at least on the Mac, I don’t think I’ve had nested NIBs on iOS in a while). That means that e.g. a view controller in a NIB will get one awakeFromNib because the items in the NIB it owns have been loaded and connected, and then a second one when its parent NIB has finished loading and it’s been connected to the other items surrounding it. Depending on when the inner view controller is asked to provide its view, it may not have been loaded yet, so obviously there’s nothing to connect to yet. E.g. if the surrounding NIB calls -view on the view controller in -awakeFromNib, then of course it is until then that the remaining outlets are connected. I don’t see how that would break any contracts, it is logical. The alternative would be to somehow violate encapsulation and have an inner object inform the outer object that it has a NIB that needs loading as well, and then have it modify the load order and trigger awakeFromNib calls on objects actually instantiated by its owner and … it would be very messy, at the latest once you have a view controller inside the NIB of a view controller inside of the app’s main NIB or whatever. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: View-based outline view problem
On Jul 11, 2014, at 2:24 AM, Shane Stanley wrote: > FWIW, in my cell-based version I used > textView:willChangeSelectionFromCharacterRange:toCharacterRange: in my > outline view subclass. But that no longer seems to get called. In general, an NSCell is owned by a control (instance of some subclass of NSControl). An NSCell uses the field editor, an instance of NSText or a subclass (usually an NSTextView or subclass, more specifically), to handle the actual editing. The field editor uses the control which owns the NSCell as its delegate. That control receives the NSTextViewDelegate and, by extension, NSTextDelegate method calls. Since an NSTextFieldCell is a kind of NSCell, all of the above applies to it, too. In a cell-based outline view, the outline view is the control owning the NSTextFieldCell. There's no actual NSTextField. The text view which is the field editor uses the outline view as its delegate. That's why it gets that delegate method. In your view-based outline view, there's an actual NSTextField (or subclass). That's a control unto itself. So, it (and not the outline view) serves as the field editor's delegate. You can use a custom subclass of NSTextField and it will receive the delegate calls. If you want, you can make your custom NSTextField forward the text view delegate methods to its own delegate. So, your custom text field would not need to incorporate the logic specific to your outline view, it could just be a generic utility class. (I'm a bit surprised that NSTextField doesn't already do this for those NSText[View]Delegate methods which don't already map to NSControlTextDelegate or the informal NSControl delegate methods. Have you tried setting your text field's delegate to your outline view or some appropriate controller?) 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: View-based outline view problem
On 11 Jul 2014, at 5:44 pm, Quincey Morris wrote: > In such a case, it’s also worth re-considering your UI at a higher level. > > I wonder, for example, whether there’s an alternative that uses *two* text > fields. Put the file name in the ‘textField’ outlet field, and put the > extension in a separate but adjacent field. Use auto-layout to keep both > fields sized to their contents, and to keep the second field immediately > adjacent to the first. If that’s actually possibly, it’ll look like a single > string when not being edited, but will change the UI so that editing of the > pieces is separate. (Or make the extension field uneditable, if you don’t > actually allow it to be changed.) It might even be *better* than the old way. > :) I'm open to all ideas. But I'm essentially trying to mimic what happens in the Finder, where name+extension can be edited as a unit, but not accidentally. I also want to keep some names unable to be edited at all. Your idea also raises the question of what will be selected when the user presses return and there are two text fields. If I understood how that process happened, I might find a better solution. (And auto-layout is down the track for this .xib -- each time I start playing with that conversion, I seem to end up either crashing Xcode or producing an unreadable .xib. So it's one step into the future at a time.) -- Shane Stanley ___ 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: Cocoa-dev Digest, Vol 11, Issue 374
On 11 Jul 2014, at 7:44 am, João Varela wrote: > Ithas been officially declared by Apple that cell-based NSOutlineView¹s and > NSTableView's are deprecated. Would you care to point to where? I'm not arguing, but you wouldn't think so from the documentation. I see: "NSCell-based tables continue to be supported in OS X v10.7 and later, but they’re typically used only to support legacy code." That hints at deprecation at some stage, but I don't see that it has happened yet. -- Shane Stanley ___ 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: View-based outline view problem
On Jul 11, 2014, at 00:24 , Shane Stanley wrote: > Just seems a lot of work for something that doesn't strike me as an uncommon > need. In such a case, it’s also worth re-considering your UI at a higher level. I wonder, for example, whether there’s an alternative that uses *two* text fields. Put the file name in the ‘textField’ outlet field, and put the extension in a separate but adjacent field. Use auto-layout to keep both fields sized to their contents, and to keep the second field immediately adjacent to the first. If that’s actually possibly, it’ll look like a single string when not being edited, but will change the UI so that editing of the pieces is separate. (Or make the extension field uneditable, if you don’t actually allow it to be changed.) It might even be *better* than the old way. :) Something like that. ___ 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: View-based outline view problem
On 11 Jul 2014, at 5:24 pm, Shane Stanley wrote: >> I guess you could solve it with a NSTextField subclass that overrides >> becoming first responder. > > That's all I can think of. Well not quite. I'm already overriding keyDown: in the outline view to show QL previews, so it might be easier to hang it off there. But it seems a bit icky. -- Shane Stanley ___ 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: View-based outline view problem
On 11 Jul 2014, at 4:34 pm, Ken Thomases wrote: > Have you connected the delegate outlet of your text view (field?)? Yes. On 11 Jul 2014, at 4:54 pm, Quincey Morris wrote: > 1. The delegate method ‘control:textShouldBeginEditing:’ seems like it’s > called too late. Presumably the selection change needs to be done when the > text field gets first responder status, not when the text is actually changed. Right, that's what I tried and that's what I'm seeing. > > 2. It’s not obvious to me how the text field gets first responder status. In > the TableViewPlayground sample code, it does, without any apparent support, > so I assume this is something built into NSOutlineView -> NSTableViewCell -> > textField outlet (when you press Return). I don’t know how you’d customize > that if you have a non-standard table cell view. In particular, I don’t see > how you’d know *when* this was happening. FWIW, in my cell-based version I used textView:willChangeSelectionFromCharacterRange:toCharacterRange: in my outline view subclass. But that no longer seems to get called. > I guess you could solve it with a NSTextField subclass that overrides > becoming first responder. That's all I can think of. Just seems a lot of work for something that doesn't strike me as an uncommon need. -- Shane Stanley ___ 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
