Re: Launched window not activating

FROM : Charilaos Skiadas
DATE : Tue Apr 12 07:06:14 2005

Another idea then: In my case, the controller has in its init method a 
call of the form:
  self = [self initWithWindowNibName:@"Console"];

and then at some point when the window is to appear, after the 
application has finished launching, I have:
[myController showWindow:self];
And it works for me. Are you calling showWindow?
If that doesn't work, then I would consider making a test case, as 
minimal as possible, reproducing the problem, and file a bug report. Do 
you have the same problems even if you do just show the window when the 
notification comes, but strip out all other work that the app is doing 
with the camera etc. It is necessary to determine whether this has 
anything to do with this other camera framework you are using, or if it 
is a pure cocoa problem.
On Apr 11, 2005, at 11:32 PM, Ken Tozier wrote:

>
> On Apr 11, 2005, at 10:13 PM, Charilaos Skiadas wrote:
>

>> Ken,
>>
>> Where from are the cameraNotifications posted?

>
> They come from the ICA (image capture) interface (not my app) so I 
> don't really know what's happening under the hood.
>

>> The method handling them will be running in that same thread that 
>> they were posted on, regardless of in which thread you registered for 
>> the notification, so the downloader methods dealing with the 
>> notifications might actually not be running in the main thread.

>
> I just did a test in the callback handler checking to see if I was 
> multithreaded but it doesn't appear that the ICA stuff is forking a 
> new thread for messages it delivers. I was still single threaded 
> inside the callback.
>

>> In that case, your downloader should be using 
>> performSelectorOnMainThread: for the creation of the window and 
>> bringing it to front, to make sure these operations take place in the 
>> main thread.

>
> OK I tried performSelectorOnMainThread and got basically the same 
> result. The window appears in unactivated form and sending it a 
> "makeKeyAndOrderFront" from within performSelectorOnMainThread doesn't 
> do anything. You can click on it and move it around the screen but it 
> never comes to the front.
>

>> In any case it's a good idea to give it a try this way, and ensure 
>> that all the UI stuff happens in the main thread.
>> This might talk a bit more about the issue:
>> http://cocoa.mamasam.com/MACOSXDEV/2004/02/2/85391.php

>
> Thanks for the link.
>
> Ken
>
>

>>
>> HTH
>> On Apr 11, 2005, at 8:51 PM, Ken Tozier wrote:
>>

>>> Sorry to keep beating this issue, but there is something 
>>> fundamentally wrong somewhere in the following six steps and I'm 
>>> just not experienced enough with Cocoa GUI stuff to see it. To me, 
>>> the algorithm looks fine, but there is some subtle thing that Cocoa 
>>> doesn't like.
>>>
>>> The problem is that the window generated in step 6.A and displayed 
>>> in 6.B is never frontmost and can't even be forced to front by 
>>> clicking on it. The only way to bring it to front is to put the 
>>> window load code inside a thread (which I'm told is bad for GUI 
>>> stuff) Even when it's placed in a thread, it doesn't become 
>>> frontmost without manually clicking on it.
>>>
>>> Anyone see the error?
>>>
>>> Thanks
>>>
>>> Ken
>>>
>>> Sequence of events:
>>> --------------------------------
>>> 1. Application opens "main" nib
>>>
>>> 2. "AppController" instance inside "main" nib initializes it's 
>>> "downloader" instance
>>>
>>>     - (id) init
>>>     {
>>>         self = [super init];
>>>         if (self)
>>>         {
>>>             downloader        = [[ICADownloader alloc] init];
>>>         }
>>>         
>>>         return self;
>>>     }
>>>
>>> 3. Downloader instance registers for camera connect events in it's 
>>> "init" method
>>>
>>>
>>>     - (id) init
>>>     {
>>>         self    = [super init];
>>>         if (self)
>>>         {
>>>             [self registerForCameraConnectNotifications];
>>>         }
>>>         
>>>         return self;
>>>     }
>>>
>>>
>>> 4. Time passes
>>>
>>> 5. User plugs in a camera
>>>
>>> 6. Downloader receives camera connect notification and performs 
>>> following actions:
>>>
>>>     A. Creates a new window by loading the "DownloadWindow" nib file 
>>> using NSWindowController with an owner of "self".
>>>     B. Displays the window.
>>>     C. Downloads photos to a specified directory.
>>>     D. Closes window.
>>>
>>> 7. Done/Waits for another camera connect event.
>>>
>>>
>>> Hierarchically, the location of the window create code is
>>>
>>> App
>>> {
>>>    Main Nib
>>>    {
>>>      AppController
>>>      {
>>>          downloader
>>>          {
>>>            handleCameraConnect <- (callback method)
>>>            {
>>>                NSWindowController    *wind
>>>            }
>>>          }
>>>      }
>>>    }
>>> }
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Cocoa-dev mailing list      (<email_removed>)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/cocoa-dev/
>>> <email_removed>
>>>
>>> This email sent to <email_removed>
>>>
>>>

>> Haris
>>

>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/
> <email_removed>
>
> This email sent to <email_removed>

Haris