Custom Control/KeyDown Headache...

[mark smit]

Hello,

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 "win32api.inc"


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)
      wc.style                      = %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

------------------
Cheers

[Edwin Knoppert]

%WM_CHAR ??

------------------
[email protected]

[Patrice Terrier]

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
       
    WEND

------------------
Patrice Terrier
mailto[email protected][email protected]</A>

[mark smit]

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


CBHWND
CBHINSTANCE


WINDOW END CBHWND

What do you think?

------------------
Cheers

[Lance Edmonds]

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".


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

[mark smit]

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.

------------------
Cheers

[Lance Edmonds]

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!



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