Re: Problem with initialFirstResponder in Gorm

[Germán Arias]

On lun, 2011-02-14 at 22:13 +0100, Wolfgang Lux wrote:
> Germán Arias wrote:
> 
> > Currently, in no document-based apps, the connection in Gorm of the
> > outlet "initialFirstResponder" don't work if the window is  
> > configured to
> > be displayed at launch time. Is necessary call -orderFront: in that
> > window to get the expected behavior. This problem seems to be related
> > with the problem of menu in window in no document-based apps. But the
> > problem with -setInitialFirstResponder occurs with any style of menu  
> > and
> > independently of the windows decoration. And I don't have idea about
> > where is the problem.
> 
> I see you have meanwhile found a solution to your problem (personally,  
> I dislike that code duplication, but I don't have a better solution  
> available). Nevertheless, your problem report here and the commit log  
> message indicate a misunderstanding of the problem that deserve  
> clarification.
> 
> There was nothing wrong with the initialFirstResponder outlet in Gorm.  
> Recall that this outlet describes only the view that is the first  
> responder of a window when it is made visible for the first time.  
> Making a view the initialFirstResponder does not necessarily mean that  
> this view will receive key events when the window becomes visible.

I was accustomed to this behavior, so I thought it was the correct. One
year ago I made a small tutorial to make a simple app on Windows, and I
was accustomed to launch the app and immediately write into a textfield
without use the mouse. But, as you explain, this is not necessarily the
behavior.

> 
> In general, it is also not sufficient to send -orderFront: to a window  
> to make it key window (though it works with many window managers under  
> X because they tend to shift focus to a window when it is ordered  
> front). To reliably make a window key, you should send it - 
> makeKeyAndOrderFront:.
> 
> The situation is a little different when an application is launched,  
> however. If no window was made key explicitly (by sending it - 
> makeKeyAndOrderFront:), the application chooses one of its visible  
> windows to become key. Thus, if you have only one window, sending it - 
> orderFront: is sufficient in this special case. Your problem simply  
> was that due to the obscure logic -- that you rightly removed -- to  
> (ab)use the inactive window list when loading a nib while the  
> application is not active, the application had no visible menu (except  
> for the main menu) when it was looking for a window that could be made  
> key.
> 
> Wolfgang
>