NSWindow remember whether showing on re-launch
I have a window in my OSX application which shows a log of commands. It's not 'Visible At Launch' because you often don't need to see it. It's also excluded from the windows menu, instead it has its own permanent menu item on that menu which both shows if it's enabled and acts as a menu item to toggle it. All works fine. I want however the window to remember its state and if it was showing when the app was terminated, show on re-start. I can do that with a user default quite easily but figured this has to be a very common task and thought there must be a standard way to accomplish it. Is there? ___ 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: Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
On Fri, Feb 7, 2014, at 04:27 PM, David Delmonte wrote: > Hi, Is there a way to turn secureTextField on and off in Cocoa? I'd like > users to have the option to see their passwords. > In iOS, I can do something like [textField setSecureTextEntry:YES]; > > I found [secureTextField setEchoBullets] but that's not what I want. No. You'll have to swap between instances of NSTextField and NSSecureTextField, keeping the two controls' stringValues in sync. --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
Can I Hide / Show an NSTextField / NSSecureTextField in Cocoa?
Hi, Is there a way to turn secureTextField on and off in Cocoa? I'd like users to have the option to see their passwords. In iOS, I can do something like [textField setSecureTextEntry:YES]; I found [secureTextField setEchoBullets] but that's not what I want. Thanks ___ 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: [NSPointerArray copy] problem
Darn. What about -allObjects? Is that OK on <10.7? I don't care about any NULLs, so that should give me a functional copy. --Graham On 8 Feb 2014, at 9:45 am, Greg Parker wrote: > On Feb 7, 2014, at 4:26 AM, Graham Cox wrote: >> I'm using NSPointerArray to hold a list of weak references. >> >> In one case, I need to enumerate these in a mutation-safe way, so I make a >> copy of the pointer array before iterating it. That works fine on 10.7 and >> later, but on 10.6.x, I get a runtime exception that [NSConcretePointerArray >> copyWithZone:] is abstract*. NSPointerArray documentation says that it >> supports NSCopying and is available from 10.5 and later. Was -copy not >> properly implemented until 10.7? How can I workaround this? > > -[NSPointerArray copyWithZone:] was not implemented until 10.7. The > alternative is to duplicate the contents of the array manually. > > > -- > 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSToolbar delegate -toolbarAllowedItemIdentifiers:
On Feb 7, 2014, at 14:49 , Markus Spoettl wrote: > But apparently its result is ignored because items that are disallowed (by > not returning them in this delegate method) are still visible. It’s a while since I had to suffer through the pain that is NSToolbar delegate methods, but I suspect the problem is that the IB-created items are in a different universe from programmatically created ones. Therefore, in a “mixed” configuration, ‘toolbarAllowedItemIdentifiers:’ is queried only to supply the identifiers of non-IB items that you want to add to the IB-defined toolbar. The delegate method is, after all, optional *in this case*. If that’s correct, and you have a toolbar whose items are allowed in a *contextually* dependent way, you’ll have to create the toolbar contents programmatically — or at least those items. Note that I’m speculating. I vaguely recall that there was something very horrible about mixing IB and non-IB items, and this may or may not be it. ___ 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: NSToolbar delegate -toolbarAllowedItemIdentifiers:
On 2/7/14 11:19 PM, Jerry Krinock wrote:
I’ve never used -toolbarAllowedItemIdentifiers:. However, its documentation
states…
"Sent to discover the allowed item identifiers for a toolbar.”
Wonderful :)) There is no indication of who sends it, when, nor what is done
with the result. The “Discussion” is no more enlightening either. Therefore I
have no idea what the purpose of this method is. Apparently, based on your
results, its purpose is not your purpose.
On 2014 Feb 07, at 13:43, Markus Spoettl wrote:
So the question is: How do I remove an item with a given identifier in such a
way that it does not appear
Here is how I remove toolbar items that are present in nibs…
NSInteger someToolbarItemIndex = [[toolbar items]
indexOfObject:someToolbarItem] ;
if ((someToolbarItemIndex >= 0 ) && (someToolbarItemIndex < [[toolbar items]
count]))
{
[toolbar removeItemAtIndex:settingsToolbarItemIndex] ;
}
where ‘toolbar’ and ‘someToolbarItem’ are outlets, connected in the nib. So a
disadvantage of my method is that you need an outlet for any removable toolbar
item. But I have only have one, and it works for me.
in the customization, neither is single item nor as part of the default toolbar
configuration.
I hope that clause was not important because I don’t understand it.
It is important, I'm afraid. Removing the items from the toolbar is not a
problem. However, I can't get the toolbar to remove them from the customization
sheet.
I thought the whole point of telling the toolbar which of the items are allowed
is that those items will not be shown them during customization (or anywhere
else). The -toolbarAllowedItemIdentifiers: delegate method is called at the
beginning of the customization (before the sheet comes up), that's a hint that
it's used for a purpose that has to do with customization. But apparently its
result is ignored because items that are disallowed (by not returning them in
this delegate method) are still visible.
Regards
Markus
--
__
Markus Spoettl
___
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: [NSPointerArray copy] problem
On Feb 7, 2014, at 4:26 AM, Graham Cox wrote: > I'm using NSPointerArray to hold a list of weak references. > > In one case, I need to enumerate these in a mutation-safe way, so I make a > copy of the pointer array before iterating it. That works fine on 10.7 and > later, but on 10.6.x, I get a runtime exception that [NSConcretePointerArray > copyWithZone:] is abstract*. NSPointerArray documentation says that it > supports NSCopying and is available from 10.5 and later. Was -copy not > properly implemented until 10.7? How can I workaround this? -[NSPointerArray copyWithZone:] was not implemented until 10.7. The alternative is to duplicate the contents of the array manually. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSToolbar delegate -toolbarAllowedItemIdentifiers:
I’ve never used -toolbarAllowedItemIdentifiers:. However, its documentation
states…
"Sent to discover the allowed item identifiers for a toolbar.”
Wonderful :)) There is no indication of who sends it, when, nor what is done
with the result. The “Discussion” is no more enlightening either. Therefore I
have no idea what the purpose of this method is. Apparently, based on your
results, its purpose is not your purpose.
On 2014 Feb 07, at 13:43, Markus Spoettl wrote:
> So the question is: How do I remove an item with a given identifier in such a
> way that it does not appear
Here is how I remove toolbar items that are present in nibs…
NSInteger someToolbarItemIndex = [[toolbar items]
indexOfObject:someToolbarItem] ;
if ((someToolbarItemIndex >= 0 ) && (someToolbarItemIndex < [[toolbar items]
count]))
{
[toolbar removeItemAtIndex:settingsToolbarItemIndex] ;
}
where ‘toolbar’ and ‘someToolbarItem’ are outlets, connected in the nib. So a
disadvantage of my method is that you need an outlet for any removable toolbar
item. But I have only have one, and it works for me.
> in the customization, neither is single item nor as part of the default
> toolbar configuration.
I hope that clause was not important because I don’t understand it.
___
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
Core Data : Synchronizing objects with SQLite file
I’m currently running a Core Data app in Xcode and trying to figure out why an object tells me that the value of its ‘foo’ attribute is nil, but when I query the SQLite file on disk, the value of the ‘ZFOO’ attribute for the problem object is a short string, not nil. There is only one managed object context with this store, and it was created on the main thread. The value of ‘foo’ was pre-existing in the store when the app launched and should not have been changed. The app gives me three indications that foo is nil… • app’s user interface indicates that foo is nil. • Using lldb’s expr command, [problemObject foo] returns nil • Creating a fetch request in lldb, sending -[NSManagedObjectContext executeFetchRequest:error:] returns descriptions of the data for 4 objects as expected; all look good except that the problem object has foo=nil. I’ve also tried in lldb: • -[NSManagedObjectContext save:] • -[NSManagedObjectContext refreshObject:problemObject mergeChanges:YES] • -[NSManagedObjectContext processPendingChanges] All methods executed OK but did not change any of the results. Executing an ‘update’ query with another program upon the SQLite file, I changed a different attribute of the problem object. Upon re-executing the fetch request in lldb, the problem object was now a fault. I then sent [myObject foo], which still returned nil, but this apparently caused the data to be “faulted in”, because a subsequent fetch request in lldb no longer showed a fault, but now showed all of the old data. That is, foo=nil still, and the different attribute was still at its old value. Do I misunderstand how this stuff is supposed to work? Thanks, Jerry ___ 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: NSToolbar delegate -toolbarAllowedItemIdentifiers not getting called, other delegate methods are
On 2/7/14 10:31 PM, Markus Spoettl wrote: Hi, I have a strange problem with a toolbar that is configured in IB which I need to adjust programmatically. It has a delegate set (to the window controller) but for some reason - (NSArray *)toolbarAllowedItemIdentifiers:(NSToolbar*)toolbar is never getting called. Other delegate methods such as - (NSArray *)toolbarDefaultItemIdentifiers:(NSToolbar *)toolbar are getting called. I need to adjust (restrict) the allowed items under certain circumstances and there's no other way to do that. Of course I spoke too soon. It is called, but it doesn't seem to change what NSToolbar is doing. It is called when I open the toolbar customization, but even though I return a restricted set of identifiers, it still presents all items that were set up in IB, not the reduced set of items as it's supposed to present. So the question is: How do I remove an item with a given identifier in such a way that it does not appear in the customization, neither is single item nor as part of the default toolbar configuration. Thanks for any pointers! Regards Markus -- __ Markus Spoettl ___ 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
NSToolbar delegate -toolbarAllowedItemIdentifiers not getting called, other delegate methods are
Hi, I have a strange problem with a toolbar that is configured in IB which I need to adjust programmatically. It has a delegate set (to the window controller) but for some reason - (NSArray *)toolbarAllowedItemIdentifiers:(NSToolbar*)toolbar is never getting called. Other delegate methods such as - (NSArray *)toolbarDefaultItemIdentifiers:(NSToolbar *)toolbar are getting called. I need to adjust (restrict) the allowed items under certain circumstances and there's no other way to do that. Does anyone have an idea what might be wrong? This is with Xcode 4.6.3, OSX 10.7 base SDK, running on Mountain Lion. Regards Markus -- __ Markus Spoettl ___ 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
[NSPointerArray copy] problem
I'm using NSPointerArray to hold a list of weak references. In one case, I need to enumerate these in a mutation-safe way, so I make a copy of the pointer array before iterating it. That works fine on 10.7 and later, but on 10.6.x, I get a runtime exception that [NSConcretePointerArray copyWithZone:] is abstract*. NSPointerArray documentation says that it supports NSCopying and is available from 10.5 and later. Was -copy not properly implemented until 10.7? How can I workaround this? *the error I get literally says: HIToolbox: ignoring exception 'abstract method copyWithZone: called directly on class NSConcretePointerArray' that raised inside Carbon event dispatch. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
