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. Strange random behavior of TB_HIDEBUTTON on Win7 Notification Toolbar buttons

Strange random behavior of TB_HIDEBUTTON on Win7 Notification Toolbar buttons

Scheduled Pinned Locked Moved C / C++ / MFC
helpquestiondatabasecomlinux
3 Posts 2 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.
  • W Offline
    W Offline
    Will5801
    wrote on last edited by
    #1

    (This does reference previous projects but I suggest deserves a new thread as it is a particular issue with TB_HIDEBUTTON and no other API). I have discovered some apparently random behaviour of TB_HIDEBUTTON on Windows 7 64-bit. I have not tested on any other OS but suppose the problem will be duplicated to some degree or other. First, I have a project (of my own) which successfully enumerates the toolbar buttons in the Notify Area. One starting project to illustrate the idea, is this: http://www.codeproject.com/Articles/10807/Shell-Tray-Info-Arrange-your-system-tray-icons (This is an old project - for my Win7 it needs modifying to make the TBBUTTON structure fixed to 6 reserved bytes, also a mod to find the hwnd Win 7 "User Promoted Notification Area", so it's not a perfect sample but good enough to illustrate the type of code loop i'm using.) I've used TB_BUTTONCOUNT to obtain a count of buttons on the Notification Toolbar, have entered a loop iterating over those items as i, and have created memory in the target process to retrieve the TBBUTTON structure and its TRAYDATA structure. I have then used GetWindowThreadProcessId to get tray.hwnd and from there have been able to extract all the required information in my loop regarding the target button. This all works. The problem is, that being in my loop of i, I can successfully delete buttons with TB_DELETEBUTTON (and also, in the sample above with mods, can successfully use TB_MOVEBUTTON as well.) I'm therefore certain that my loop of i is pointing at the correct button. My pointer enumerator (actually an index i for SendMessage) appears to be, therefore, correct, as in, it is pointing at the correct button on the list in each iteration. That's logical. However, TB_HIDEBUTTON produces bizarre and unexpected results - it hides the wrong button every time. The only thing I can suppose in this circumstances is that the TB_HIDEBUTTON API has a wierd bug. Can anyone confirm what is the problem hiding buttons with this API?

    // In a loop of "int i" enumerating TB_BUTTONCOUNT list of buttons:

    // THIS WORKS, AND DELETES THE INDEXED Button
    LRESULT hideResult = SendMessage(hTrayWnd, TB_DELETEBUTTON, i, 0 ); // always zero

    // THE FOLLOWING CODE DOESN'T WORK, AND HIDES ANOTHER, (FAIRLY RANDOM) BUTTON,
    // SOMETIMES APPEARING TO BE IN A SORT OF DISORGANIZED REVERSE-ORDER, I.E.
    // IF YOU ATTEMPT TO HIDE A BUTTON TOWARDS THE FAR-LEFT OF THE NOTIFY AREA,
    // IT ENDS UP HIDING A BUTTON T

    L 1 Reply Last reply
    0
    • W Will5801

      (This does reference previous projects but I suggest deserves a new thread as it is a particular issue with TB_HIDEBUTTON and no other API). I have discovered some apparently random behaviour of TB_HIDEBUTTON on Windows 7 64-bit. I have not tested on any other OS but suppose the problem will be duplicated to some degree or other. First, I have a project (of my own) which successfully enumerates the toolbar buttons in the Notify Area. One starting project to illustrate the idea, is this: http://www.codeproject.com/Articles/10807/Shell-Tray-Info-Arrange-your-system-tray-icons (This is an old project - for my Win7 it needs modifying to make the TBBUTTON structure fixed to 6 reserved bytes, also a mod to find the hwnd Win 7 "User Promoted Notification Area", so it's not a perfect sample but good enough to illustrate the type of code loop i'm using.) I've used TB_BUTTONCOUNT to obtain a count of buttons on the Notification Toolbar, have entered a loop iterating over those items as i, and have created memory in the target process to retrieve the TBBUTTON structure and its TRAYDATA structure. I have then used GetWindowThreadProcessId to get tray.hwnd and from there have been able to extract all the required information in my loop regarding the target button. This all works. The problem is, that being in my loop of i, I can successfully delete buttons with TB_DELETEBUTTON (and also, in the sample above with mods, can successfully use TB_MOVEBUTTON as well.) I'm therefore certain that my loop of i is pointing at the correct button. My pointer enumerator (actually an index i for SendMessage) appears to be, therefore, correct, as in, it is pointing at the correct button on the list in each iteration. That's logical. However, TB_HIDEBUTTON produces bizarre and unexpected results - it hides the wrong button every time. The only thing I can suppose in this circumstances is that the TB_HIDEBUTTON API has a wierd bug. Can anyone confirm what is the problem hiding buttons with this API?

      // In a loop of "int i" enumerating TB_BUTTONCOUNT list of buttons:

      // THIS WORKS, AND DELETES THE INDEXED Button
      LRESULT hideResult = SendMessage(hTrayWnd, TB_DELETEBUTTON, i, 0 ); // always zero

      // THE FOLLOWING CODE DOESN'T WORK, AND HIDES ANOTHER, (FAIRLY RANDOM) BUTTON,
      // SOMETIMES APPEARING TO BE IN A SORT OF DISORGANIZED REVERSE-ORDER, I.E.
      // IF YOU ATTEMPT TO HIDE A BUTTON TOWARDS THE FAR-LEFT OF THE NOTIFY AREA,
      // IT ENDS UP HIDING A BUTTON T

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

      According to the documentation[^], the WPARAM value should be the command id of the button, not an index.

      W 1 Reply Last reply
      0
      • L Lost User

        According to the documentation[^], the WPARAM value should be the command id of the button, not an index.

        W Offline
        W Offline
        Will5801
        wrote on last edited by
        #3

        Correct. The API def for DELETEBUTTON specifies an Index whereas Command Identifier is presumably the idCommand field of TBBUTTON. The API docs are different for each function. Having tested this using the idCommand field of TBUTTON, rather than the Index, it works. Problem solved. Many thanks.

        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