|
From: | Lennart Borgman |
Subject: | Re: Q on frame focus with MS Windows |
Date: | Tue, 25 Oct 2005 23:45:38 +0200 |
User-agent: | Mozilla Thunderbird 1.0.7 (Windows/20050923) |
Drew Adams wrote:
I am not sure here, but I dived into the C code to see what might be happening. If I understand this correct (which I am not sure about at all) this happens:What I'm looking for is: 1. To understand this better. Just what is the nature/cause of the problem? 2. A way (workaround) to deal with this problem - something that will keep the input focus in the minibuffer for as long as the minibuffer is active. (So, for instance, if done by redirect-frame-focus, I would want that undone after the minibuffer is inactivated.) 3. If this is a bug in some sense, which could be fixed in Emacs, that would be great. However, I also need this to work in other versions of Emacs, so I would still want the workaround (#2). Any help is appreciated.
1) A frame is created through a call to x-create-frame. 2) This calls x_make_frame_visible3) There is a call to my_show_window with a parameter that is SW_SHOWNORMAL which I guess is later given to the w32 API ShowWindow or something similar.
The documentation for SW_SHOWNORMAL says SW_SHOWNORMAL Activates and displays a window. If the window is minimized or maximized, the system restores it to its original size and position. An application should specify this flag when displaying the window for the first time.I am not sure about what "activates" mean here but I believe it was that it will get the keyboard input focus. And I wonder if the documentation is correct when it sounds that you have to use SW_SHOWNORMAL.
*************** A workaround is maybe to use `after-make-frame-functions'?
[Prev in Thread] | Current Thread | [Next in Thread] |