OpenEuphoria

Re: Win32Lib Losing Keys

• Posted by cklester <cklester at yahoo.com> Jul 09, 2004
• 479 views

A discussion occurred:

> > >>   setEnable(PushButton4,False)
> > >>   setFocus(Window1) 
> > >>   setEnable(PushButton4,True)
> > >
> > >I don't understand why setFocus(Window1) doesn't do the job
> > >sufficiently here. However, your suggestion does work for me!
> > Me neither. Maybe Derek can comment?
> 
> When we talk about 'focus' we are talking about *keyboard* focus. That is,
> which element in the display recieves keyboard events. In the Windows
> paradigm, the only elements that normally get focus are those that keyboard
> activity makes sense for. Now, true, this is a bit arbitary but Microsoft,
> and other GUI designs, have decided that it doesn't make sense for the
> parent (background) window to react to keystrokes. So in a nutshell, 
> windows don't get focus but (most other) controls do.
> 
> In Win32lib, when a window gets a 'GotFocus' message, I try to locate the
> child control that last had focus for that window and set the new focus to
> that control, rather than the Window itself (and thus no control in that
> window). This is especially relevant when moving between windows.

Okay, I can see all this more clearly, now. And I'd rather not have to
track what control last had focus if a user clicks away and then clicks
back into my app... so, the way you've set it up is the obvious and
logical way to do it.

> So I put it to the user base of this library: What do you want to happen
> when a Window gets a 'GotFocus' message?

Is there a way to differentiate between

procedure onClick_AButton(...) -- dev code
   -- do something
   setFocus( parentWindow ) -- my internal call
end procedure

and a windows message saying, "The user has returned to your app?"
I'm guessing that's the only other time a window receives a
gotFocus message, right?

Or, perhaps you can have a special function like

   setFocusAndIReallyMeanIt( parentWindow )

-=ck
"Programming in a state of EUPHORIA."