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. Spy++ unable to find dialog controls

Spy++ unable to find dialog controls

Scheduled Pinned Locked Moved C / C++ / MFC
announcementquestion
11 Posts 5 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.
  • D Offline
    D Offline
    Dave Calkins
    wrote on last edited by
    #1

    Normally, when using the Spy++ find window tool, you can mouse over a dialog and the controls will highlight as you mouse over them, allowing you to click them and then have Spy++ select them in its list of windows. We have a dialog app and this has worked fine for that app. We recently upgraded to a new version of a third party GUI library we use and are seeing some wierdness. When trying to use Spy++ to examine the windows, I noticed that the Spy++ find window tool no longer works in this dialog. With the find window tool active, when you mouse over the dialog the controls do not highlight. If you move to the title bar the dialog does highlight. If you click the dialog, you can see it in the Spy++ list along with all the child controls. I guess I'm grasping at straws a bit, but this seemed really unusual. I can run an older version (before the third party GUI library update) and it works fine. Any ideas what (if anything) this strange Spy++ behavior could indicate?

    C D L L 4 Replies Last reply
    0
    • D Dave Calkins

      Normally, when using the Spy++ find window tool, you can mouse over a dialog and the controls will highlight as you mouse over them, allowing you to click them and then have Spy++ select them in its list of windows. We have a dialog app and this has worked fine for that app. We recently upgraded to a new version of a third party GUI library we use and are seeing some wierdness. When trying to use Spy++ to examine the windows, I noticed that the Spy++ find window tool no longer works in this dialog. With the find window tool active, when you mouse over the dialog the controls do not highlight. If you move to the title bar the dialog does highlight. If you click the dialog, you can see it in the Spy++ list along with all the child controls. I guess I'm grasping at straws a bit, but this seemed really unusual. I can run an older version (before the third party GUI library update) and it works fine. Any ideas what (if anything) this strange Spy++ behavior could indicate?

      C Offline
      C Offline
      CPallini
      wrote on last edited by
      #2

      Dave Calkins wrote:

      you can see it in the Spy++ list along with all the child controls

      Are you sure the above list contains the controls that Spy++ find window tool cannot detect? I mean maybe those controls aren't windows.

      If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
      [my articles]

      D 1 Reply Last reply
      0
      • D Dave Calkins

        Normally, when using the Spy++ find window tool, you can mouse over a dialog and the controls will highlight as you mouse over them, allowing you to click them and then have Spy++ select them in its list of windows. We have a dialog app and this has worked fine for that app. We recently upgraded to a new version of a third party GUI library we use and are seeing some wierdness. When trying to use Spy++ to examine the windows, I noticed that the Spy++ find window tool no longer works in this dialog. With the find window tool active, when you mouse over the dialog the controls do not highlight. If you move to the title bar the dialog does highlight. If you click the dialog, you can see it in the Spy++ list along with all the child controls. I guess I'm grasping at straws a bit, but this seemed really unusual. I can run an older version (before the third party GUI library update) and it works fine. Any ideas what (if anything) this strange Spy++ behavior could indicate?

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

        I've seen this quite a few times with controls that are obscured by others. I never bothered to find a solution, if there even is one.

        "Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

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

        1 Reply Last reply
        0
        • D Dave Calkins

          Normally, when using the Spy++ find window tool, you can mouse over a dialog and the controls will highlight as you mouse over them, allowing you to click them and then have Spy++ select them in its list of windows. We have a dialog app and this has worked fine for that app. We recently upgraded to a new version of a third party GUI library we use and are seeing some wierdness. When trying to use Spy++ to examine the windows, I noticed that the Spy++ find window tool no longer works in this dialog. With the find window tool active, when you mouse over the dialog the controls do not highlight. If you move to the title bar the dialog does highlight. If you click the dialog, you can see it in the Spy++ list along with all the child controls. I guess I'm grasping at straws a bit, but this seemed really unusual. I can run an older version (before the third party GUI library update) and it works fine. Any ideas what (if anything) this strange Spy++ behavior could indicate?

          L Offline
          L Offline
          led mike
          wrote on last edited by
          #4

          Dave Calkins wrote:

          Any ideas what (if anything) this strange Spy++ behavior could indicate?

          yes

          Dave Calkins wrote:

          third party GUI library we use

          Therefore

          Dave Calkins wrote:

          seeing some wierdness.

          Does this library include source code? If not then you need to be asking them not us. If the library does not include source code then you have eliminated yourself or any other developer from solving the problem. You are now completely at the mercy of the third party. Are you having fun yet?

          led mike

          D 1 Reply Last reply
          0
          • C CPallini

            Dave Calkins wrote:

            you can see it in the Spy++ list along with all the child controls

            Are you sure the above list contains the controls that Spy++ find window tool cannot detect? I mean maybe those controls aren't windows.

            If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
            [my articles]

            D Offline
            D Offline
            Dave Calkins
            wrote on last edited by
            #5

            yes, they are windows. although they don't highlight when mousing over with the find window tool, if you mouse over the dialog title bar and click it, it finds it in the list. If you then expand the tree, you can see all the controls listed as windows. In the list, you can right-click and highlight them and they do highlight. It just seemed that the mouse-over behavior was odd and I was wondering if that indicated anything particular.

            1 Reply Last reply
            0
            • L led mike

              Dave Calkins wrote:

              Any ideas what (if anything) this strange Spy++ behavior could indicate?

              yes

              Dave Calkins wrote:

              third party GUI library we use

              Therefore

              Dave Calkins wrote:

              seeing some wierdness.

              Does this library include source code? If not then you need to be asking them not us. If the library does not include source code then you have eliminated yourself or any other developer from solving the problem. You are now completely at the mercy of the third party. Are you having fun yet?

              led mike

              D Offline
              D Offline
              Dave Calkins
              wrote on last edited by
              #6

              led mike wrote:

              yes

              can you be more specific? :)

              led mike wrote:

              Does this library include source code? If not then you need to be asking them not us. If the library does not include source code then you have eliminated yourself or any other developer from solving the problem. You are now completely at the mercy of the third party. Are you having fun yet?

              yes, the library includes source code. I have asked them and they're not sure either. Its a strange issue and the Spy++ behavior seemed odd so I thought I'd ask what that could indicate. The issue is we're using custom control from the library which provides menu toolbar functionality. It uses a menu resource along with toolbar icons and provides icons in the menus, etc. Its worked fine for some time, but upgrading the third party GUI library results in the menu no longer rendering. The toolbar is there, but is empty. None of the menu items render. Creating an empty sample project works fine. The menu shows as expected using the new vesion of the library. So there's something messed up with the project. I tried Spy++ just to see what was there and saw the strange mouse-over behavior. As I said, there's some straw grasping going on :)

              L 1 Reply Last reply
              0
              • D Dave Calkins

                led mike wrote:

                yes

                can you be more specific? :)

                led mike wrote:

                Does this library include source code? If not then you need to be asking them not us. If the library does not include source code then you have eliminated yourself or any other developer from solving the problem. You are now completely at the mercy of the third party. Are you having fun yet?

                yes, the library includes source code. I have asked them and they're not sure either. Its a strange issue and the Spy++ behavior seemed odd so I thought I'd ask what that could indicate. The issue is we're using custom control from the library which provides menu toolbar functionality. It uses a menu resource along with toolbar icons and provides icons in the menus, etc. Its worked fine for some time, but upgrading the third party GUI library results in the menu no longer rendering. The toolbar is there, but is empty. None of the menu items render. Creating an empty sample project works fine. The menu shows as expected using the new vesion of the library. So there's something messed up with the project. I tried Spy++ just to see what was there and saw the strange mouse-over behavior. As I said, there's some straw grasping going on :)

                L Offline
                L Offline
                led mike
                wrote on last edited by
                #7

                Well at least you have the source so you will just have to dig in and figure it out. Menu's can be a quite stubborn. It sounds like perhaps something is not being created successfully so I might start by checking out how they implemented creation. Like are they logging or asserting or throwing or whatever. Since you have source you could add any of those that might be helpful in researching the problem.

                led mike

                D 1 Reply Last reply
                0
                • L led mike

                  Well at least you have the source so you will just have to dig in and figure it out. Menu's can be a quite stubborn. It sounds like perhaps something is not being created successfully so I might start by checking out how they implemented creation. Like are they logging or asserting or throwing or whatever. Since you have source you could add any of those that might be helpful in researching the problem.

                  led mike

                  D Offline
                  D Offline
                  Dave Calkins
                  wrote on last edited by
                  #8

                  well, I noticed something else which might provide a hint. If I hit the Alt key and then the down arrow, the drop down menus appear, but they appear as though they're dropping down from under the title bar and each top level menu (accessed by using the right and left arrow keys) shows up in the same place. I guess I'll dig into their rendering code. Maybe the positioning was somehow hosed.

                  1 Reply Last reply
                  0
                  • D Dave Calkins

                    Normally, when using the Spy++ find window tool, you can mouse over a dialog and the controls will highlight as you mouse over them, allowing you to click them and then have Spy++ select them in its list of windows. We have a dialog app and this has worked fine for that app. We recently upgraded to a new version of a third party GUI library we use and are seeing some wierdness. When trying to use Spy++ to examine the windows, I noticed that the Spy++ find window tool no longer works in this dialog. With the find window tool active, when you mouse over the dialog the controls do not highlight. If you move to the title bar the dialog does highlight. If you click the dialog, you can see it in the Spy++ list along with all the child controls. I guess I'm grasping at straws a bit, but this seemed really unusual. I can run an older version (before the third party GUI library update) and it works fine. Any ideas what (if anything) this strange Spy++ behavior could indicate?

                    L Offline
                    L Offline
                    Lost User
                    wrote on last edited by
                    #9

                    Interesting. Are your controls, by chance, contained within other controls?

                    Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Individuality is fine, as long as we do it together - F. Burns

                    D 1 Reply Last reply
                    0
                    • L Lost User

                      Interesting. Are your controls, by chance, contained within other controls?

                      Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Individuality is fine, as long as we do it together - F. Burns

                      D Offline
                      D Offline
                      Dave Calkins
                      wrote on last edited by
                      #10

                      no, they're direct children of the dialog.

                      L 1 Reply Last reply
                      0
                      • D Dave Calkins

                        no, they're direct children of the dialog.

                        L Offline
                        L Offline
                        Lost User
                        wrote on last edited by
                        #11

                        Hmmm... I don't have that same problem (using the same library). Contained control controls are not showing up and the ones that do, Spy++ says it can't find the window at all. So while I can find the controls, Spy++ still can't find them.

                        Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Individuality is fine, as long as we do it together - F. Burns

                        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