SendKeys and window focus problem

Sometime ago I wrote a clipboard management program for cutting and pasting
text. The program uses keys other than ctrl-c ctrl-v. If a hot key is
pressed, the window in focus and window in foreground are saved, the
clipboard management screen comes up, and after choosing what to do focus
and foreground are set back where they were and ctrl-c or ctrl-v are sent
with SendKeys.

I am also doing java now and often write VB utility programs to help me
work. I need to extract text from many JSP pages, place that text in a
resource file, and leave behind a bean:message tag in the JSP. To do this I
wrote a VB program and it works similar to the clipboard management program
described above. Removed text is placed in a database and an incremental
bean:message tag is put in its place, in the java IDE. Whatever text is
highlighted in the java IDE, the hot key is pressed, and like magic the
bean:message tag is substituted.

There is a problem, though. For my new program to work an interceding VB
screen must appear. I cannot just press the hot key and have the text change
in the java IDE. I must save current focus and foreground windows, present a
form, click on the form, and have an event do the text substitution into the
java IDE. I want to get rid of the intervening VB screen.

I tried sending keystrokes with SendMessage to the java IDE. The window in
focus or window in foreground must not be the correct window, or I would
have to examine child windows to see which should receive the SendMessage.
Rather than waste too much time on that I decided to go back to the
intervening VB screen.

The problem is thread, I think. The hot key triggers the VB screen in one
thread, but the same thread cannot be used to do the text substitution.
Clicking on the VB screen creates another thread which works. I also tried
using PostMessage hwnd,0,0,0 to the form receiving the hot key and that
makes no difference.

I will try using a timer instead of putting the VB screen up, but is there
something else I can do? Thanks

David McDivitt wrote:
> There is a problem, though. For my new program to work an interceding VB
> screen must appear. I cannot just press the hot key and have the text chan
ge
> in the java IDE. I must save current focus and foreground windows, present
 a
> form, click on the form, and have an event do the text substitution into t
he
> java IDE. I want to get rid of the intervening VB screen.

