We Keep Coding

Determining (programmatically) who controls the mouse on a PC using C# or C++

Is there a way to determine who is controlling the mouse (and which mouse) on a PC programmatically? I recently installed LogMeIn (logmein.com) and wanted to know if it's possible to (1) tell within a program if the mouse is being clicked/moved by the direct user or by a remote user, (2) write a stand-alone program that simply shows mouse events (on any application) and whether or not the mouse event was generated by a local or remote user. I am somewhat familiar with Win32 hooks, but don't think that they can give this sort of information. Regarding (1) it would seem like a common request. I.e. "Only allow user to complete button presses related to password change if he is local..." or something like that.
Of secondary importance (just academic interest actually) is the question of telling whether the local user is using the mouse or the trackpad.

you can hook the device API's of windows that you want to get the information from, then if the mouse moves the api is probably not called when the user movers the mouse, but if logmein does then it probably calls some SetMousePointerPos-like C WinAPI.

Since posting, I came across this post which basically answers the question.
C# Get Mouse handle (GetRawInputDeviceInfo)
I'd add that for those of you who want to use WPF instead of WinForms (as the example above uses), check out ComponentDispatcher.ThreadFilterMessage (for WPF) or IMessageFilter (Windows Forms).
I wrote a couple of programs based on the above posting (one is basically the posting above with some minor additions and the other is a WPF (as opposed to WinForms)). If I can figure out GitHub I'll post all the code and add a comment here. But the posting above definitely gives you all you need.

How to keep focus on more than one window for input devices

The idea is to do something like what a keystroke catcher does, but with multiple input devices. I want a window to record input from devices even if the focus is on another window. What libraries or methodologies would allow me to accomplish this?

This is typically handled via a low level Hook. There is no C# library which will handle this directly, though there is a Microsoft KB article showing How to set a Windows hook in Visual C# .NET.

c# read syslistview32 items tooltips via winapi

i want to write an application, which reads under windows xp the quick launch items in the order like they are located in the taskbar,
and sets hotkeys for each of these item.
windows + 1 should start the first application
windows + 2 the second, etc.
(like in windows 7)
all of these items are found i a folder, but if i read the items of this folder, i dont get the right order of these items.
i found two solutions the get the right order - first:
in the registry an entry is found, where its saved how they are located, but not in plain text. i dont know how to read this, and cant reverse engine it.
the second:
read via winapi the items tooltip from the taskbar, so i can (if there are not items with the same name) search via the name in the quick launch folder.
the quick launch bar is just a listview (syslistview32).
via sendmessage i got it work to count the items, and start one (faking a click on this item), but how the hell can i read the tooltip?
i have googled a lot, tried everything, but i didnt get it run.
i hope you have any snippets for me, to solve this problem.
cheers

Determining the order of the items in the Quick Launch toolbar programmatically is going to be inherently fragile. There's not an API exposed for this, which means that it's subject to change in future versions of Windows, breaking your code that relied on assumptions about undocumented implementation details.
However, this is less of a problem in this specific case than it normally would be, since the Quick Launch toolbar doesn't exist anymore (or, at least, no one uses it anymore). The last version of Windows that used the Quick Launch toolbar was Vista, so if you make sure that your code is compatible with Vista and earlier, you should be fine. It won't work with newer versions anyway.
The positions of items in the Quick Launch toolbar is stored in the Registry in the following key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Streams\Desktop
You can extract the information from there, parse and interpret it, and then use it as you like. As you mention, this information isn't stored in plain text form because that would be very slow for the shell to load and parse itself. Since this is undocumented and not designed to be used by clients, they had no particular benefit in making it user (or developer) friendly. All that matters is what's most efficient for the shell, and storing the binary information from its internal structures is the obvious choice.
You will need to reverse engineer this in order for it to be useful to you. The way I'd go about it is probably by setting up a test environment with a couple of items in the Quick Launch bar in a particular order, exporting the information from the Registry, moving one of the items around, exporting the updated information from the Registry, and comparing the two exported Registry files to see what changed. Rinse and repeat as many times as necessary to deduce the pattern. (Really makes you wonder why so many developers actually do take the time to reverse-engineer undocumented aspects of Windows, doesn't it?)
The other option would be to use Spy++ to investigate the windows that implement the taskbar and its Quick Launch toolbar. I don't have a pre-Windows 7 system around, but it sounds like from the question that you've already done this and determined that the Quick Launch toolbar is implemented using a standard ListView. If you know the name of that window (and the names of its ancestor windows), you can walk through those windows to obtain a handle to the window you're interested in. And then you can determine the order of the items in the window as if it were a standard ListView in your own application.
The documentation for ListView controls is here; that should get you started in the right direction. You can get the text of one of the subitems by sending the LVM_GETITEMTEXT message.
This is probably the easier way of doing it. The same caveats apply--there is nothing keeping future versions of Windows from changing the names of those windows or the way that the taskbar is implemented, but since the only versions of Windows that have a Quick Launch toolbar have already been released (and therefore aren't likely to change), this may not be a big problem.
Then again, with the fact of the Quick Launch toolbar's obsolescence in mind, I struggle to comprehend why this endeavor is even worthy of investing developer time.
Also, even once you get this program all written and installed, consider what happens when the user adds a new item to the Quick Launch toolbar or re-arranges the existing items. How is your utility going to know that and adjust the keyboard shortcuts accordingly? What if an installer adds/removes an item from the Quick Launch toolbar?

How do I reliably invoke clipboard copy/paste actions in other apps without messing with input queue

A while ago I wrote a simple app, which surrounds selected text in any input field in any application with some unicode symbols when user presses some hotkey. Basically, app's logic is as follows:
Register global hotkey.
Hotkey fired, now set clipboard monitor and invoke clipboard copy to see if some text was selected.
If clipboard has changed and now contains text, surround said text with symbols and then invoke clipboard paste, so input field will be updated with modified text.
The problem is, I can't get copy/paste functionality from other apps in a reliable way. What I have tried to date:
If I send WM_COPY/WM_PASTE, it's more often ignored than not, depending on the application.
If I use SendInput, keybd_event or any other keyboard-messing stuff to press/unpress usual clipboard hotkeys, it will often tamper with user-pressed keys: copy/paste uses control or shift, which are also quite popular for all generic hotkeys in all apps, my app included.
If I use Journal Hook to directly inject keyboard messages into system input queue, sometimes it will work fine, and sometimes weird glitches will occur. Also, other applications may be using JournalHook for themselves, and that will mess my app badly. Not to mention that default security policies make journal hook hard to use.
I've been trying to get/set text in the input fields using Windows UI automation instead of clipboard magic, but it rarely works.
So, if you know other ways to make other applications reliably use copy/paste functionality, or can even devise entirely different approach, I'd really appreciate you telling me :)

I think your approach isn't that bad, maybe you can start with WM_DRAWCLIPBOARD so you can monitor the clipboard. A nice sample code can be found here.
Next I'd take a look at SendKeys class - Attention: Flush, Buffer, etc. Use this to send ctrl+c/v instead of a windows message! You should get a notification from your monitor if it worked.
Now I'd use the Cliboard class to maniplulate the Data and paste it back.

Oh, it seems that I could only find more or less reliable way of invoking copy-paste without SendInput or journal hook, but I have to deal with it :-) So here it is, in case someone find it useful:
Remember and reset keyboard modifiers via AttachThreadInput(yourAppThreadId, targetAppThreadId) + SetKeyboardState(keyStateWithoutKeyboardModifiers).
Set Ctrl key modifier via SetKeyboardState(keyStateWithControl) for Ctrl+C/V hotkey.
Then PostMessage to focused control handle with WM_KEYDOWN message for C or V key, whether you want it to copy or paste.
Call Thread.CurrentThread.Join(20) to let other app process messages — and that's the most retarded moment in the whole deal, since I couldn't find the sure way to know when other app will have empty message queue.
Restore remembered keyboard modifiers.
Also, every time you do SetKeyboardState, call SetForegroundWindow(focusedControlHandle) and SetFocus(focusedControlHandle) afterwards.

C# GUI macro libraries or general approaches?

In a C# WinForms application (on .NET 3.5, probably 4.0 soonish), how would you go about allowing the user to define their own macros? For instance, a user could want the key press CTRL+K to mean clicking a certain item in the menu, and entering some text in the dialog opened by the menu, before pressing "Ok" to close the dialog.
Ideally, our software could provide a macro-recording functionality, that would enable a user to just start recording, perform the desired tasks, and the stop recording to have a macro available. This a feature that they are used to from the old version of the software, that was written in FoxPro, a tool that has such capabilities built-in.
The best option for us would clearly be acquiring and utilizing a tried and tested third party library of some sorts, but ideas for rolling our own version are also appreciated.

If I were working on something like this, I would perhaps integrate a general purpose eventhandler to log events that you want to be recordable ( perhaps either as an individual handler added to available buttons or by creating a RecordedEventHandler class to extend EventHandler and then subclassing all your event handling from that - these are just top-of-the-head ideas so I haven't looked into which would be most viable ) and just use the "record macro" button as a switch for that. There are only likely to be a few different types of event that need to be recorded - button clicks, keyboard input on any text fields, keyboard shortcuts and mouse input on any mouse-input fields so it's not an enormously taxing task although of course working out how to store and bind macros and how to facilitate import and export if you were inclined to do so is time consuming but not technically challenging. I don't know of any libraries for this purpose ( although I expect some exist ) and thinking about it I'm not sure how easy it would be to integrate something like that because most peoples' needs in terms of macros are likely to be different.
If you needed to be able to log events around your application then you may find the ManagedWinApi to be helpful.

I have good experience with "command design pattern" for macro-recording functionaly. Every command fire some application-wide (static for example) event with informations abou parameters etc... The recorder listen to this event and persist the sequence of command calling.