1. Win32Lib Losing Keys
Can somebody please help me with this problem? Run the code below.
Type anything. You'll see the result in the statusbar. Now click the
button. Try typing again. No KeyPress response.
You can try setting the onClick event for the button to setFocus(Window1)
but it still won't work. How do I make the button lose focus again so
the Window can receive key events? Or should I go about this difrerently?
Thanks!!!
-- code generated by Win32Lib IDE v0.18.14
include Win32Lib.ew
without warning
--------------------------------------------------------------------------------
-- Window Window1
constant Window1 = createEx( Window, "Window1", 0, Default, Default, 434, 352,
0, 0 )
constant StatusBar2 = createEx( StatusBar, "StatusBar2", Window1, 0, 0, 0, 0, 0,
0 )
constant PushButton4 = createEx( PushButton, "PushButton4", Window1, 96, 124,
88, 28, 0, 0 )
---------------------------------------------------------
--------------------------------------------------------------------------------
procedure Window1_onKeyPress (integer self, integer event, sequence
params)--params is ( int keyCode, int shift )
setText(StatusBar2, "Got key " & params[1] & "." )
end procedure
setHandler( Window1, w32HKeyPress, routine_id("Window1_onKeyPress"))
WinMain( Window1,Normal )
-=ck
"Programming in a state of EUPHORIA."
2. Re: Win32Lib Losing Keys
cklester wrote:
>
> Can somebody please help me with this problem? Run the code below.
> Type anything. You'll see the result in the statusbar. Now click the
> button. Try typing again. No KeyPress response.
>
> You can try setting the onClick event for the button to setFocus(Window1)
> but it still won't work. How do I make the button lose focus again so
> the Window can receive key events? Or should I go about this difrerently?
It all depends on what you are trying to achieve. Is it really important that
you react to the Window, rather than *any* other control, getting a key
event?
My guess is that you wish to do something when a certain key is pressed,
regardless of which control currently has focus. If that is so,
trying using
setHandler(Screen, w32HKeyDown, ...)
this will trap all key presses, regardless of which control currently
has focus. If you need to know which control has focus, call the
getSelf() function inside the Screen-event handler.
> Thanks!!!
>
> -- code generated by Win32Lib IDE v0.18.14
>
> include Win32Lib.ew
> without warning
>
>
> --------------------------------------------------------------------------------
> -- Window Window1
> constant Window1 = createEx( Window, "Window1", 0, Default, Default, 434, 352,
> 0, 0
> )
> constant StatusBar2 = createEx( StatusBar, "StatusBar2", Window1, 0, 0, 0, 0,
> 0, 0
> )
> constant PushButton4 = createEx( PushButton, "PushButton4", Window1, 96, 124,
> 88, 28,
> 0, 0 )
> ---------------------------------------------------------
>
> --------------------------------------------------------------------------------
> procedure Window1_onKeyPress (integer self, integer event, sequence
> params)--params
> is ( int keyCode, int shift )
> setText(StatusBar2, "Got key " & params[1] & "." )
> end procedure
> setHandler( Window1, w32HKeyPress, routine_id("Window1_onKeyPress"))
>
> WinMain( Window1,Normal )
>
> -=ck
> "Programming in a state of EUPHORIA."
>
--
Derek Parnell
Melbourne, Australia
3. Re: Win32Lib Losing Keys
Derek Parnell wrote:
>
> cklester wrote:
> >
> > Can somebody please help me with this problem? Run the code below.
> > Type anything. You'll see the result in the statusbar. Now click the
> > button. Try typing again. No KeyPress response.
> >
> It all depends on what you are trying to achieve. Is it really important that
> you react to the Window, rather than *any* other control, getting a key
> event?
Well, press the space bar after clicking the button. It's important
that the spacebar not push the button.
> My guess is that you wish to do something when a certain key is pressed,
> regardless of which control currently has focus. If that is so,
> trying using
>
> setHandler(Screen, w32HKeyDown, ...)
>
> this will trap all key presses, regardless of which control currently
> has focus. If you need to know which control has focus, call the
> getSelf() function inside the Screen-event handler.
How do I prevent the spacebar from clicking the button?
The following code sets the event handler to the Screen... but after
clicking the button, pressing the spacebar still clicks it. That's
bad behavior.
-- code generated by Win32Lib IDE v0.18.14
include Win32Lib.ew
without warning
--------------------------------------------------------------------------------
-- Window Window1
constant Window1 = createEx( Window, "Window1", 0, Default, Default, 434, 352,
0, 0)
constant StatusBar2 = createEx( StatusBar, "StatusBar2", Window1, 0, 0, 0, 0, 0,
0)
constant PushButton4 = createEx( PushButton, "PushButton4", Window1, 96, 124,
88, 28,0, 0 )
---------------------------------------------------------
--------------------------------------------------------------------------------
procedure Window1_onKeyPress (integer self, integer event, sequence
params)--params is ( int keyCode, int shift )
setText(StatusBar2, "Got key " & params[1] & "." )
end procedure
setHandler( Screen, w32HKeyPress, routine_id("Window1_onKeyPress"))
WinMain( Window1,Normal )
4. Re: Win32Lib Losing Keys
On Wed, 07 Jul 2004 18:49:40 -0700
cklester <guest at RapidEuphoria.com> wrote:
>
>
> posted by: cklester <cklester at yahoo.com>
>
> Derek Parnell wrote:
> >
> > cklester wrote:
> > >
> > > Can somebody please help me with this problem? Run the code below.
> > > Type anything. You'll see the result in the statusbar. Now click the
> > > button. Try typing again. No KeyPress response.
> > >
> > It all depends on what you are trying to achieve. Is it really important
> > that
> > you react to the Window, rather than *any* other control, getting a key
> > event?
>
> Well, press the space bar after clicking the button. It's important
> that the spacebar not push the button.
>
> > My guess is that you wish to do something when a certain key is pressed,
> > regardless of which control currently has focus. If that is so,
> > trying using
> >
> > setHandler(Screen, w32HKeyDown, ...)
> >
> > this will trap all key presses, regardless of which control currently
> > has focus. If you need to know which control has focus, call the
> > getSelf() function inside the Screen-event handler.
>
> How do I prevent the spacebar from clicking the button?
>
> The following code sets the event handler to the Screen... but after
> clicking the button, pressing the spacebar still clicks it. That's
> bad behavior.
>
> -- code generated by Win32Lib IDE v0.18.14
>
> include Win32Lib.ew
> without warning
>
>
> --------------------------------------------------------------------------------
> -- Window Window1
> constant Window1 = createEx( Window, "Window1", 0, Default, Default, 434, 352,
> 0, 0)
> constant StatusBar2 = createEx( StatusBar, "StatusBar2", Window1, 0, 0, 0, 0,
> 0, 0)
> constant PushButton4 = createEx( PushButton, "PushButton4", Window1, 96, 124,
> 88, 28,0, 0 )
> ---------------------------------------------------------
>
> --------------------------------------------------------------------------------
> procedure Window1_onKeyPress (integer self, integer event, sequence
> params)--params is ( int keyCode, int shift )
> setText(StatusBar2, "Got key " & params[1] & "." )
> end procedure
> setHandler( Screen, w32HKeyPress, routine_id("Window1_onKeyPress"))
>
> WinMain( Window1,Normal )
To avoid the space bar hit you must returnValue(-1) in that procedure if my
memory doesn't fail...
5. Re: Win32Lib Losing Keys
Guillermo Bonvehi wrote:
> To avoid the space bar hit you must returnValue(-1) in that procedure if my
> memory
> doesn't fail...
Nope. Didn't work for me. Spacebar still clicks the button.
(I tried both returnValue(0) and returnValue(-1).)
-=ck
"Programming in a state of EUPHORIA."
6. Re: Win32Lib Losing Keys
cklester wrote:
>
> Derek Parnell wrote:
> >
> > cklester wrote:
> > >
> > > Can somebody please help me with this problem? Run the code below.
> > > Type anything. You'll see the result in the statusbar. Now click the
> > > button. Try typing again. No KeyPress response.
> > >
> > It all depends on what you are trying to achieve. Is it really important
> > that
> > you react to the Window, rather than *any* other control, getting a key
> > event?
>
> Well, press the space bar after clicking the button. It's important
> that the spacebar not push the button.
>
> > My guess is that you wish to do something when a certain key is pressed,
> > regardless of which control currently has focus. If that is so,
> > trying using
> >
> > setHandler(Screen, w32HKeyDown, ...)
> >
> > this will trap all key presses, regardless of which control currently
> > has focus. If you need to know which control has focus, call the
> > getSelf() function inside the Screen-event handler.
>
> How do I prevent the spacebar from clicking the button?
>
> The following code sets the event handler to the Screen... but after
> clicking the button, pressing the spacebar still clicks it. That's
> bad behavior.
>
> -- code generated by Win32Lib IDE v0.18.14
>
> include Win32Lib.ew
> without warning
>
>
> --------------------------------------------------------------------------------
> -- Window Window1
> constant Window1 = createEx( Window, "Window1", 0, Default, Default, 434, 352,
> 0, 0)
> constant StatusBar2 = createEx( StatusBar, "StatusBar2", Window1, 0, 0, 0, 0,
> 0, 0)
> constant PushButton4 = createEx( PushButton, "PushButton4", Window1, 96, 124,
> 88, 28,0,
> 0 )
> ---------------------------------------------------------
>
> --------------------------------------------------------------------------------
> procedure Window1_onKeyPress (integer self, integer event, sequence
> params)--params
> is ( int keyCode, int shift )
> setText(StatusBar2, "Got key " & params[1] & "." )
> end procedure
> setHandler( Screen, w32HKeyPress, routine_id("Window1_onKeyPress"))
>
> WinMain( Window1,Normal )
You can put this patch into win32lib...
If the routine called 'fDoKeys', move down till you find
these lines...
elsif iMsg = WM_KEYDOWN then
if length(lUserReturn) >= 2 then
if equal(lUserReturn[1], w32KH_SetFocus) then
lNewFocus = lUserReturn[2]
end if
end if
Then insert these lines between the two 'end if' lines in the
above code...
elsif lUserReturn[1] = -1 then
-- Ignore this keystroke
lRC = {kMainMsg}
Finally, do this in your application code...
procedure PushButton4_onKeyDown (integer self, integer event, sequence
params)--params is ( int keyCode, int shift )
if params[1] = ' ' then
returnValue(-1)
end if
end procedure
setHandler( PushButton4, {w32HKeyDown}, routine_id("PushButton4_onKeyDown"))
--
Derek Parnell
Melbourne, Australia
7. Re: Win32Lib Losing Keys
Derek Parnell wrote:
> >
> > How do I prevent the spacebar from clicking the button?
> >
>
> You can put this patch into win32lib...
What if I have multiple buttons/controls? Do I need to define
a KeyDown routine for each and every control that could possibly
be affected by a spacebar?
-=ck
"Programming in a state of EUPHORIA."
8. Re: Win32Lib Losing Keys
cklester wrote:
>
> Derek Parnell wrote:
>
> > >
> > > How do I prevent the spacebar from clicking the button?
> > >
> >
> > You can put this patch into win32lib...
>
> What if I have multiple buttons/controls? Do I need to define
> a KeyDown routine for each and every control that could possibly
> be affected by a spacebar?
Look, I don't know what your application is supposed to do here, so I'm
guessing and reacting to your specific questions. You only asked about
ignoring the spacebar for ONE button. Anyhow...
It all depends! Do you have ANY controls that you want the spacebar to
work in? If so, the the answer to your latest question is YES. This is
not so big a deal to do though. For example...
sequence SkipBars
SkipBars = {
Btn1, Btn3, Btn15, Fld2, Checkbox44, ... you get the idea...}
procedure Skip_the_spacebar(integer self, integer event, sequence parms)
if parms[1] = ' ' then
returnValue(-1)
end if
end procedure
setHandler(SkipBars, w32HKeyDown, routine_id("Skip_the_spacebar"))
Viola! That's it.
If you don't want ANY control to react to the spacebar then do this...
procedure Skip_the_spacebar(integer self, integer event, sequence parms)
if parms[1] = ' ' then
returnValue(-1)
end if
end procedure
setHandler(Screen, w32HKeyDown, routine_id("Skip_the_spacebar"))
Or if you have a dynamic situation in which the controls that can
react, changes over time ...
sequence SkipBars
SkipBars = {
Btn1, Btn3, Btn15, Fld2, Checkbox44, ... you get the idea...}
procedure Skip_the_spacebar(integer self, integer event, sequence parms)
if parms[1] = ' ' and find(getSelf(), SkipBars) then
returnValue(-1)
end if
end procedure
setHandler(Screen, w32HKeyDown, routine_id("Skip_the_spacebar"))
What is the real problem you are trying to solve? Or to put it another
way, what is the real effect you are trying to achieve?
--
Derek Parnell
Melbourne, Australia
9. Re: Win32Lib Losing Keys
I couldn't remember this last night, or where I've used it, but I did
this morning, so my apologies - Derek has meantime suggested a bunch
of changes to win32lib which I am studiously ignoring 
The following trick will allow the user to deliberately tab to a
control and press space to click it, but then the button loses focus
and 'normal' keyboard handling resumes, which is probably better than
an outright ban on space activating a button.
To be honest, the spacebar both activates the button AND appears on
the statusbar, so a further small tweak may be required.
procedure Window1_onKeyPress (integer self, integer event, sequence
params)--params is ( int keyCode, int shift )
setText(StatusBar2, "Got key " & params[1] & "." )
if self=PushButton4 then
setEnable(PushButton4,False)
setFocus(Window1)
setEnable(PushButton4,True)
end if
end procedure
setHandler( {Window1,PushButton4}, w32HKeyPress,
routine_id("Window1_onKeyPress"))
integer numclicks
numclicks=0
procedure PushButton4Click(integer self, integer event, sequence
params)
numclicks+=1
setText(Window1,sprint(numclicks))
setEnable(PushButton4,False)
setFocus(Window1)
setEnable(PushButton4,True)
end procedure
setHandler(PushButton4,w32HClick,routine_id("PushButton4Click"))
10. Re: Win32Lib Losing Keys
Derek Parnell wrote:
> cklester wrote:
> >
> > What if I have multiple buttons/controls? Do I need to define
> > a KeyDown routine for each and every control that could possibly
> > be affected by a spacebar?
>
> If you don't want ANY control to react to the spacebar then do this...
>
> procedure Skip_the_spacebar(integer self, integer event, sequence parms)
> if parms[1] = ' ' then
> returnValue(-1)
> end if
> end procedure
> setHandler(Screen, w32HKeyDown, routine_id("Skip_the_spacebar"))
That doesn't work. The SPACEBAR keypress still causes the button
to click. I even tried the following, which
doesn't allow any kepress to go through, yet the button still gets
clicked with the spacebar.
procedure Window1_onKeyPress (integer self, integer event, sequence
params)--params is ( int keyCode, int shift )
setText(StatusBar2, "Got key " & params[1] & "." )
returnValue(-1)
end procedure
setHandler( Screen, w32HKeyDown, routine_id("Window1_onKeyPress"))
> What is the real problem you are trying to solve?
Being able to press the spacebar without having a recently clicked
button react to it.
> Or to put it another
> way, what is the real effect you are trying to achieve?
When the user types, I'm using wPuts() to put it to a part of the
window. They can click buttons to do other things, but when they
start typing again, I expect to be able to receive those events and
wPuts() them to the window again. But it doesn't work that way, yet. :)
> Derek Parnell
Thanks, Derek!
-=ck
"Programming in a state of EUPHORIA."
11. Re: Win32Lib Losing Keys
Pete Lomax wrote:
>
> The following trick will allow the user to deliberately tab to a
> control and press space to click it, but then the button loses focus
> and 'normal' keyboard handling resumes, which is probably better than
> an outright ban on space activating a button.
>
> To be honest, the spacebar both activates the button AND appears on
> the statusbar, so a further small tweak may be required.
>
> procedure Window1_onKeyPress (integer self, integer event, sequence
> params)--params is ( int keyCode, int shift )
> setText(StatusBar2, "Got key " & params[1] & "." )
> if self=PushButton4 then
> 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!
> end if
> end procedure
> setHandler( {Window1,PushButton4}, w32HKeyPress,
> routine_id("Window1_onKeyPress"))
Using setHandler(Screen,...) works fine.
-=ck
"Programming in a state of EUPHORIA."
12. Re: Win32Lib Losing Keys
cklester wrote:
>
> Derek Parnell wrote:
> > cklester wrote:
> > >
> > > What if I have multiple buttons/controls? Do I need to define
> > > a KeyDown routine for each and every control that could possibly
> > > be affected by a spacebar?
> >
> > If you don't want ANY control to react to the spacebar then do this...
> >
> > procedure Skip_the_spacebar(integer self, integer event, sequence parms)
> > if parms[1] = ' ' then
> > returnValue(-1)
> > end if
> > end procedure
> > setHandler(Screen, w32HKeyDown, routine_id("Skip_the_spacebar"))
>
> That doesn't work. The SPACEBAR keypress still causes the button
> to click. I even tried the following, which
> doesn't allow any kepress to go through, yet the button still gets
> clicked with the spacebar.
You did put in that patch I mentioned, didn't you? It won't work
without that patch. It does work here with the patch installed.
>
> procedure Window1_onKeyPress (integer self, integer event, sequence
> params)--params
> is ( int keyCode, int shift )
> setText(StatusBar2, "Got key " & params[1] & "." )
> returnValue(-1)
> end procedure
> setHandler( Screen, w32HKeyDown, routine_id("Window1_onKeyPress"))
>
> > What is the real problem you are trying to solve?
>
> Being able to press the spacebar without having a recently clicked
> button react to it.
By 'recently' do you actually mean the most recent button that was clicked?
Or any button that was click in the last 'x' seconds?
If it just the last button clicked, then on the Click event, place this
button's id in the SkipBar sequence, and use the Screen keydown to
check the getSelf() returns that same id, if so ignore the spacebar
for it. Dead simple.
> > Or to put it another
> > way, what is the real effect you are trying to achieve?
>
> When the user types, I'm using wPuts() to put it to a part of the
> window. They can click buttons to do other things, but when they
> start typing again, I expect to be able to receive those events and
> wPuts() them to the window again. But it doesn't work that way, yet. :)
Arhhh...so if a button has focus, and you start getting keystrokes, you
wish to 'pretend' that its the Window that actually has focus.
--
Derek Parnell
Melbourne, Australia
13. Re: Win32Lib Losing Keys
On Thu, 08 Jul 2004 08:41:07 -0700, cklester <guest at RapidEuphoria.com>
wrote:
>> 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?
Regards,
Pete
14. Re: Win32Lib Losing Keys
Pete Lomax wrote:
>
> On Thu, 08 Jul 2004 08:41:07 -0700, cklester <guest at RapidEuphoria.com>
> wrote:
>
> >> 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 in 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.
So I put it to the user base of this library: What do you want to happen
when a Window gets a 'GotFocus' message?
--
Derek Parnell
Melbourne, Australia
15. Re: Win32Lib Losing Keys
On Thu, 08 Jul 2004 16:53:05 -0700, Derek Parnell
<guest at RapidEuphoria.com> wrote:
>When we talk about 'focus' we are talking about *keyboard* focus. That is,
<sound of penny dropping>
>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,
<sound of krugerrand dropping>
>and other GUI designs, have decided that in 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.
There are many apps which do not rely on a traditional windows
control. Of course, for me, MEditor springs to mind. Most games, and
indeed Word and Internet Explorer fall into the same category.
>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.
>
>So I put it to the user base of this library: What do you want to happen
>when a Window gets a 'GotFocus' message?
Perhaps this is the wrong question. Why are we programmers trying to
setFocus(Window)? Is there a more natural way to express the intent,
such as
create(Hidden,....)
or
create(Virtual,...)
Regards,
Pete
16. Re: Win32Lib Losing Keys
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."
17. Re: Win32Lib Losing Keys
If you remove the WS_TABSTOP-style from a button, I think it doesn't get focus
anymore when clicked. That way, the control that had focus (your editor) will
keep focus when clicking a button.
I'm not sure about this, but I think it's worth a try.
--
tommy online: http://users.pandora.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
