No announcement yet.

Custom Control/KeyDown Headache...

  • Filter
  • Time
  • Show
Clear All
new posts

  • Custom Control/KeyDown Headache...


    Once again its a late night behind the warm glow of the CRT...

    How is it that a windows control like an editbox/textbox can
    process ALL the WM_KEY(DOWN/UP) messages but when you make a
    custom control it seems like windows filters out the ESC, ARROW,
    and ENTER keys. I have put together a simple example in which the
    above happens...

    #compile exe
    #include ""
    function GridProc(byval hwnd as long, byval wmsg as long, byval wparam as long, byval lparam as long) export as long
      dim ps        as local PAINTSTRUCT
      dim hdc       as local long
      dim wr        as local RECT
      select case wmsg
        case %WM_PAINT
          GetClientRect hwnd, wr
          hdc = BeginPaint(hwnd, ps)
          DrawFrameControl hdc, wr, %DFC_BUTTON, %DFCS_BUTTONPUSH
          EndPaint hwnd, ps
        case %WM_KEYDOWN
          SetWindowText GetParent(hwnd), format$(wparam)
        case else
          function = DefWindowProc(hwnd, wmsg, wparam, lparam)
      end select
    end function
    callback function dlgproc as long
      dim szClassName as asciiz * 64
      dim wc as local WNDCLASSEX
      select case cbmsg
        case %WM_INITDIALOG
          szClassName                   = "SysGrid32"
          wc.cbSize                     = sizeof(wc)
                      = %CS_HREDRAW or %CS_VREDRAW
          wc.lpfnWndProc                = codeptr(GridProc)
          wc.cbClsExtra                 = 0
          wc.cbWndExtra                 = 0
          wc.hInstance                  = GetWindowLong(cbhndl, %GWL_HINSTANCE)
          wc.hIcon                      = %NULL
          wc.hIconSm                    = %NULL
          wc.hCursor                    = LoadCursor(%NULL, byval %IDC_ARROW)
          wc.hbrBackground              = %COLOR_WINDOWFRAME
          wc.lpszClassName              = varptr(szClassName)
          wc.lpszMenuName               = %NULL
          if (RegisterClassEx(wc) = %FALSE) then
            MessageBox %HWND_DESKTOP, "Unable to register window class", "message", %MB_OK or %MB_ICONERROR
            exit function
          end if
          control add "SysGrid32", cbhndl, 100, "", 8, 8, 32, 14, %WS_CHILD or %WS_VISIBLE
      end select
    end function
    function pbmain as long
      dim hdlg as local long
      dialog new %NULL, "KeyDown test", 1, 1, 256, 256, %WS_OVERLAPPEDWINDOW, %WS_EX_TOOLWINDOW to hdlg
      dialog show modal hdlg call dlgproc
    end function

  • #2
    %WM_CHAR ??

    [email protected]


    • #3
      You should consider using a keyboard hook, my WinLIFT's package uses this technic to filter characters before they reach edit controls.

      If you are familiar with SDK programming style you can also try this one:
          WHILE GetMessage(Msg, %NULL, 0, 0)
             IF Msg.Message = %WM_KEYUP THEN
                SELECT CASE Msg.wParam
                CASE %VK_RETURN 
                CASE %VK_ESCAPE
                END SELECT 
             END IF
             IF IsDialogMessage(hDialB&, Msg) = %FALSE THEN
                TranslateMessage Msg
                DispatchMessage Msg
             END IF

      Patrice Terrier
      mailto[email protected][email protected]</A>
      Patrice Terrier
      Addons: GDImage.DLL 32/64-bit (Graphic library), WinLIFT.DLL 32/64-bit (Skin Engine).


      • #4
        Hello Edwin and Patrice!

        Edwin, I have already tried the WM_CHAR method but it doesn't seem
        to work at all, Thanks for your input though. Patrice, maybe you
        can answer my next question, What is DDT doing to prevent messages
        from reaching the dialog handler function? Why wouldn't PowerBasic
        outline what each function does so that we can write our code
        around these rules. Is this all because of the may Windows manages
        dialogs? If that is the case then maybe PowerBasic should read
        one of my earlyer posts about adding some windows support to DDT
        or a new extension of DDT called DWT(dynamic window tools).

        WINDOW NEW %HWND_DESKTOP, "TestApp", etc...
        WINDOW SET SIZE CBHWND, 256, 256
        What do you think?



        • #5
          Mark, you are essentially trying to trap "special" keys like TAB, ENTER, etc, and you need to work at a much "lower" level than DDT can offer (you need to be able to work within the application's message loop to intercept the messages before TranslateMessage() is executed).

          As Patrice suggested, a keyboard hook would be the easiest solution to trap these keys.

          For more information how Windows treats keystroke messages, please review the WIN32.HLP chapter "Keyboard Input".

          PowerBASIC Support
          mailto:[email protected][email protected]</A>
          mailto:[email protected]


          • #6
            Thanks Lance!

            What do you think about extending the DDT functions to support
            "regular" windows? I think it would make the code more readable
            and give it a more constant look and feel.



            • #7
              DDT does things according to how the Windows dialog engine governs... hence the name "Dynamic Dialog Tools". If you create a dialog using non-DDT techniques you'll find that keyboard messages received by the dialog callback procedure are no different to those received by a DDT callback.

              If DDT was "enhanced" to work with standard windows rather than dialogs, then we would have to change the name!

              PowerBASIC Support
              mailto:[email protected][email protected]</A>
              mailto:[email protected]