gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with initialFirstResponder in Gorm


From: Wolfgang Lux
Subject: Re: Problem with initialFirstResponder in Gorm
Date: Mon, 14 Feb 2011 22:13:44 +0100

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]