I notice that your program, has the ability to paste directly into the Active application.
That takes a bit of doing, as the clicking of the systray, steals the focus (Active'ness), and Windows does not place the focus (Active'ness) back to the previously Active Window, when the clicked systray program hides itself.
No doubt some API's are involved, to accomplish that feat.
Could you list those for me.
-RobC
The problem you describe totally applies. There are many ways of activating the app - via the hotkey, click on the task bar icon, click on the "tray" (notification area) icon, alt-tab or mouse click in the program window. AFAIK, there is no solution that can handle all these cases. At least in Delphi, the earliest notifications the app receives about being activated come too late, when the previously active app is already inactive. As you found out, the best you can get in some cases is the tray window, not the previously focused application.
My idea was to give up. I don't try to detect what app was active, since it is doomed to failure most of the time. Instead, I let Windows figure it out, since this is what Windows does anyway. When user pastes a clip in Echo, Echo de-activates and hides itself, then sends a sequence of keypresses. These keypresses go to whatever window becomes active after Echo disappears. This happens to be the application that was active at the time Echo was invoked.
Now, I realize that *theoretically* this may not always be the case. Another app might pop up a window while user is working in Echo. However, I have not experienced this even once in over a year of using Echo myself, and I've had no bug reports to that effect. It helps that in recent versions of Windows inactive applications are not permitted to grab focus.
So far I've only had one issue with my non-solution: applications that actively refuse to regain focus. One such app was
reported earlier in this thread. What happens is:
1. App X has focus
2. User invokes Echo and pastes a clip.
3. Echo minimizes...
4. ...but app X does not regain focus, even though it is again the foreground app.
It's important to realize that the problem in (4) happens because app X is specifically designed not to grab focus (and you can't switch to it via alt+tab, for example). Such apps are thankfully rare.
The only thing I could do in this case was to give up again and add a check for the active application, the check that doesn't really work. Well, in Echo it does work if user activates Echo using the global hotkey, but not when Echo gets activated in any other way. So Echo doesn't rely on this value. If Echo is activated via hotkey *and* it can get a window handle that is not the desktop, then it will try to make that handle foreground before pasting the clip. It seems to be working with "Stickies" (the problem app in this case) and doesn't hurt anything, as far as I can tell.
Other than such odd-behaving apps, my non-solution seems satisfactory.
On edit, forgot to add: I know that some similar apps try to monitor the focused window changes as they happen. I haven't even explored this possibility, because my personal "prime directive" is to do as little as necessary to get the desired result. When Echo sits idly in the tray, it is really idle; I don't like the idea of constantly monitoring what other windows are doing. It would require either a very frequently firing timer (which would often miss, anyway) or installing a system hook. Either way is too intrusive for my liking.