[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with initialFirstResponder in Gorm
From: |
Germán Arias |
Subject: |
Re: Problem with initialFirstResponder in Gorm |
Date: |
Mon, 14 Feb 2011 18:32:20 -0600 |
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
>