Re: makeKeyAndOrderFront (not working)
On 14.04.2013, at 20:20, Pax 45rpmli...@googlemail.com wrote: [[NSApplication sharedApplication] activateIgnoringOtherApps : YES]; Thanks for the suggestion. If it breaks something else I'll be sure you let you know. Cool, it'd be appreciated! Cheers, -- Uli Kusterer http://stacksmith.org ___ 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: Followup - Re: Is there a pattern for creating an object with global scope?
On 15 Apr 2013, at 00:25, Graham Cox graham@bigpond.com wrote: On 14/04/2013, at 2:08 PM, YT y...@redwoodcontent.com wrote: My struggle is partially due to my lack of experience in OOP. I just have not written enough OO code as of yet. AND I'm very new to Objective-C. Hence my lack of experience and working knowledge of Objective-C. extern int gFoobar; I understand that solution and its working for me right now. I understand how tempting it is to go with whatever you can get working, especially when you're new to something. But in this case I believe you should resist the temptation and try and gain a little more understanding before you get too far down this road. GLOBALS ARE BAD NEWS. That is a pretty good rule and well worth sticking to. If you can get rid of globals (and you always can) then you should avoid them. There is NO problem in application programming that requires a global to solve it. Singletons are a much safer and more predictable means of achieving something that has global scope but prevents the hidden state/parameters problem that globals bring with them. Wow, I really can't get my head around this one. You make bold statements like GLOBALS ARE BAD NEWS (which I 100% agree with), but then follow up with effectively use singletons instead. Singletons bring with them 95% of the problems globals bring. They still break any attempts at threading, they still break any attempts at testing, they still break separation of concerns, and they're always avoidable. So I'd follow up with SINGLETONS ARE BAD NEWS TOO! In 95% of cases where you have a singleton, you should almost certainly be using dependancy injection instead, or some other method of avoiding it. Note also – simply using your app delegate as a store for things that aren't singletons, but only one of them is pointed at by your app delegate is also horrific – you're just substituting one singleton for another. Thanks Tom Davie ___ 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: UITableCellView width decreases when scrolling
On Apr 15, 2013, at 12:01 AM, Glenn L. Austin gl...@austin-soft.com wrote: You can't have the full 320 pixels in width and still have the disclosure indicator. Well, you can, but you won't be happy with the result (and likely won't get it past Apple's reviewers). I see, thanks. It doesn't have to be 320, 300 is fine too, as long as it doesn't change when I scroll the table. I'll make the subView 300 wide and see what happens. - Koen. ___ 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: UITableCellView width decreases when scrolling
On Apr 15, 2013, at 1:27 AM, Luke Hiesterman luket...@apple.com wrote: In general, if you want to put custom stuff in a cell, you should do it by adding views - like labels, image views, etc. Only if you find a scrolling performance problem and only if via profiling analysis you can show that the performance problem is related to having too many views should you think about flattening the view hierarchy by using -drawRect. If you stick to this strategy your life will likely be much simpler. The reason I was using drawRect is that my cell contains some text, plus a small graph (a few changing lines, so I cannot use an static image) at the bottom. Therefore I was using CoreGraphics, and I decided then to also draw the strings that way. Even if I use labels for the strings (which I agree is much easier and customizable), then I still would need a subview for the bottom half of my contentView to draw in the graph. Unless there is another solution? - Koen. ___ 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: Core Data grinds for 30 min saving SQLite. 10.6 Bug?
On Apr 14, 2013, at 6:25 PM, Jerry Krinock je...@ieee.org wrote: Has anyone ever seen any behavior like this? (More data follows below.) Yes. I haven't checked to see if this was addressed in later cats, but I did notice that CoreData is a memory hog in Snow Leopard. Specifically, it allocates up to twice the size of the managed object when updating or deleting (!) the object, so if you have an object that is a few hundred megabytes in size and the process is running in 32-bit mode, then it may not be able to update/delete the object. Nick Zitzmann http://www.chronosnet.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: Core Data grinds for 30 min saving SQLite. 10.6 Bug?
On 2013 Apr 15, at 10:54, Nick Zitzmann n...@chronosnet.com wrote: Yes. I haven't checked to see if this was addressed in later cats, but I did notice that CoreData is a memory hog in Snow Leopard. Specifically, it allocates up to twice the size of the managed object when updating or deleting (!) the object, so if you have an object that is a few hundred megabytes in size and the process is running in 32-bit mode, then it may not be able to update/delete the object. Thank you, Nick. These are some interesting clues. But there must be something else going on in this case, because this store contains only several dozen small objects. The size of the .sql file, before and after saving, is only 112 KB. ___ 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: Restoring unsaved docs does wrong thing
On Apr 12, 2013, at 16:16:53, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
You can just override autosavesInPlace to return NO, to turn off the new
behavior.
It's also possible that just overriding autosavesDrafts to return NO might
disable the untitled document behavior, if that's all you need, but the
drafts behavior is a bit hard to follow from the documentation.
I don't see an autosavesDrafts method anywhere. Ah, I just found it in
NSDocument. Strange that searching for that term in the help window didn't find
it.
I have the following overrides in my NSDocument subclass:
+(BOOL) preservesVersions
{
return NO;
}
+(BOOL) autosavesDrafts
{
return NO;
}
- (BOOL)hasUnautosavedChanges
{
// We don't do Cocoa autosaving - we do our own:
return NO;
}
- (NSString*)autosavingFileType
{
// Another way to prevent Cocoa's autosaving:
return nil;
}
Note in my original message I said kill not quit. I meant if I kill the app
from the debugger or force quit. In this case, if I had an dirty untitled
document open, the system will create new empty documents when I launch again.
How can I prevent this? The data was never saved anywhere, so opening a new
document is the wrong thing for the OS to do. The stack is shown below. I don't
see any method I can override to prevent this. I could install my own event
handler for kAEOpenApplication, but I don't know everything the default handler
does for this event, so I'd probably lose lots of standard behavior, and it
seems like overkill.
#0 0x027b237a in -[FCMacDocumentController
openUntitledDocumentAndDisplay:error:]
#1 0x99ed1998 in -[NSDocumentController
_openUntitledDocumentOfType:andDisplay:error:] ()
#2 0x99ed9834 in -[NSDocumentController
_restorePersistentDocumentWithState:completionHandler:] ()
#3 0x99eda17c in __block_global_27 ()
#4 0x99ed1ea6 in -[NSDocumentController
_waitForAsyncOpeningOrPrintingToFinishThenContinue:] ()
#5 0x99ed9ea3 in __76+[NSDocumentController
restoreWindowWithIdentifier:state:completionHandler:]_block_invoke_0 ()
#6 0x99b7cfee in -[NSApplication _whenReopeningIsAllowedDo:] ()
#7 0x99ed9dec in +[NSDocumentController
restoreWindowWithIdentifier:state:completionHandler:] ()
#8 0x99ac641d in -[NSApplication(NSPersistentUISupport)
restoreWindowWithIdentifier:state:completionHandler:] ()
#9 0x99ac5d3a in -[NSApplication(NSPersistentUISupport)
_restoreWindowWithRestoration:handler:] ()
#10 0x99ac48cd in -[NSPersistentUIManager
restoreAllPersistentStateRegisteringAsReadyWhenDone:completionHandler:] ()
#11 0x99b7af28 in -[NSApplication
_reopenWindowsAsNecessaryIncludingRestorableState:registeringAsReady:completionHandler:]
()
#12 0x99b7adf5 in -[NSApplication(NSAppleEventHandling)
_reopenWindowsIfNecessaryWithAppleEvent:completionHandler:] ()
#13 0x99b7acfa in -[NSApplication(NSAppleEventHandling)
_handleAEOpenEvent:] ()
#14 0x99b7a824 in -[NSApplication(NSAppleEventHandling)
_handleCoreEvent:withReplyEvent:] ()
#15 0x915b1628 in -[NSObject performSelector:withObject:withObject:] ()
#16 0x92f2c73a in __76-[NSAppleEventManager
setEventHandler:andSelector:forEventClass:andEventID:]_block_invoke_0 ()
#17 0x92f2c291 in -[NSAppleEventManager
dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
#18 0x92f2c08e in _NSAppleEventManagerGenericHandler ()
#19 0x90523a35 in aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned
long, unsigned char*) ()
#20 0x904f8fbe in dispatchEventAndSendReply(AEDesc const*, AEDesc*) ()
#21 0x904f8e7d in aeProcessAppleEvent ()
#22 0x90170c58 in AEProcessAppleEvent ()
#23 0x99b76d4d in _DPSNextEvent ()
#24 0x99b761dc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#25 0x99b6c63c in -[NSApplication run] ()
#26 0x99b0f666 in NSApplicationMain ()
#27 0x01309368 in main
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
___
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: Restoring unsaved docs does wrong thing
On Apr 15, 2013, at 4:49 PM, Steve Mills smi...@makemusic.com wrote: I don't see an autosavesDrafts method anywhere. Ah, I just found it in NSDocument. Strange that searching for that term in the help window didn't find it. It might be that your Xcode doc window is searching the 10.7 docset. The autosavesDrafts method is 10.8-only. In the search field in Xcode doc window, hit the little magnifying glass and select Show Find Options. There will be a Find in popup menu showing which docsets are being searched. --Andy ___ 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: Restoring unsaved docs does wrong thing
Hi Steve, On Apr 12, 2013, at 1:10 PM, Steve Mills smi...@makemusic.com wrote: If I have an unsaved doc open in my app (I mean one that has never been saved to disk), and I kill the app, upon relaunch, the OS attempts to restore that document, but it does so incorrectly. First of all, the data was never saved by the new Cocoa autosaving mechanism (we have our own and must use it for now). Second, it creates a new untitled doc by calling our document controller's openUntitledDocumentAndDisplay method. Why would it do that? A new untitled doc with nothing in it has *nothing* to do with what might've been an untitled doc with user changes in it. If the app unexpectedly crashed or was killed, the system will make a best-effort to restore state. If the document was never saved, the best it can do is recreate an Untitled document. Also, what should I be overriding and returning in my document subclass to ensure that the OS autosaving never happens and prevent it from trying to create new docs on launch like this? You can mark a window as not restorable in the xib, or by calling [window setRestorable:NO] Hope that helps, -Peter ___ 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: Restoring unsaved docs does wrong thing
On Apr 15, 2013, at 16:06:51, Andy Lee ag...@mac.com wrote: On Apr 15, 2013, at 4:49 PM, Steve Mills smi...@makemusic.com wrote: I don't see an autosavesDrafts method anywhere. Ah, I just found it in NSDocument. Strange that searching for that term in the help window didn't find it. It might be that your Xcode doc window is searching the 10.7 docset. The autosavesDrafts method is 10.8-only. Ah, that explains it. Thanks. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: Restoring unsaved docs does wrong thing
On Apr 15, 2013, at 13:49 , Steve Mills smi...@makemusic.com wrote: I have the following overrides in my NSDocument subclass: […] You didn't mention autosavesInPlace. This is the one to override if you don't want any (new-style) autosaving. The data was never saved anywhere, so opening a new document is the wrong thing for the OS to do. No, that's not true when autosavesInPlace is YES. In that case, if the app has a window open when it quits, it should and will open a window when it re-starts. If autosave has never completed, it'll be a new, untitled window. Having said that, things get a bit more complicated when you kill the app during debugging. It's a bit unpredictable what restorable state has been saved, and whether it'll successfully restore. You can turn off the Launch application without state restoration option in the Run action of the scheme, which make help you out during debugging, though that of course won't prevent the behavior in normal usage for your users. ___ 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: Core Data grinds for 30 min saving SQLite. 10.6 Bug?
On Apr 15, 2013, at 2:22 PM, Jerry Krinock je...@ieee.org wrote: Yes. I haven't checked to see if this was addressed in later cats, but I did notice that CoreData is a memory hog in Snow Leopard. Specifically, it allocates up to twice the size of the managed object when updating or deleting (!) the object, so if you have an object that is a few hundred megabytes in size and the process is running in 32-bit mode, then it may not be able to update/delete the object. Thank you, Nick. These are some interesting clues. But there must be something else going on in this case, because this store contains only several dozen small objects. The size of the .sql file, before and after saving, is only 112 KB. Okay, that's pretty bizarre and I haven't seen that happen before. I don't suppose your user could use Instruments' object allocation instrument to figure out what's going on…? That would require installing Xcode from the App Store. Nick Zitzmann http://www.chronosnet.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: makeKeyAndOrderFront (not working)
On Apr 15, 2013, at 3:36 AM, Uli Kusterer wrote: On 14.04.2013, at 20:20, Pax 45rpmli...@googlemail.com wrote: [[NSApplication sharedApplication] activateIgnoringOtherApps : YES]; Thanks for the suggestion. If it breaks something else I'll be sure you let you know. Cool, it'd be appreciated! We've been doing that for years now in Fusion for the stub apps that represent Windows apps in a virtual machine, some of which are UIElement=YES, and nothing's broken so far :) ___ 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: Core Data grinds for 30 min saving SQLite. 10.6 Bug?
On 2013 Apr 15, at 14:20, Nick Zitzmann n...@chronosnet.com wrote: Okay, that's pretty bizarre and I haven't seen that happen before. I don't suppose your user could use Instruments' object allocation instrument to figure out what's going on…? Oh, I don't need the user. I've reproduced the problem on an old Mac Mini that actually has some Xcode 3.x installed on it. I do recall, though, that performance usually made Instruments unusable on that Mac. The timeline would advance at about 1/10 real time or something like that. The Sample I pasted in to the bottom of my original post indicates clearly that Core Data is going crazy. Could Instruments give me any more useful information than that? It would be worth a Technical Support Incident if I could get Apple to confirm that this is their bug in 10.6, but I think DTS would probably reject any incident which required them to actually fire up a 10.6 Mac. ___ 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: Followup - Re: Is there a pattern for creating an object with global scope?
On 15/04/2013, at 8:44 PM, Tom Davie tom.da...@gmail.com wrote: Wow, I really can't get my head around this one. You make bold statements like GLOBALS ARE BAD NEWS (which I 100% agree with), but then follow up with effectively use singletons instead. Singletons bring with them 95% of the problems globals bring. They still break any attempts at threading, they still break any attempts at testing, they still break separation of concerns, and they're always avoidable. So I'd follow up with SINGLETONS ARE BAD NEWS TOO! In 95% of cases where you have a singleton, you should almost certainly be using dependancy injection instead, or some other method of avoiding it. Note also – simply using your app delegate as a store for things that aren't singletons, but only one of them is pointed at by your app delegate is also horrific – you're just substituting one singleton for another. I'm not suggesting you use singletons all over the place, but judicious use of singletons is a reasonable and straightforward way to solve the global scope problem without directly using globals. Sometimes you need something with global scope, and the OP's use-case of preferences is a common example. Other things are a natural fit too, such as NSApplication. I agree that they can bring many of the same problems with them, but some of the things you mention are not inherently a problem with singletons as long as you're aware of the issues. Threading for example, is easily taken care of. Are they a solution for every situation? No, I'm not suggesting they are, but I don't think they bring 95% of the same problems as globals. I don't know what you mean by dependency injection, it's not a term I've heard of, but it's like anything - there are good and correct solutions to a problem and there are others which work but are non-optimal. The craftsman needs to be aware of the tools at his disposal and use the appropriate one for the task at hand. Globals are never required, singletons occasionally. Something else altogether usually. --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
Re: Followup - Re: Is there a pattern for creating an object with global scope?
On 16/04/2013, at 10:18 AM, Graham Cox graham@bigpond.com wrote: I don't know what you mean by dependency injection, it's not a term I've heard of OK, I looked it up. I hadn't heard the term but I'm very familiar with the concept it refers to. Sometimes the service or dependent entity should be a singleton... I don't see that it's a substitutable solution, but one orthogonal to the existence of singletons. --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
Re: Followup - Re: Is there a pattern for creating an object with global scope?
On 15.04.2013, at 12:44, Tom Davie tom.da...@gmail.com wrote: Note also – simply using your app delegate as a store for things that aren't singletons, but only one of them is pointed at by your app delegate is also horrific – you're just substituting one singleton for another. If it were only that! At least singletons only pull in dependencies from their problem domain into any module that uses them. If you instead implement them in the app delegate, all that code not only bloats the app delegate, its dependencies also make all these singletons recompile whenever only one of them changes. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.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
