Re: Keeping a progress window showing active
Re: Keeping a progress window showing active
- Subject: Re: Keeping a progress window showing active
- From: Graham Cox <email@hidden>
- Date: Tue, 6 Apr 2010 12:35:59 +1000
On 06/04/2010, at 12:03 PM, Quincey Morris wrote:
> On Apr 5, 2010, at 18:31, Graham Cox wrote:
>
>> My app currently needs to show a progress bar during startup (Yes, I know - I'm working on a better solution so this isn't going to be needed at all longer term). The problem I'm having is how to set this up correctly with respect to its active appearance. Other apps generally seem to use a normal modeless dialog type window with the full height title-bar with the name of the app in it. I do that, and also put the window into the 'modal dialog' layer (also tried 'status window' layer).
>
> Maybe you could do something hinky with a custom view that can become first responder in the progress window, and arrange to make the document window main but the progress window key.
I tried adding a non-drawing custom view that is initialFirstResponder, can become FR, and refuses to resign FR, but to no avail. It seems that making another window main/key will happen regardless of whether the existing key window has a view that refuses to resign.
Since I'm otherwise just making use of the standard document-based app opening behaviour, there isn't an easy or obvious way to only make the document window main but not key (seems -makeKeyAndOrderFront: is being called internally at some point). I'll look into that though.
> How many document windows are opening? I wonder if a different approach might make more sense to a user anyway: Display your freestanding progress window *until* the first document window appears. Then get rid of the separate progress window and, as each document window appears (one or more), display a progress sheet on each document window, showing how close *that* document is to being fully open and available. Something along that line.
Generally only one doc opens (just the initial 'untitled' doc) but the progress relates to some global setup that takes a little time to run. This is done in a second thread, so the normal startup happens in parallel. There isn't any lengthy setup per document in this case, though it's a nice idea otherwise.
>> Also, while I'm on the subject, what is the "Non-Activating" checkbox in IB for NSWindow for? It doesn't seem to be listed as one of the flags in the Window Style masks.
>
> It means that clicking on the window when your application is behind other applications brings the window to the front, but leaves the application in the background. (See NSNonactivatingPanelMask -- IDK if there's anything similar that works for NSWindows.)
Ah, right, it's a panel setting rather than a window setting, which is why I didn't see it in Window Style masks. Thanks for the clarification.
--Graham
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden