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.

(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

(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 appears to be, therefore, correct. 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 TOWARDS THE FAR RIGHT, AS THOUGH THE INDEX OF THE ARRAY WAS REVERSED, THOUGH THIS IS NOT QUITE REPRODUCEABLE)

LRESULT hideResult = SendMessage(hTrayWnd, TB_HIDEBUTTON, i, 1 ); /

// IN C++ /clr // BOXED VALUE TYPE ON GC HEAP int ^ gc_i = gcnew int;           // WHAT EXACTLY IS THE STORAGE TYPE FOR THIS int ? int * i = new int; *i = 5; // PRESUMABLY ON THE UNMANAGED HEAP, BUT HOW CAN THIS HAPPEN FOR INT? // DOESN'T INT ALWAYS MAP TO System.Int32? // OR DOES THE COMPILER GIVE US A NATIVE INT INSTEAD, TO PLACE ON THE UNMANGED HEAP?

// IN A CLR C++ PROJECT // AN ARRAY. SHOWS IN LOCALS WINDOW AS TYPE array array<byte> ^ a = gcnew array<BYTE>(10); // A BYTE ARRAY. SHOWS IN LOCALS WINDOW LIKE A NATIVE ARRAY BYTE b[10]; b[0] = 5; // A POINTER LPBYTE p = &b[0]; The pointer is to be passed to api as a buffer to fill The question: is b actually a ref system.array instance and therefore pin_ptr should be used instead? If so this must cause some subtle bugs?

I have two versions of SENS.DLL both version 5.2.3790.3959 According to WinMerge they are binary identical. However, they are different sizes on disk? C:\windows\system32\sens.dll (65,024 bytes) C:\windows\sysWOW64\sens.dll (37,376 bytes) I also loaded them both into TextPad and they appear identical, both have length of 37,376 Why they appear different sizes on disk? It appears that MS has accidentally released a 32 bit build of the DLL for both 32 bit and 64 bit use?

http://www.codeproject.com/KB/IP/SENSNetworkEvents.aspx[^] When attempting to load this project on x64, the SENS type libary is not available in the COM tab of the References dialog. SENS.DLL seems to be correctly registered in the registry as a type library but is not recognized in Visual Studio. The example project is C# but the problem persists in C++ projects too. It works fine on 32 bit. Have tested this on several x64 boxes, same result. Is the Visual Studio builder broken?

These two APIs are very similar but it is unclear what the differences are and when each should be used (Except that LoadUserProfile is specified for use with CreateProcessAsUser which I am not using. I am simply impersonating for hive accesss). LoadUserProfile http://msdn.microsoft.com/en-us/library/bb762281(VS.85).aspx RegOpenCurrentUser http://msdn.microsoft.com/en-us/library/ms724894(VS.85).aspx According to the Services & the Registry article: http://msdn.microsoft.com/en-us/library/ms685145(VS.85).aspx we should use RegOpenCurrentUser when impersonating. But what does/should RegOpenCurrentUser do if the user profile is roaming - should it load it? As far as I can tell from these docs, both APIs provide a handle to the HKEY_CURRENT_USER for the user the thread is impersonating. Therefore, they both "load" the hive i.e. lock it as a database file and give a handle to it for registry APIs. It might seem that LoadUserProfile loads the user profile in the same way as the User does when he/she logs on, whereas RegOpenCurrentUser does not - is this correct? What is the fundamental difference (if any) in how these two APIs mount the hive? What are the implications and differences (if any) between what happens IF 1. A user logs-on or logs-off while each of these impersonated handles is already in use? 2. A user is already logged-on when each matching close function (RegCloseKey and UnloadUserProfile) is called?

I am designing a Service to run under LocalSystem account on Win2000, XP and Vista. It will need access to users registry hives, sometimes for extended periods of time, both when the users are logged-in, and also, when they are not logged-in (IF the profile is local. If the profile is Roaming and not loaded, I will not attempt to load it.) If the user is logged-on, I can get the Users access token by various means (E.g. from its Explorer process, or by receiving Logon events from the Service Control Manager) then use ImpersonateLoggedOnUser and RegOpenCurrentUser to access the User's hive. However, what are the implications if the User selects LogOff from the start menu while I am impersonating and have his hive open? Will the logoff be prevented? Will my impersonation be terminated? If the user is not logged on, I can use RegLoadKey to directly open the hive NTUSER.DAT. (Impossible for a logged-on user). But what are the implications of this if the user decides to log-on (I suppose the hive will be locked and the logon either prevented, or may experience difficulty?) I will be setting up some test projects to explore these ideas however, regardless of their apparent results, these questions are theoretical in terms of what type of problems might, or would, be caused by the user loggin in/out during these actions by the service. Caveat: ImpersonateLoggedOnUser can ONLY be used either for a logged-on user (token obtained from process or SCM event) OR for a user for which I have the plaintext password to call WinLogon and obtain a token - TRUE / FALSE ? In other words although I have maximum permissions as LocalSystem and am able to change the user's password or even delete the user's account, if the user is not logged-on, it is totally impossible to create a new token to impersonate the user without having the the password?