Where are temporary documents stored until saved?
Wow, Googling for this is hard. I've got a problem that prevents me from closing a document in my OS X app. Unfortunately, each time I re-launch, the same docs open, with all the data they contained before. I just want to delete these documents. For that matter, I'd rather they didn't auto-save at all during development (or auto-restore, or whatever the terminology is). I can't figure out where the temporary state is stored so I can delete it before re-launching. Can anyone tell me? Thanks! -- Rick ___ 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: Where are temporary documents stored until saved?
Nevermind, I found it. ~/Library/Autosave Information/ On Dec 30, 2012, at 2:56 , Rick Mann wrote: > Wow, Googling for this is hard. > > I've got a problem that prevents me from closing a document in my OS X app. > Unfortunately, each time I re-launch, the same docs open, with all the data > they contained before. I just want to delete these documents. For that > matter, I'd rather they didn't auto-save at all during development (or > auto-restore, or whatever the terminology is). > > I can't figure out where the temporary state is stored so I can delete it > before re-launching. Can anyone tell me? > > Thanks! > > -- > Rick > > > > > ___ > > 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/rmann%40latencyzero.com > > This email sent to rm...@latencyzero.com -- Rick ___ 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: Where are temporary documents stored until saved?
Il giorno 30/dic/2012, alle ore 12:07, Rick Mann ha scritto: >> they contained before. I just want to delete these documents. For that >> matter, I'd rather they didn't auto-save at all during development (or >> auto-restore, or whatever the terminology is). so why don't you just disable auto-saving, maybe with an option so you can switch it off only on your development machine? Check the "Autosaving" methods in NSDocument: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/nsdocument_Class/Reference/Reference.html -- Simone Tellini http://tellini.info ___ 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
Visualised constraint colours
Hi What do the colours mean when visualised by calling -visualizeConstraints: ? My working layout has 4 blue constraints but my broken layout has 2 blue and 2 red but all 4 of those constraints seem incorrect (although they're the same constraints as the working layout) so I don't want to assume blue == good, red == bad Iain ___ 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: Bound NSTextField displays Selection Placeholder instead of Null Placeholder
On Dec 29, 2012, at 3:16 PM, Quincey Morris wrote: > Well, I have part of the answer. I think there are 2 bugs, though it's not > entirely clear. > > AFAICT, the reason it's showing the No Selection placeholder is roundabout. > It *isn't* displaying the No Selection placeholder as a result of the > binding. It's actually displaying the Placeholder String of the *text field* > (when you delete the contents after there's initially been something there), > but when you originally created the binding Xcode changed the Placeholder > String in the text field to the No Selection string from the binding. At > least, that's what happened to me. > > This appears to be a bug in Xcode, and it only happened when I first > established the binding. After that, playing with the binding placeholders > didn't have any effect on the text field Placeholder String. (However, Xcode > did crash dramatically one time, right after I changed a binding placeholder > and tried to select the text field. That seems relevant.) I am not sure I am experiencing this bug, if I understand you correctly. I can change the binding placeholder string and the bug will show the new changed placeholder string. Changing the text field placeholder string, however, does not appear to have any effect. > The second bug (I think) is that the field editor displays the text field > Placeholder String at first (i.e. when you delete the contents after there's > initially been something there), but the appropriate binding placeholder at > other times. I still suspect this is a timing issue with NIB loading, where > the text field caches the placeholder it's going to tell the field editor to > use before it's seen that there's going to be a binding that supplies a > different placeholder. > > The workaround for the first bug (which would make the second bug moot) is to > change the text field Placeholder String to match the binding's Null > placeholder. Of course, that means you'll still have to go in and edit (or at > least check) each text field in Xcode. > > I dunno about a workaround for the second bug (which would make the first > one moot, I suppose). Perhaps if your could arrange to re-set the text field > to its initial value after the window has been displayed, the field editor > problem would go away. Or perhaps you'd have to to set it to the empty string > or nil, before you re-set it to the correct thing. Or perhaps you'd have to > re-set it before the field editor is created. This seems to be the issue. Watching NSTextFieldCell shows that when the xib is first loaded the cell's placeholder string is set to the "no selection" placeholder, which certainly might be the case depending on when the binding is established and queried, but never updated when the controller's state changes until after the editor has committed edited. Curiously, even if I change to where the controller content is set well after nib loading, the same behavior occurs, so I am inclined to think my problem is a timing issue with nib loading, but the fact that the appropriate placeholder is never updated until the first edit. Looks like I am back to setting the binding placeholder for every field Thanks for all your help! Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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: Where are temporary documents stored until saved?
On Dec 30, 2012, at 3:18 AM, Simone Tellini wrote: > > Il giorno 30/dic/2012, alle ore 12:07, Rick Mann ha > scritto: > >>> they contained before. I just want to delete these documents. For that >>> matter, I'd rather they didn't auto-save at all during development (or >>> auto-restore, or whatever the terminology is). > > > so why don't you just disable auto-saving, maybe with an option so you can > switch it off only on your development machine? That *drastically* changes NSDocument's behavior. It would not be a good idea to disable this during development as you might unwittingly introduce bugs that only manifest when autosaving is enabled. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Finder Source List Icons
Thanks to all … and Happy New Year !
-koko
On Dec 29, 2012, at 11:36 PM, Charles Srstka wrote:
> On Dec 29, 2012, at 10:46 PM, koko wrote:
>
>> Are the icons in the Finders Source List available to developer apps or does
>> the developer have to capture and photoshop them?
>
> The icons for the items that are currently in the source list can be obtained
> like this:
>
> LSSharedFileListRef list = LSSharedFileListCreate(kCFAllocatorDefault,
> kLSSharedFileListFavoriteItems, NULL);
> NSArray *items = CFBridgingRelease(LSSharedFileListCopySnapshot(list, NULL));
>
> for (id eachItem in items) {
>IconRef iconRef = LSSharedFileListItemCopyIconRef((__bridge
> LSSharedFileListItemRef)eachItem);
>NSImage *iconImage = [[NSImage alloc] initWithIconRef:iconRef];
>
>// do something with the image
> }
>
> CFRelease(list);
>
> Charles
>
>
___
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: Where are temporary documents stored until saved?
You can turn this off for your debug runs using: Product > Edit Scheme... > Run > Options > Persistent State: Launch app without state restoration Joar On 30 dec 2012, at 02:56, Rick Mann wrote: > Wow, Googling for this is hard. > > I've got a problem that prevents me from closing a document in my OS X app. > Unfortunately, each time I re-launch, the same docs open, with all the data > they contained before. I just want to delete these documents. For that > matter, I'd rather they didn't auto-save at all during development (or > auto-restore, or whatever the terminology is). > > I can't figure out where the temporary state is stored so I can delete it > before re-launching. Can anyone tell me? > > Thanks! > > -- > Rick > > > > > ___ > > 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/joar%40joar.com > > This email sent to j...@joar.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: Where are temporary documents stored until saved?
Oh that's perfect! Sent from my iPhone On Dec 30, 2012, at 9:51, Joar Wingfors wrote: > You can turn this off for your debug runs using: > >Product > Edit Scheme... > Run > Options > Persistent State: Launch app > without state restoration > > Joar > > > On 30 dec 2012, at 02:56, Rick Mann wrote: > >> Wow, Googling for this is hard. >> >> I've got a problem that prevents me from closing a document in my OS X app. >> Unfortunately, each time I re-launch, the same docs open, with all the data >> they contained before. I just want to delete these documents. For that >> matter, I'd rather they didn't auto-save at all during development (or >> auto-restore, or whatever the terminology is). >> >> I can't figure out where the temporary state is stored so I can delete it >> before re-launching. Can anyone tell me? >> >> Thanks! >> >> -- >> Rick >> >> >> >> >> ___ >> >> 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/joar%40joar.com >> >> This email sent to j...@joar.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: Finder Source List Icons
On Dec 30, 2012, at 12:36 AM, Charles Srstka wrote:
> LSSharedFileListRef list = LSSharedFileListCreate(kCFAllocatorDefault,
> kLSSharedFileListFavoriteItems, NULL);
> NSArray *items = CFBridgingRelease(LSSharedFileListCopySnapshot(list, NULL));
>
> for (id eachItem in items) {
>IconRef iconRef = LSSharedFileListItemCopyIconRef((__bridge
> LSSharedFileListItemRef)eachItem);
>NSImage *iconImage = [[NSImage alloc] initWithIconRef:iconRef];
>
>// do something with the image
> }
>
> CFRelease(list);
Actually, here's a correction; looking at this again, I should have released
the IconRef after creating the NSImage:
ReleaseIconRef(iconRef);
Otherwise, memory will leak. Sorry about that!
Charles
___
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
BAse localisation and strings files compatibility with 10.7
I'm considering moving (part of) an existing project to using a base localisation, with nibs only for the base language, and strings files to localise for other languages. I can't find in the documentation whether this feature is compatible with 10.7. I think it is, but I'm not sure, and can't find any confirmation on it in Apple's docs nor generally on the web. I need this app to remain compatible with 10.7. Can I safely move to using base localisation and strings files to localise nibs? -António They deem me mad because I will not sell my days for gold; And I deem them mad because they think my days have a price. --Kahlil Gibran --- ___ 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: "New" busy cursor in the Finder
On Dec 20, 2012, at 2:30 PM, Eric Schlegel wrote: > > On Dec 19, 2012, at 8:03 PM, lordpi...@mac.com wrote: > >> I noticed recently that the Finder has a "new" very nice looking animated >> busy cursor, which you can see here: >> https://dl.dropbox.com/u/45534011/BusyCursor.png [snip] > > You're actually seeing the cursor in Finder (and other apps) when opening a > menu that requires a significant amount of time to open or render (which the > "Open…" menu item often does). Menus in OS X apps (both Carbon and Cocoa) are > still implemented using the Carbon Menu Manager, which accesses this cursor > via the Carbon API SetAnimatedThemeCursor. > > I don't believe there's currently any NSCursor API for accessing this cursor; > a Radar would be appropriate. Thanks. I have filed a RADAR: RADAR: rdar://12939978 OPEN RADAR: http://openradar.appspot.com/radar?id=2489401 AndyT (lordpixel - the cat who walks through walls) A little bigger on the inside (see you later space cowboy, you can't take the sky from me) ___ 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
Binding NSTableView columns to dynamic properties in Core Data?
I'm not sure if this is possible with bindings and Core Data, or how much glue code I'm going to have to write to do this, but I thought I'd ask to see if anyone else has done anything like this. I want to display a table view with a set of columns that's not known at compile time, but rather at run time. The model has one entity for the rows, and related key-value pair entities for each column in the row. These are generated at run time based on the input data, but they are the same for all rows in a set. Each column may be of a different type than the other, but all the entries in a column are the same. I suspect I'll have to programmatically build the table columns each time the set changes (not quite sure how to do that, but I assume there are obvious methods for adding and removing columns). Once I'm building the columns, I expect I'd have to programmatically bind them to an NSArrayController. Not sure how I map a key name in a table column through the NSArrayController to my main entity, and through that to the related key-value pair entity. Override the primary entity's valueForKey and have it fetch the related property? Any caveats I should look out for? Suggestions and advice welcome. Thanks! -- Rick ___ 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: Binding NSTableView columns to dynamic properties in Core Data?
On Dec 30, 2012, at 8:35 PM, Rick Mann wrote: > I'm not sure if this is possible with bindings and Core Data, or how much > glue code I'm going to have to write to do this, but I thought I'd ask to see > if anyone else has done anything like this. > > I want to display a table view with a set of columns that's not known at > compile time, but rather at run time. The model has one entity for the rows, > and related key-value pair entities for each column in the row. These are > generated at run time based on the input data, but they are the same for all > rows in a set. Each column may be of a different type than the other, but all > the entries in a column are the same. > > I suspect I'll have to programmatically build the table columns each time the > set changes (not quite sure how to do that, but I assume there are obvious > methods for adding and removing columns). Once I'm building the columns, I > expect I'd have to programmatically bind them to an NSArrayController. Not > sure how I map a key name in a table column through the NSArrayController to > my main entity, and through that to the related key-value pair entity. > Override the primary entity's valueForKey and have it fetch the related > property? Any caveats I should look out for? It seems to me that the amount of work involved in maintaining the bindings would be more troublesome than simply using data source methods. You would also have much more control as well. I have done basically what you are thinking in the way of a simple database querying UI, where the results would be loaded into a table whose columns are dynamically created to match the columns of a SQL "select" query. Data source is the way to go. Note, however, that you don't get all of the "free" behavior that NSArrayController gives you for adding objects (especially undo) nor the "free" stuff you get from bindings for cell editing. But it's not hard to code and the managed object context will still maintain undo for you. I still think the build up/tear down of bindings will be more of a pain and more fragile in any case. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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: Binding NSTableView columns to dynamic properties in Core Data?
On Dec 30, 2012, at 20:08 , Keary Suska wrote: > It seems to me that the amount of work involved in maintaining the bindings > would be more troublesome than simply using data source methods. You would > also have much more control as well. I have done basically what you are > thinking in the way of a simple database querying UI, where the results would > be loaded into a table whose columns are dynamically created to match the > columns of a SQL "select" query. Data source is the way to go. > > Note, however, that you don't get all of the "free" behavior that > NSArrayController gives you for adding objects (especially undo) nor the > "free" stuff you get from bindings for cell editing. But it's not hard to > code and the managed object context will still maintain undo for you. I still > think the build up/tear down of bindings will be more of a pain and more > fragile in any case. Great considerations. Given that the data really isn't intended to be editable (at least, not in the first release), and the user can't add or delete rows, perhaps you're right, and the data source is the way to go. I have a related table that displays details about the row selected, and that, I think, can still be done with Bindings. -- Rick ___ 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: Bound NSTextField displays Selection Placeholder instead of Null Placeholder
On Dec 30, 2012, at 07:59 , Keary Suska wrote: > I am not sure I am experiencing this bug, if I understand you correctly. I > can change the binding placeholder string and the bug will show the new > changed placeholder string. Changing the text field placeholder string, > however, does not appear to have any effect. If you saw an incorrect placeholder "No selection", I'm saying, then you saw it because Xcode incorrectly put that string the text field Placeholder String at some point in the past. It's got nothing actually to do with a NSController selection, except perhaps in Xcode's fevered imagination. However, Xcode doesn't do this routinely. It only happened to me the first time I established a binding for text field newly added to the XIB, then never again. It's presumably dependent on the order of things in the XIB and/or the history of what was changed. > Looks like I am back to setting the binding placeholder for every field AFAIK you always had to do this. The binding placeholder fields in IB are by default *empty* (though in some cases they *display* gray IB placeholder text to indicate what you would put there if you chose to use the fields), so you would have had to go through once entering binding placeholder strings. Because of the [apparent] field editor bug, you'd be faced with also setting the text field Placeholder string for every field as well. So, yes, to work around the problem this way, you do have to edit every field. I wonder, though, what happens if you set the placeholder string directly, after the NIB has loaded. It's a property of the text field cell. Maybe you'd need to set it on the text field cell, or maybe you'd need to set it on the field editor cell. ___ 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