What does the intervening VB screen do?... I'm having a hard time
figuring out the functionality. When you click on that form, are you
clicking on some canned text or something? Are hotkeys the reason your
screen needs to be showing? (hopefully, you're asking about VB5/6 and
not B#). fwiw, I built a "SnagIt" replacement using some of the code
from this sample.

System-Wide Keyboard Trapping with RegisterHotKey
http://vbnet.mvps.org/index.html?co...isterhotkey.htm

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

>From: David McDivitt <x12code-del@del-yahoo.com>
>Subject: SendKeys and window focus problem
>Date: Thu, 28 Oct 2004 09:28:01 -0500
>
>Sometime ago I wrote a clipboard management program for cutting and pasting
>text. The program uses keys other than ctrl-c ctrl-v. If a hot key is
>pressed, the window in focus and window in foreground are saved, the

Using a timer worked. When I set the timer at 100ms, only the first two text
substitutions would work, then ctrl-c ctrl-v would no longer get through to
the java IDE. One of the java IDE menu items kept getting invoked instead.
If I use 500ns for the timer everything works OK. Why the difference? Use of
the timer means a new thread. I'd like to know what Windows is doing so I
can emulate that and not use the timer, or is a timer the only way?

David McDivitt wrote:
> Using a timer worked. When I set the timer at 100ms, only the first two te
xt
> substitutions would work, then ctrl-c ctrl-v would no longer get through t
o
> the java IDE. One of the java IDE menu items kept getting invoked instead.
> If I use 500ns for the timer everything works OK. Why the difference? Use 
of
> the timer means a new thread. I'd like to know what Windows is doing so I
> can emulate that and not use the timer, or is a timer the only way?

Timers don't run on their own thread.


--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

>Subject: Re: SendKeys and window focus problem
>Date: Thu, 28 Oct 2004 08:40:38 -0700
>
>David McDivitt wrote: 
>
>What does the intervening VB screen do?... I'm having a hard time
>figuring out the functionality. When you click on that form, are you
>clicking on some canned text or something? Are hotkeys the reason your
>screen needs to be showing? (hopefully, you're asking about VB5/6 and
>not B#). fwiw, I built a "SnagIt" replacement using some of the code
>from this sample.
>
>System-Wide Keyboard Trapping with RegisterHotKey
>http://vbnet.mvps.org/index.html?co...isterhotkey.htm

Ken,

I do not use the intervening VB screen anymore, but a timer. Text
replacement processing must happen in a different thread than the one
associated with the hot key. I would like everything to happen in the same
thread if possible, but freeing up the hot key thread is probably a good
idea, since text processing involves a database. Though quick it may hang or
be slow because of external resources beyond control.

>Subject: Re: SendKeys and window focus problem
>Date: Thu, 28 Oct 2004 09:12:55 -0700
>
>David McDivitt wrote: 
>
>Timers don't run on their own thread.

It is different event thread, then, and not a different processor thread.
Maybe I used the wrong term. I use timers all the time to start new event
threads. It is the same as clicking a button and firing on the button.

I would like my text substitution program to do everything in the hot key
event if possible.

David McDivitt wrote:
> It is different event thread, then, and not a different processor thread.
> Maybe I used the wrong term. I use timers all the time to start new event
> threads. It is the same as clicking a button and firing on the button.

Here's a little bit about how an event works (exactly the same as
calling a sub)

Subject: Re: Ideas for asynchronous calls in VB6
http://groups.google.com/groups?sel...br />
t=gplain

> I would like my text substitution program to do everything in the hot key
> event if possible.

fwiw, I used that 'System-Wide Keyboard Trapping with RegisterHotKey'
sample to create my app that runs in the system tray. Unless there's
something on that form that you need to pick from, I'm not seeing a
reason for the form (still don't quite have a grasp of what your app
does... any similar commercial apps to compare it to?)

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

>From: Ken Halter <Ken_Halter@Use_Sparingly_Hotmail.com>
>Subject: Re: SendKeys and window focus problem
>Date: Thu, 28 Oct 2004 12:59:40 -0700
>
>David McDivitt wrote: 
>
>Here's a little bit about how an event works (exactly the same as
>calling a sub)
>
>Subject: Re: Ideas for asynchronous calls in VB6
>http://groups.google.com/groups?sel...r />
ut=gplain
> 
>
>fwiw, I used that 'System-Wide Keyboard Trapping with RegisterHotKey'
>sample to create my app that runs in the system tray. Unless there's
>something on that form that you need to pick from, I'm not seeing a
>reason for the form (still don't quite have a grasp of what your app
>does... any similar commercial apps to compare it to?)

What the app does is use a system-wide hot key similar to what you describe.
In any open window, if that window has copy and paste functionality with
ctrl-c/ctrl-v, my app will do text substitution. The user highlights text,
presses the hot key, and highlighted text is replaced with something else.

The problem is doing the text substitution in the hot key routine. It's
necessary to let that thread (execution sequence) finish, then start a new
thread. Otherwise ctrl-c/ctrl-v will not go to the correct window if
SendKeys is used. In the hot key thread I save the current focus and
foreground windows. At that point a form can be thrown up, so when clicked a
new thread (execution sequence) can start, or a timer can be used to start a
new thread. I was using a form. Now I'm using a timer. Having the timer fire
at 100ms is too short a time and SendKeys works intermittently. No problem
is noticed using 500ms. The reason the form worked earlier is because it
took more than 500ms to do the hot key, then click the form with the mouse.

About threads or execution sequences, I successfully made a control to work
with Microsoft Access. When used in a VB application the control worked OK,
but if mounted on a Microsoft Access form it would not. The control works by
firing events to request information. When a method is called on the
control, the control in turn fires events back into the form that called it.
In Microsoft Access the code is locked and nothing can break into it. In VB
this is no problem. To solve the Microsoft Access problem a timer was placed
on the control, and a whole set of duplicate methods was made available.
Each of the duplicate methods on the control does nothing but set the timer,
then returns to the caller, allowing that thread to end. When the timer
fires it executes whatever method was intended. Because code is not
executing in Access at that time, it is not locked, and events fired by the
control are serviced. In Access, even if code is waiting on a subroutine
return, it is locked, and no events can be serviced until that thread or
execution sequence has finished.

I think the problem I was having in my text substitution program is because
the operating system state is in transition during the hot key thread. It is
necessary to let the thread finish, then processing performed in a new
thread. What I don't understand is why there's a difference between 100ms
and 500ms, since how long to wait before a new thread is started should not
matter, but whether processing is done in a new thread.