Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. WS_TABSTOP and EDIT controls

WS_TABSTOP and EDIT controls

Scheduled Pinned Locked Moved C / C++ / MFC
c++wpfcomquestion
4 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • L Offline
    L Offline
    Luther Baker
    wrote on last edited by
    #1

    I am building a window in code (not via RC or dialog templates) and attaching EDIT controls to it. Upon completion, there may be 10 windows with 25 EDIT controls each. Within each window (one displayed at a given time) I'd like to TAB between the EDIT controls. Unfortunately, the only examples I can find on the net (http://blogs.msdn.com/oldnewthing/archive/2003/10/21/55384.aspx) want me to change my message loop to something like this: if (IsDialogMessage(hwnd, &msg)) { /* Already handled by dialog manager */ } else { TranslateMessage(&msg); DispatchMessage(&msg); } My message loop is in a completely different C++ file/class. For this to work as described, I'd need to pass the application (or make it global) to every single EDIT control - or at least, find away to keep updating the "hwnd" used in the IsDialogMessage method above every time focus changed since that method works on a specific EDIT control at a time ... Is that really necessary? I've built the EDIT controls with WS_TABSTOP style, and naturally, they are eating the TAB key. I can manually catch and GetNextDlgTabItem myself, but I wasn't sure if that was normal. Is there a cleaner way I've overlooked? Many thanks, -Luther

    A 1 Reply Last reply
    0
    • L Luther Baker

      I am building a window in code (not via RC or dialog templates) and attaching EDIT controls to it. Upon completion, there may be 10 windows with 25 EDIT controls each. Within each window (one displayed at a given time) I'd like to TAB between the EDIT controls. Unfortunately, the only examples I can find on the net (http://blogs.msdn.com/oldnewthing/archive/2003/10/21/55384.aspx) want me to change my message loop to something like this: if (IsDialogMessage(hwnd, &msg)) { /* Already handled by dialog manager */ } else { TranslateMessage(&msg); DispatchMessage(&msg); } My message loop is in a completely different C++ file/class. For this to work as described, I'd need to pass the application (or make it global) to every single EDIT control - or at least, find away to keep updating the "hwnd" used in the IsDialogMessage method above every time focus changed since that method works on a specific EDIT control at a time ... Is that really necessary? I've built the EDIT controls with WS_TABSTOP style, and naturally, they are eating the TAB key. I can manually catch and GetNextDlgTabItem myself, but I wasn't sure if that was normal. Is there a cleaner way I've overlooked? Many thanks, -Luther

      A Offline
      A Offline
      Anonymous
      wrote on last edited by
      #2

      Once you have built them, you could SetWindowPos(CWnd* pWndInsertAfter, int x, int y, int cx, int cy, UINT nFlags ); where pWndInsertAfter identifies the CWnd object that will precede this CWnd object in the Z-order.

      L 1 Reply Last reply
      0
      • A Anonymous

        Once you have built them, you could SetWindowPos(CWnd* pWndInsertAfter, int x, int y, int cx, int cy, UINT nFlags ); where pWndInsertAfter identifies the CWnd object that will precede this CWnd object in the Z-order.

        L Offline
        L Offline
        Luther Baker
        wrote on last edited by
        #3

        I'm not sure how that helps me? If I am in a TEXT EDIT box - and I press the "TAB" key, the MessageBell goes off and the "TAB" key is sent to the TEXT EDIT box. If I manually catch the "TAB" key in a WM_CHAR message and manually call GetNextDlgTabItem and then SetFocus(nextItem) ... I get the behavior I want. The ordering is fine. When I manually tab, I tab to the correct TEXT EDIT box. The problem is not the ordering or where I am going. The problem is catching the "TAB" key before it is sent to the EDIT TEXT box. That is what IsDialogMessage handles for me. I'm just looking for some common idiom to handle this - since IsDialogMessage needs the HWND to check and IsDialogMessage must exist with the main message loop - 100,000 miles (so to speak) away from the rest of my code. Does that help clarify anything? Thanks, -Luther

        B 1 Reply Last reply
        0
        • L Luther Baker

          I'm not sure how that helps me? If I am in a TEXT EDIT box - and I press the "TAB" key, the MessageBell goes off and the "TAB" key is sent to the TEXT EDIT box. If I manually catch the "TAB" key in a WM_CHAR message and manually call GetNextDlgTabItem and then SetFocus(nextItem) ... I get the behavior I want. The ordering is fine. When I manually tab, I tab to the correct TEXT EDIT box. The problem is not the ordering or where I am going. The problem is catching the "TAB" key before it is sent to the EDIT TEXT box. That is what IsDialogMessage handles for me. I'm just looking for some common idiom to handle this - since IsDialogMessage needs the HWND to check and IsDialogMessage must exist with the main message loop - 100,000 miles (so to speak) away from the rest of my code. Does that help clarify anything? Thanks, -Luther

          B Offline
          B Offline
          benft
          wrote on last edited by
          #4

          Is it a modeless dialog? I'm having the same problem. In modal dialogs, WS_TABSTOP does the job you want: send focus to the next control in the tab order when tab is hit. Modeless, nope...I get the same behavior. Help anybody?

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups