>>
APLDN Home

>>
Events

>>
Trainings

>>
APL Books

>>
APLDN Links

>>
Discussion Groups

>>
Downloads

>>
Articles

>>
Library

>>
Learning Tools

>>
APLDN User IO

>>
APL2000.com




Problem Resolution

Author Thread: Missing Call-back on Enter
Richard.Hill
Missing Call-back on Enter
Posted: Friday, December 24, 2004 2:36 AM (EST)
A control is created which has an on-key function, or a hidden menu. These need to be activated when the user hits an enter key. There is a problem with this that I have previously reported, in that the Enter key is not recognised, the first time it is hit. The reply was that this is a Microsoft bug. Up till now we have lived with it, but I am asking if anyone has experienced it also and has developed a good workaround. Richard Hill


Comments:

Author Thread:
davin.church
Missing Call-back on Enter
Posted: Saturday, January 01, 2005 12:20 PM (EST)
If you're using onKeyPress, have you tried switching to onKeyUp instead?

     

Support
Missing Call-back on Enter
Posted: Monday, January 03, 2005 3:45 PM (EST)
Richard, what you've reported isn't familiar to us here at APL2000 Support.  When did you report it and to whom?  It might help if you were to provide a sample code.  Post it here or send it to support@apl2000.com.

APL2000 Support

     

Richard.Hill
Missing Call-back on Enter
Posted: Monday, January 03, 2005 7:40 PM (EST)
Using onKeyDown and onKeyUp for the various different keys supported by each. Am also trying the hidden menu approach.

     

Richard.Hill
Missing Call-back on Enter
Posted: Tuesday, January 04, 2005 9:51 PM (EST)
Cannot find the original example. It is hard to simplify the problem to show exactly what is happening, but the following shows a related problem, and I think the actual problem is caused by the programmer attempting to work around the following. If you run the little function Test and you click the OK with the mouse, then the warg result is different to the case if you respond to the OK with Enter. {del} [0]Test ;form;edit [1]Wmsg 'test' 0 [2]form{assign} 'test' {quad}wi 'Create' 'Form' [3]edit{assign} 'test.ed' {quad}wi 'Create' 'Edit' [4]edit {quad}wi 'onKeyUp' '{quad}warg' [5]form {quad}wi 'Wait' {del} Richard Hill

     

davin.church
Missing Call-back on Enter
Posted: Tuesday, January 04, 2005 10:35 PM (EST)

FYI -- Did you know that hitting Enter on a default button acts very differently in Windows than clicking on that button.  For one thing, the button never gets the focus from Enter (which I've had to work around in many places).

 

Of course, that's on a Button and not an Edit box.  (And did I miss seeing an OK Button in your example?)

     

Richard.Hill
Missing Call-back on Enter
Posted: Wednesday, January 05, 2005 7:23 PM (EST)
Davin, I think that you have shown the problem. the OK button shows up from the [1] Wmsg'test' 0 in the test function. (sorry, the editor on this machine doesnt seem to allow the user to break or set a new line, so the function appeared garbled) It would be good if you could share your preferred work around. Richard Hill

     

davin.church
Missing Call-back on Enter
Posted: Monday, January 10, 2005 11:50 AM (EST)

I'm not very pleased with my solution, but at least it works adequately.  What I do is change the button's onClick handler to call a refocusing routine.  So if the handler would normally call something like:

      DoButton

it instead invokes:

      CheckFocus 'DoButton'

and the CheckFocus function forces the focus to change (if possible) before running the handler.  My CheckFocus function is shown below.  (There are non-displayed {equivalent} symbols in the locations of ...me='#'...)

 

    ’ CheckFocus handler;me
[1]   © This routine is called from an onClick handler and passed the
[2]   © name of the true handler function to be executed.
[3]   © It's purpose is to make sure that onExit has been run before
[4]   © proceeding, and to abort the onClick procedure if the result of
[5]   © onExit is the detection & notification of an error.  This might
[6]   © occur because onExit is not necessarily called prior to an onClick
[7]   © in some circumstances (e.g. pressing Enter for the default button).
[8]   ©
[9]   © Syntax (in context):
[10]  ©   ... Œwi 'onClick' 'CheckFocus ''onClickHandlerFunction'''
[11]
[12]  me„Œwself © Make sure the focus is on me (or my parentage)
[13]  :while ~(›'Focus')¹me Œwi 'events' ª me„ParentOf me ª :endwhile
[14]
[15]  :if me­'#' Œwi 'focus' © Am I the currently focused object?
[16]      –handler © Yep - go ahead and run the handler
[17]  :else
[18]      © Force the focus to myself first, running previous field's onExit
[19]      me Œwi 'Focus' © Trigger refocusing
[20]      © Now, let's check to see if I _stayed_ focused on myself
[21]      :if me­'#' Œwi 'focus' © Am I still the current object?
[22]          –handler © Yep - now we can run the handler
[23]      :else
[24]          © No!  Skip execution of the handler!
[25]      :endif
[26]  :endif
    ’

 

I hope you find it useful.

 

     

Support
Missing Call-back on Enter
Posted: Friday, January 14, 2005 2:54 PM (EST)

Richard,


You will be pleased to learn that I successfully located the prior messages between us that you alluded to earlier pertaining to this matter.  The two messages date back to September 6, 2000 and are shown below (between the *s) for everyone to view:

*******************

On Wed, 6 Sep 2000 16:18:00 +1000
"Richard Hill" wrote:
> When using the Wmsg function, I find an
> unexpected 'feature'
> We are using it to display a message box,
> eg with yes no boxes.
> This is part of a larger application.
> Assume the user wants to reply to the message
> with a yes.
>
> If they select the yes box with the mouse, and then click
> or if they type a 'y' then the system behaves as expected.
>
> If they select the yes box and then press the 'Enter' key
> the function returns the expected return code,
> BUT
> windows also keeps the 'enter' key hit alive and {Quad}wi activates
> the onKeyUpxx  method for the enter key quite unrelated to the message
> box, causing errors in the invoking application.
>
> APL+Win Version 3.6.09,  WinNT 4.0 SP5
>
> Is this a known condition?  Is there a standard bypass?

 

On Wed, 06 Sep 2000 15:40:28 -0400
APL2000 Technical Support <support@apl2000.com> wrote:
>
> Richard,
>
> This is a known condition of Windows.  The only way around this is to
> temporarily disable the onKeyUp handler immediately following the
> display of the message box.

*******************


The problem now, as was then, is that when you clear the message box with the Enter key, the onKeyUp event occurs in the window appearing after the message box.  This doesn't happen when you use Space Bar or mouse to clear the message box.  The reason for this is partly explained in Davin's posting from 1/4/05 in that the button doesn't get the focus when you press the Enter key like it does with the Space Bar and mouse but more importantly, when you press the Enter key, the message box disappears and the subsequent window appears before you release the key.  So what ends up happening is onKeyUp event fires in the Edit control in the second window.  The workaround for this was to use the value of a variable to determine when the onKeyUp event was processed in the onKeyUp event hander function for the Edit control.  [See onKeyUp fn below]

But the workaround created a new problem, which was when the Space Bar or mouse was used to clear the message box, the Enter key needed to be pressed twice in the Edit box in order to (correctly) process the onKeyUp notification.  Here is a workaround for this problem.  It requires setting up
filter-procedures for the Windows messages WM_KEYUP, WM_LBUTTONUP, and WM_NCDESTROY and subclassing the button in the message box with your filter-procedures.  When the WM_KEYUP and WM_LBUTTONUP messages are detected, the above-mentioned variable is set to correctly process the Enter key in the subsequent window. 

Below is the improved version of your Test function.  Just paste it into your APL+Win session and try it out.


 Test2 arg;hwnd;res;button;f1;f2;f3;sfp;rc

:select arg

:case 'create'
    © initialize variable used to process the onKeyUp event
    ‘val„0

    © create Timer object used to subclass message box
    0 0½'t' Œwi 'Create' 'Timer'
    't' Œwi 'interval' 250
    't' Œwi 'onTimer' "Test2 'onTimer'"

    © call message box
    0 0½Wmsg 'test' 'title'

    © display form appearing after message box
    0 0½'test' Œwi 'Create' 'Form'
    Œwself„'test.ed' Œwi 'Create' 'Edit'
    Œwi 'onKeyUp' "Test2 'onKeyup'"
    Œwi 'onDestroy' "0 0½ŒEX '‘val ‘SpaceBar ‘Mouse'"
    Œwi ':Wait'


:case 'onTimer'
    © Get window handle of Message Box
    hwnd„FindFrame 'title'

    © Get handles for all objects in MessageBox
    res„EnumChildWindows hwnd

    © Pick the window handle for the OK button in MessageBox
    © Use a different value desired is in a different position.
    button„res[3;1]

    ‘SpaceBar„‘Mouse„0
    © Subclass the button in MessageBox
    f1„('WM_KEYUP' '‘SpaceBar„1 ª W_Forward')
    f2„('WM_LBUTTONUP' '‘Mouse„1 ª W_Forward')
    f3„('WM_NCDESTROY' "Test2 'MBDestroy'")
    sfp„W_CreateFilter 'SP' f1 f2 f3
    rc„W_SubClass 0 button sfp
    W_Destroy sfp
    0 0½'t' Œwi 'Delete'


:case 'onKeyup'

    © when ‘val is 1, process the onKeyup event
    :if ‘val=0
        Œwres„¯1
        ‘val„1
    :else
        :select (Œwarg[7])
        :case 13
        'Enter Key Detected'
        :end
    :endif


:case 'MBDestroy'

    © check if message box dismissed with Space Bar or Mouse
    :if ‘SpaceBar=1
    :orif ‘Mouse = 1
        ‘val„1
    :endif

:end

 

 

APL2000 Support

     



APL2000 Official Web Site

Service is the rent we pay for being. It is the very purpose of life, and not something you do in your spare time.
--- Marion Wright Edelman

APLDN Home   |    |  Events   |  Trainings   |  APL Books   |  APLDN Links   |    |  Discussion Groups   |    |  Downloads   |  Articles   |  Library   |  Learning Tools   |  APLDN User IO   |  APL2000.com   |