Printable View
Hi All,
How can I return the selected (highlighted) word/text from any given application?
Eg. I select a word in Excel (or Outlook, Access, Visio etc) and upon a click of a Button, I MsgBox the word.
I'm gussing a global (system wide) hook of some kind.
Cheers.
Hmmmm... If I understand your question correctly you work in one application and select something in that and then you want to click a button in another app and that should know what you have selected in the app you worked in just before you clicked the button... Is this correct?
You can set up OLE to connect two apps.
I have a sample that I can post.
G'Day Joacim & David :wave:
@ Joacim, I think you have it... :) To put in proper perspective, my app sits in the SysTray, if you highlight a word from say Excel, when the SysTray icon is double clicked, the word is displayed.
I know that if you selected text in one app (not your own) then set the focus to your app, the selected (highlighted) text/word 'appears' to loose focus, hence the Hook requirement.
I know this may be impossible, but hey :).
Cheers.
Well, nothing is impossible but there are a few things that are very hard to do. Just think about it.... Let's say I have made a little application that has 3 text boxes and a treeview and also a listview (or whatever). Now I've set the HideSelection property to false on all of these controls which means you can select text in 3 different textboxes one treeview and in one listview. Now I click on your icon in the Systray and I want it to return what ever I've selected in my program.... Which is 5 different things.... So your app should return what????
Point taken.
I can work on that. The trouble is getting just anything returned.
For what its worth, its a Spell Checker that runs in the SysTray.
I can select a word that I suspect is wrong, currently by copying it to the ClipBoard and dbl click my Icon (in the SysTray), the word is checked against M$Word SpellChecker().
The corrected word (if relavent) is then placed onto the ClipBoard for insertion.
This is all up and running quite well. I just wanted to go one step further, and cut out the inital manual copy step. Therefore, select the suspect word, have the Spell Check check the slected word....
This might be a bit hard to figure out. You could try to monitor which window and control currently has focus and when your icon is clicked send WM_COPY to that window. However all applications you might be able to copy text from doesn't respond to the WM_COPY message, but many does. All edit fields and combo boxes react on this message.
To find out what window has the cursor / focus in it use GetGUIThreadInfo API.
Thanks Guys.
@ Merrion, I'm checking that out :)
Unfortunatly, when you click the SysTray, the (current) App losses focus (being the selected text).
However, when you give focus back to the App, the (previously) selected text is re-shown slected. That said, Windows therefore must know (all the time) what text IS selected (whether the App has the focus or not).
Is there a way then to query 'Windows' for the given App (passing the the Handle of the App in question)?
Cheers.
When an application gains focus it gets a wm_activateapp message.
In this message the wParam is the thread handle of the application that is losing the focus. Pass this handle to GetGUIThreadInfo and you can find out which window in the application that just lost the focus was the one with the input focus.
Thanks Merrion :)
Ok, what I will attempt to do is capture the losing focus app's HWnd, re-focus to that app, (hopefully the selected text will now be re-selected (since getting back the focus))
then use WM_COPY.....
Ok, To begin (intercepting the WM_ACTIVEAPP message) I'm using the following to no avail. The wParam is either a 0 or 1 depending on whether my App has the focus or not:
VB Code:
VB Code:
Could you always hook the active window and check for the WM_LOSTFOCUS message or something like that? To subclass an app that isn't your own : http://www.vbforums.com/showthread.php?t=322261
Yeah, that's because the wParam contains the activation flag (was your application, or rather your window activated or not) while the lParam contains the the thread ID of the application that lost the activtion, or gained the activation, depending on the value you've got in the wParam parameter.
Hi Manavo11, unfortunatly I wouldn't know what will be the active window (as it could be many)
Joacim, Hi, I tried getting the Thread ID using the lParam, but it is the same for all apps ecept mine. I think I'm using the Sub-Class correct - does it work for you?
Cheers,
The problem might be that when the user clicks on your icon in the system tray, the lParam will show the thread that had the focus before which in this case would have been the taskbar itself....
At this stage I am still testing in the IDE, no SysTray icon at this stage. I working on the assumption from Merrion's post that when my app recieves the focus, I can check for the Hwnd that had the focus. I guess that by intercepting the WMessage (when my app gets the foocus), that I can check on of the params, in particular the param that has the leaving apps Hwnd....
Cheers,
OK, when you subclass your Form and check for the WM_ACTIVATEAPP message you will get that every time your Form either lose or gain focus from another thread. So this will sort of work like the GotFocus event for a Form with the difference that the message is sent when your Form gain or lose focus from another application. So the wParam argument will tell you if your Form has gained or lost focus to another thread. While lParam will tell you the the thread ID that lost or gained focus.
The problem here is that lParam is the thread ID and not the hWnd of the app that lost/gained focus.
very intersting question, since i am using my bro user for few question i know that my brother had worked with Babylon.
Babylon is a Dictionary you underlin the word on and app and click on the the wheel button on your mouse and the app will that the word and give you definition. if this thread had not been solved untill my bro comes i can ask him for help
Concur. The problem was I wasn't seeing the reulst until I gave the focus to my App, then minimised it - then the ID changed based on the App that had the focus.Quote:
Originally Posted by Joacim Andersson
Testing to see if the ID's are relavent when my app gets the focus.
Ok, further to my last; why I see the (correct TreadID) result when I minimise, is that once I minimise, the previous app gets back the focus hence the lParam change. This dosn't work
when my app gets the focus, as it is the current tread.
I have unsuccessfully tried different WM_ constants in order to capture the losing focus app ID once my Apps sub-class is envoked.
*bump* :)
When your app regains focus you should get the thread id from the application that lost focus... at least that is what the MSDN Library states. Maybe you need to subclass the ThunderRT6Main window (this window is called ThunderMain when you run the app from the IDE) instead of your Form. VB creates this window as the parent for all other windows in your application. It's not visible but gains the messages before your Form does. You can get the handle to this window via a call to GetWindow, just pass the hWnd of your Form and the GW_OWNER relationship flag.
G'Day Joacim :wave:
I to thought I could get the ThreadID when my app gets the Focus of the losing apps.
The only way I could get that to work was when I minimised my app - it seems that
the ID was received when the focus was going back to the original losing app....
That said, I't dosn't help with my goal as I need the losing apps ID when mine gets the focus (as your aware).
I will try a demo with regard to the VB's ThunderRT6Main. :)
Thanks again,
Bugger! Yeilds the same result (works only when you minimise).
:)
This is from MSDN:
Should work..........................Quote:
WM_ACTIVATEAPP Notification
--------------------------------------------------------------------------------
The WM_ACTIVATEAPP message is sent when a window belonging to a different application than the active window is about to be activated. The message is sent to the application whose window is being activated and to the application whose window is being deactivated.
A window receives this message through its WindowProc function.
Syntax
WM_ACTIVATEAPP
WPARAM wParam
LPARAM lParam;
Parameters
wParam
Specifies whether the window is being activated or deactivated. This parameter is TRUE if the window is being activated; it is FALSE if the window is being deactivated.
lParam
Specifies a thread identifier (a DWORD). If the wParam parameter is TRUE, lParam is the identifier of the thread that owns the window being deactivated. If wParam is FALSE, lParam is the identifier of the thread that owns the window being activated.
Return Value
If an application processes this message, it should return zero.
Notification Requirements
Minimum DLL Version None
Header Declared in Winuser.h, include Windows.h
Minimum operating systems Windows 95, Windows NT 3.1
See Also
Windows Overview, WM_ACTIVATE
Why not try something simplier... Like using SendKeys "%{tab}" (Alt+Tab) to set focus back to the previous application?
hehe, just wanted to avoid any SendKey issues :)
(But, I'm knocking it up now)
Oh bloody hell. SendKeys dosn't want to work from a SysTray Icon (in VB.Net), from a Form Click it's fine (both VB6 and .Net)
Oh yes it will work if you first makes sure you call SetForegroundWindow and pass the hWnd of your Form (even if it isn't visible).
Okey dokey... trying now :)
[crying] Its a catch 22. If I use SendKeys, I must use SetForgroundWindow - then I cant copy the text using SedKeys my app nolonger has the Focus. So, I tried to use GetActiveWindow to be used with say SendMessage (for a Copy), but that too wont work
as my app has the ActiveWindow due to SetForground........ waaahhhhhhh[/still crying - pulling hair]
Ok, new day....
I've actually lost you Bruce... If you've sent Alt+Tab the previous window will have focus so just try to send WM_COPY to the active window and check if the clipboard content changed. If so bring up your window and do your magic....
Hi Joacim,
The GetActiveWindow didn't work post SetForgroundWindow. However, I didn't test WM_COPY - will try.
What I meant is that after you have made a call to GetActiveWindow you should be able to send Alt+Tab. GetActiveWindow will only work if you own the thread of the active window, and since you've alt+tabbed to another process it should fail. If you want the handle of the active window that belongs to another thread you should use GetForegroundWindow instead.
Understood :)
But as merrion pointed out you should use the GetGUIThreadInfo API function to get the handle of the control owning the user input...
Ahhh, I won't use SetForegroundWindow either for the same reason :)
(instead, I'll use SetActiveWindow)
Update:
1. Using SetForegroundWindow to enable the use of SendKeys, always makes my app the return hWnd.
2. If I use SetActiveWindow to overcome this, I can no longer use SendKeys!
3. The delima is If I now use PostMessage to emulate SendKeys (%{Tab}) I would require the hWmd of the now non-focused window..........
Still trying :)
Another idea... Use GetNextWindow (or call GetWindow which does the same thing) with GW_HWNDNEXT to get the next window in the ZOrder.
Will give it a shot.
I must say I was surprised when I couldn't find any posts similar to this (I think the question was answered but no solution). I would be keen to get this up nad running as
others may benifit too.
Thanks for your inputs on this Joacim, I appreciate it :).
Cheers,
Was successful, but flakey :)
I tried many combinations, even to the point of not having to use SendKeys (as the Next Windows hWnd was made available).
Sorry, I stopped reading after the word "successful" :)
:thumb: :DQuote:
Originally Posted by Joacim Andersson
Through sheer determination I revisited the above APIs' - SUCCESS!
In short, and NO Sub-Classing, I used:
SetForeGroundWindow(myApps hWnd)
GetNextWindow(myApps hWnd, GW_HWNDNEXT)
SetForeGroundWindow(retval of GetNextWindow)
Viola....
Clicking the SysTray Icon takes the focus, SetForegroundWindow ensures myApp is ready for GetNext,
then capture the Next hWnd,
Now set the focus back to the losing apps Window......
I will post the entire app in the .Net Forum once done.
I want to keep this un-resolved, as I would like feedback on a Global (Sub-Classed) method
using the WM_ACTIVEAPP as M$ states it should work.
At this stage many, many thanks to Joacim for his persistance :)
Regards,
Initial testing seems OK with Access, Excel.
Joacim, at this stage I cannot 'rate' you as I need to share it around. In the interim, please take ten points outa the bit bucket :)
Bruce.
Beta .Net code now posted here (post #19):
http://www.vbforums.com/showthread.php?t=366585
OK,
I've been playing with this code under VB6 for a while. The method as spelled out in the .Net forum doesn't work in VB6 since the "Next Window" is not the one we are looking for. I find that I have to first iterate through all the "tooltips_class32" windows first.
In addition, once we find the top level window we can't just send a WM_COPY message to that window since we really want the Textbox child of that window. I've been testing on Notepad and EditPadPro. Here is what I've found works so far.Like you, I didn't get the WM_APPACTIVATE code to work, but I think I can so I'll keep working on it.VB Code:
Also I never liked the Word dialog box so I'll adapt my spellchecker to this code. It is in my "RichtextBox Tricks and Tips" thread. That code brings up a context menu with spelling suggestions rather than that ugly Word Box.
Another thought I had was instead of using a task tray icon to activate we could install a global keyboard hook and look for a hot-key. This way we would already have the handle to the edit window.
@moeur, even though I really like the way you where thinking in the above solotion :thumb: there is a huge problem in that logic... The problem itself is well known, using GetWindow in a loop can freeze your app if a user happens to close a window while the loop is running... Even the MSDN Library tells you to not use this approach (and I'm quoting)Quote:
An application that calls GetWindow to perform this task [read EnumWindows] (in a loop) risks being caught in an infinite loop or referencing a handle to a window that has been destroyed.
It's simple enough to put a counter in the loop that exits the loop on too many iterations. In either case you have to work through the windows to get to the one you want.
All I'm saying ís that you should use EnumWindows instead. You can apply your logic in the callback procedure just as well... Please remember: I liked your logic :thumb:
But I don't see how EnumWindows will give us the "Next Window" in Z-order.
Some more comments on this:
WM_APPACTIVATE is not going to work for the task tray icon method because what you'd have to subclass would be the tray.
The method I posted above is still kind of flaky since sometimes there are other windows besides tooltips_class32 windows between your window and the previous window. For instance I've seen a window with a class name "WorkerW".
This method also does not work for things like the VBForums edit box.
I have come up with a robust solution to this problem.
Whenever a top-level window is activated, a global message is sent that can be trapped with a global WH_SHELL hook. If we keep track of which program was activated last, then when our icon is clicked, we have all the info we need.
Instead of having to set a global WH_SHELL hook (which would require C++) we can instead use an API function that Penagate mentioned in another thread called RegisterShellHookWindow. This function directs all shell messages to our window procedure so we just have to subclass our own window.
To set up this functionality, you do something like thisIn this code, I use my subclasser class (clsSubClass) and taskicon OCX control (NotifyIcon) but you can do it any way you would like. Once this is done we will receive the shell messages in our window procedure.VB Code:
What we want to do is keep track of the last window that was activated, so in the window procedureNow the only thing left to do is allow the user to start the spell checking by left clicking on the system tray icon that we added. In this code I call a CheckSpelling function that checks the spelling of the text on the clipboard and returns the corrected results to the clipboard.VB Code:
ok so if u have the text that u need to copy allready selected u can copy it to clipboard with sendkeys.send("{^c}') then u can retrieve it with clipboard.gettext how this is what you are looking for