No announcement yet.

Poor man's keystroke capture in edit control

  • Filter
  • Time
  • Show
Clear All
new posts

  • Poor man's keystroke capture in edit control

    I was reading an old post about capturing keystrokes in a textbox. The answer given was to subclass the control.

    It's easy enough to capture the last character typed in, as long as it was typed at the end (code example below).

    Another way to approach the problem is to use the %EN_Change notification - compare the previous content of the textbox to the content of the textbox when %EN_change is called.

    The approach can certainly be used to reject keystrokes which result in an undesired/desired textbox content - such as limiting it to numbers, letters, or special formats.

    Figuring out which non-character keys were pressed (arrow keys, shift/control, ...) or highlighting or copy/paste wouldn't be so straight-forward.

    But just because I don't see an immediate answer, doesn't mean someone else hasn't played with it to see what could be done.

    Has anyone come up with an attempt at a generalized solution?

    #Compile Exe
    #Dim All
    #Include ""
    Function PBMain() As Long
        Local hDlg As Dword
        Dialog New Pixels, 0, "Button Test",300,300,200,200, %WS_OverlappedWindow To hDlg
        Control Add TextBox, hDlg, 200,"Push", 50,40,100,20
        Control Add Label, hDlg, 300,"", 50,70,100,20
        Dialog Show Modal hDlg Call DlgProc
    End Function
    CallBack Function DlgProc() As Long
       Local NewTxt$
       If Cb.Msg = %WM_Command And Cb.Ctl = 200 And Cb.CtlMsg = %EN_Change Then
          Control Get Text Cb.Hndl, 200 To NewTxt$
          Control Set Text Cb.Hndl, 300, Right$(NewTxt$,1)
       End If
    End Function
    If not, perhaps I'll play with it and see what kind of an answer I can dream up - then ask for the forum for critique.

    I can't say as I have any pressing reason to do it - just looking at alternative solutions.
    Last edited by Gary Beene; 11 Apr 2009, 06:58 PM.

  • #2
    >just looking at alternative solutions

    Since detecting a keypress (or release) is not the same thing as detecting a change to the contents of the edit control, these are not "alternative" solutions for the same challenge.

    In your particular application it may be sufficient to do the latter; but that does not make processing the WM_COMMAND/EN_CHANGE notification the same as subclassing the control to pick up the WM_KEYDOWN or WM_KEYUP notifications.

    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]


    • #3
      Hi Micheal!

      You're correct - it would be a limited solution.

      However, I'm trying to think of when I last needed to know (in a textbox) when a key was down vs knowing what key was entered into the textbox.

      Limited doesn't mean not useful.

      And no, I don't have anything better to do on Saturday night. My wife and I have exercised, done our errands, finished the housework, caught upo on yardwork, and prepared the meal for tomorrow's family Easter lunch. So I'm on fun-time now!

      ... and as I reread this, I recall you saying on more than one occasion - tell me what you want to do, not how you want to do it. So when a post asks to capture a key, an alternative solution like this might be the better answer!
      Last edited by Gary Beene; 11 Apr 2009, 07:35 PM.


      • #4
        Did you see this recent thread? It is relevant to your post I think.

        User to user discussions about the PB/Win (formerly PB/DLL) product line. Discussion topics include PowerBASIC Forms, PowerGEN and PowerTree for Windows.

        An interesting alternative to subclassing is put forward by Colin Schmidt (post #27)
        Rgds, Dave


        • #5
          Actually, that was the thread that started me thinking.

          But when I got to Colin's post I didn't look at it close enough to be able to figure out what his "one line" was.

          I'll go look some more.