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. Problem on dialog creation

Problem on dialog creation

Scheduled Pinned Locked Moved C / C++ / MFC
sysadminhelpquestion
18 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.
  • J jpyp

    DavidCrow wrote:

    While your code may not be doing it directly, a BM_SETCHECK message is being sent to the control, thus the control's handler is doing what it should. If this is undesirable behavior, there's an easy solution.

    By easy solution you mean removing the SetCheck(FALSE) call in OnInitDialog(), I tried that with no difference. Any other suggestions? Thanks!

    jpyp

    D Offline
    D Offline
    David Crow
    wrote on last edited by
    #9

    jpyp wrote:

    By easy solution you mean removing the SetCheck(FALSE) call in OnInitDialog()...

    No, I did not mean that at all. Try:

    void CMyDialog::CMyDialog()
    {
    m_bInitializing = true;
    }

    BOOL CMyDialog::OnInitDialog()
    {
    CDialog::OnInitDialog();
    ...
    m_bInitializing = false;
    return TRUE;
    }

    void CMyDialog::OnButtonChange()
    {
    if (! m_bInitializing)
    {
    // do whatever here
    }
    }


    "A good athlete is the result of a good and worthy opponent." - David Crow

    "To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

    J 1 Reply Last reply
    0
    • M Mark Salsbery

      WM_COMMAND messages which come from a control are notifications from the control to the parent. For a radio button, see Button Messages[^] The section "Notification Messages from Buttons" lists the BN_xxx notifications that a button sends to its parent in the form of a WM_COMMAND message. You should be able to match the high WORD of the WPARAM in the command message to one of those BN_xx codes. If not, maybe it's an undocumented message :) Mark

      "Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

      J Offline
      J Offline
      jpyp
      wrote on last edited by
      #10

      Thanks for your reply and info. As I stated in my original post, the high word of wParam is 0. I still can't figure out where this message is coming from. This is driving me crazy. If you can think of anything else, please let me know. If not thanks anyway for your help.

      jpyp

      M 1 Reply Last reply
      0
      • D David Crow

        jpyp wrote:

        By easy solution you mean removing the SetCheck(FALSE) call in OnInitDialog()...

        No, I did not mean that at all. Try:

        void CMyDialog::CMyDialog()
        {
        m_bInitializing = true;
        }

        BOOL CMyDialog::OnInitDialog()
        {
        CDialog::OnInitDialog();
        ...
        m_bInitializing = false;
        return TRUE;
        }

        void CMyDialog::OnButtonChange()
        {
        if (! m_bInitializing)
        {
        // do whatever here
        }
        }


        "A good athlete is the result of a good and worthy opponent." - David Crow

        "To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

        J Offline
        J Offline
        jpyp
        wrote on last edited by
        #11

        Thanks for your reply. However this will not help as the handler is being called after OnInitDialog() completes so in OnButtonChange() m_bInitializing will always be FALSE. This is driving me crazy. This behavior does not happen with my other dialogs.

        jpyp

        D 1 Reply Last reply
        0
        • J jpyp

          Thanks for your reply and info. As I stated in my original post, the high word of wParam is 0. I still can't figure out where this message is coming from. This is driving me crazy. If you can think of anything else, please let me know. If not thanks anyway for your help.

          jpyp

          M Offline
          M Offline
          Mark Salsbery
          wrote on last edited by
          #12

          jpyp wrote:

          As I stated in my original post, the high word of wParam is 0

          I never claimed I could read ;P That's a BN_CLICKED notification. It could be because the control received a WM_SETFOCUS message. I can't recall if a BN_CLICKED gets sent when you send a BM_SETCHECK - if you comment out that call, do you still get the notification? I'm not sure why you're worried about it. There's lots of messages that most of us don't handle or care about. It's much more of a problem when you expect a message and get none :) I thought I posted this link, but in case I didn't: Button Messages[^] This documents how messages are processed by and from a button control (this is documented for pretty much all Windows controls). Mark

          "Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

          J 1 Reply Last reply
          0
          • J jpyp

            Thanks for your reply. However this will not help as the handler is being called after OnInitDialog() completes so in OnButtonChange() m_bInitializing will always be FALSE. This is driving me crazy. This behavior does not happen with my other dialogs.

            jpyp

            D Offline
            D Offline
            David Crow
            wrote on last edited by
            #13

            jpyp wrote:

            the handler is being called after OnInitDialog() completes

            It almost sounds like UpdateData() is the culprit. What I don't understand, however, is why this is a problem. I've called SetCheck() within OnInitDialog() in several of my programs and it works fine. Can you explain a bit further what the actual problem is?


            "A good athlete is the result of a good and worthy opponent." - David Crow

            "To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

            J 1 Reply Last reply
            0
            • M Mark Salsbery

              jpyp wrote:

              As I stated in my original post, the high word of wParam is 0

              I never claimed I could read ;P That's a BN_CLICKED notification. It could be because the control received a WM_SETFOCUS message. I can't recall if a BN_CLICKED gets sent when you send a BM_SETCHECK - if you comment out that call, do you still get the notification? I'm not sure why you're worried about it. There's lots of messages that most of us don't handle or care about. It's much more of a problem when you expect a message and get none :) I thought I posted this link, but in case I didn't: Button Messages[^] This documents how messages are processed by and from a button control (this is documented for pretty much all Windows controls). Mark

              "Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

              J Offline
              J Offline
              jpyp
              wrote on last edited by
              #14

              I do get the same problem if I comment out the SetCheck call. I'll investigate the WM_SETFOCUS idea. I don't that is it but you never know. The reason I worry so much about it is that I have other controls on this dialog that are supposed to be disabled when the dialog opens. When the user click on the button that I have problem with, these controls are then enabled. My problem is that when I receive this "irritating" message when the dialog opens, these controls get enabled when they should not be yet because the user has not click on it yet. Hope I'm making some sense. Thanks!

              jpyp

              M D J 3 Replies Last reply
              0
              • D David Crow

                jpyp wrote:

                the handler is being called after OnInitDialog() completes

                It almost sounds like UpdateData() is the culprit. What I don't understand, however, is why this is a problem. I've called SetCheck() within OnInitDialog() in several of my programs and it works fine. Can you explain a bit further what the actual problem is?


                "A good athlete is the result of a good and worthy opponent." - David Crow

                "To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

                J Offline
                J Offline
                jpyp
                wrote on last edited by
                #15

                I'll investigate the UpdateData() idea. See my last post to Mark with regard to more explanation on the problem. Thanks!

                jpyp

                1 Reply Last reply
                0
                • J jpyp

                  I do get the same problem if I comment out the SetCheck call. I'll investigate the WM_SETFOCUS idea. I don't that is it but you never know. The reason I worry so much about it is that I have other controls on this dialog that are supposed to be disabled when the dialog opens. When the user click on the button that I have problem with, these controls are then enabled. My problem is that when I receive this "irritating" message when the dialog opens, these controls get enabled when they should not be yet because the user has not click on it yet. Hope I'm making some sense. Thanks!

                  jpyp

                  M Offline
                  M Offline
                  Mark Salsbery
                  wrote on last edited by
                  #16

                  jpyp wrote:

                  I'll investigate the WM_SETFOCUS idea. I don't that is it but you never know.

                  I just know what I read about how the default window proc for a button control handles the WM_SETFOCUS message: "Draws a focus rectangle on the button getting the focus. For radio buttons and automatic radio buttons, the parent window is sent a BN_CLICKED notification message." So, to back up, you are calling SetCheck(BST_UNCHECKED) for the radio button in question? Is this an automatic radio button? If so, maybe calling SetCheck(BST_CHECKED) on the radio button you DO want initially checked would be more appropriate. Mark

                  "Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder

                  1 Reply Last reply
                  0
                  • J jpyp

                    I do get the same problem if I comment out the SetCheck call. I'll investigate the WM_SETFOCUS idea. I don't that is it but you never know. The reason I worry so much about it is that I have other controls on this dialog that are supposed to be disabled when the dialog opens. When the user click on the button that I have problem with, these controls are then enabled. My problem is that when I receive this "irritating" message when the dialog opens, these controls get enabled when they should not be yet because the user has not click on it yet. Hope I'm making some sense. Thanks!

                    jpyp

                    D Offline
                    D Offline
                    David Crow
                    wrote on last edited by
                    #17

                    jpyp wrote:

                    I have other controls on this dialog that are supposed to be disabled when the dialog opens.

                    Unless your resource(s) are frozen (that's a concept with my product), shouldn't you be disabling those at design time, and only enabling them when said button is clicked?


                    "A good athlete is the result of a good and worthy opponent." - David Crow

                    "To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

                    1 Reply Last reply
                    0
                    • J jpyp

                      I do get the same problem if I comment out the SetCheck call. I'll investigate the WM_SETFOCUS idea. I don't that is it but you never know. The reason I worry so much about it is that I have other controls on this dialog that are supposed to be disabled when the dialog opens. When the user click on the button that I have problem with, these controls are then enabled. My problem is that when I receive this "irritating" message when the dialog opens, these controls get enabled when they should not be yet because the user has not click on it yet. Hope I'm making some sense. Thanks!

                      jpyp

                      J Offline
                      J Offline
                      jpyp
                      wrote on last edited by
                      #18

                      I fixed it!!!!! But before I tell how I fixed it, let me answer your comments/questions. First I'll show how the dialog is designed: RadButCol1 RadButCol2 PushBut1 EditCol1_1 EditCol2_1 PushBut1 EditCol1_2 EditCol2_2 PushBut1 EditCol1_3 EditCol2_3 PushBut1 EditCol1_4 EditCol2_4 ... PushBut19 EditCol1_19 EditCol2_19 David: At design, I disable all buttons in column 1 and 2 and the two radio buttons are unchecked. So when I open the dialog both columns should be disabled. Then the user should clickone of the radio buttons to enable one set of edit controls. However when the dialog is open, the handler for RadButCol1 is being called automatically and therefore the edit controls of column one get enabled. Mark: Setting the first push-button as the default button did not help. Also I tried with calling SetFocus() in the OnInitDlg() on PushBut1 so that the RadButCol1 would not have the focus on startup, but that still did not work. Now the fix (and I still don't know why it worked!!!!): In my .rc file I moved the declarations of the two radio buttons down so that they are not first in the dialog definition. Being first seems to trigger a BN_CLICKED notification message for some reason. If you have any idea why, please let me know. I really appreciate your help and time on this issue. Thanks!

                      jpyp

                      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