> I comment out the two lines
> ;; (load-file "c:/drews-lisp-20/hexrgb.el")
> ;; (load-file "c:/drews-lisp-20/fit-frame.el")
> at the beginning of the file.  I hope they are not needed.

Yes, that was an oversight.  They are not needed at all.

>  > Note: In the file, both of these two lines are necessary, 
>  > to cause the error:
>  > (add-hook 'post-command-hook '1on1-fit-minibuffer-frame)
>  > (setq w32-grab-focus-on-raise    nil)
> 
> Both are in here.

Yes, they are needed.

> With the `post-command-hook' active, focus remains always within the
> Minibuffer frame at the bottom of my screen, whatever silly I 
> type.  The Completions frame is never selected.  So lets hope
> this got fixed.
> 
> I attach a copy of window.el as usual.  If you think that 
> hexrgb and/or fit-frame are needed for showing the bug,
> please tell me so.

(No, those files are not needed.  You can remove those two lines.)

Testing with the latest window.el you just sent, here are the results:


THE GOOD NEWS:

With the last setup we both tried, no bug!  That is: 
runemacs.exe -Q --debug-init -l "window-2011-06-23a-MARTIN.el" -l
"throw-three.el" -f "1on1-emacs"


THE BAD NEWS:

So I pared down again.  The bug happens if you make just this change in the
definition of `1on1-emacs':

Change these lines:

(if 1on1-minibuffer-frame
    (modify-frame-parameters
      1on1-minibuffer-frame
      1on1-minibuffer-frame-alist)
 (setq 1on1-minibuffer-frame
       (make-frame 1on1-minibuffer-frame-alist)))

To these, which is really what I use:

(if 1on1-minibuffer-frame
    (modify-frame-parameters
      1on1-minibuffer-frame
      1on1-minibuffer-frame-alist)
  (setq 1on1-minibuffer-frame
        (let ((after-make-frame-functions  nil))
          (make-frame 1on1-minibuffer-frame-alist))))

IOW, the difference is that `after-make-frame-functions' is bound to nil when
`make-frame' is called.  I do that to inhibit my `fit-frame' from doing
anything.  I have `fit-frame' on `after-make-frame-functions'.

I attached the file - just do as before, using this instead of throw-three.el.

I can try removing just `fit-frame' from that hook and then restoring it.  But I
think I shouldn't have to.  I think that correct behavior should not depend on
`after-make-frame-functions'.  Don't you agree?

Can you please take a look and see why and whether it is necessary that a user
_not_ bind `after-make-frame-functions' to nil here?

Why should `after-make-frame-functions' have any effect on whether keyboard
input for *Completions* gets properly redirected to the minibuffer frame?  You
don't use `after-make-frame-functions' in your code, do you?

If so, that I think is probably a bad idea.  Such hooks should be only for
additional, user etc. things, not for necessary code for vanilla Emacs to work
normally.

Anyway, please let me know what you think.  Give it a try with that `let'
binding (just use the attached file), to confirm that you at least see the same
problem as I.  We can then worry about what to do to fix or work around the
problem.

Again, the problem happens only when the *Completions* is first created.  What
happens on MS Windows is that whenever a frame is created it gets selected (by
the OS/window mgr - there is no way around this).

And for some reason, I guess because of emptying `after-make-frame-functions',
that Windows-frame-selection-on-creation is now also selecting the
window/buffer, and in such a way that keyboard input is not being correctly
redirected to the minibuffer frame.

And as before (since you made some changes a few days ago), things do work
correctly once the *Completions* frame has been created.  If that frame is
already showing and I repeat the recipe (M-x etc.) there is no problem.

And that is true regardless of which frame is selected when I start with M-x:
the *scratch* frame, the minibuffer frame, or even the *Completions* frame.
When I hit M-x, the input is always correctly redirected to the minibuffer
frame, so there is no error saying that *Completions* is read-only.  (Again,
this is when *Completions* was already showing.)

I think (and hope) we are almost there.  Something seems to be preventing the
input-focus redirection just after the *Completions* frame is created, when
`after-make-frame-functions' is nil.

Thx - Drew