By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,985 Members | 1,712 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,985 IT Pros & Developers. It's quick & easy.

Automation, disabling keystrokes/mouse

P: n/a
TR
Hi,
We have some code that uses automation to create/manipulate word
documents. This runs in a batch mode, generating dozens of documents in
sequence. The code works great, but while the automation code is working
in word, care must be taken not to "interrupt" it with a keystroke or
mouse-click, otherwise the current selection gets put somewhere its not
supposed to be, and subsequent code will fail. This means that while it
is running, the PC it is running on is effectively out of service.

Is there a way to disable the word application from receiving any input,
such that the PC can continue to be used without risking someone
clicking into the automated instance?
Thanks,
Tom

Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
TR wrote:
Hi,
We have some code that uses automation to create/manipulate word
documents. This runs in a batch mode, generating dozens of documents in
sequence. The code works great, but while the automation code is working
in word, care must be taken not to "interrupt" it with a keystroke or
mouse-click, otherwise the current selection gets put somewhere its not
supposed to be, and subsequent code will fail. This means that while it
is running, the PC it is running on is effectively out of service.

Is there a way to disable the word application from receiving any input,
such that the PC can continue to be used without risking someone
clicking into the automated instance?
Thanks,
Tom


If I were you, I'd write Word Macros to manipulate the document without
resorting to keystroke poking. Google "SendKeys" for hundreds of
warnings about the dangers of this unreliable method of automatation.

Sorry if it's not the answer you want to hear but anyone who helps you
down that particular route is not helping you at all (apart from helping
you dig a hole for yourself). I've seen keystrokes destined for a
partcular app get directed into Windows Explorer, with cut and pastes
going on it was a hair raising time.

Nov 12 '05 #2

P: n/a
On Wed, 25 Feb 2004 19:32:32 +0000, Trevor Best <nospam@localhost> wrote:
TR wrote:
Hi,
We have some code that uses automation to create/manipulate word
documents. This runs in a batch mode, generating dozens of documents in
sequence. The code works great, but while the automation code is working
in word, care must be taken not to "interrupt" it with a keystroke or
mouse-click, otherwise the current selection gets put somewhere its not
supposed to be, and subsequent code will fail. This means that while it
is running, the PC it is running on is effectively out of service.

Is there a way to disable the word application from receiving any input,
such that the PC can continue to be used without risking someone
clicking into the automated instance?
Thanks,
Tom


If I were you, I'd write Word Macros to manipulate the document without
resorting to keystroke poking. Google "SendKeys" for hundreds of
warnings about the dangers of this unreliable method of automatation.

Sorry if it's not the answer you want to hear but anyone who helps you
down that particular route is not helping you at all (apart from helping
you dig a hole for yourself). I've seen keystrokes destined for a
partcular app get directed into Windows Explorer, with cut and pastes
going on it was a hair raising time.


TR didn't say anything about using SendKeys, the quesiotn was how to prevent
the user from typing/clicking so as to alter the state of MS Word in a way the
code doesn't expect while the code is in progress. Personally, I just don't
make the MS Word application visible while doing automation, but I don't know
if that's an option here.
Nov 12 '05 #3

P: n/a
TR
Hi Steve,
Your assessment is correct.
My first inclination was to hide it as well. I have tried hiding the window, but
the process failed. This is code I have inherited, so I am still becoming familiar
with it. I'll try some more debugging to see if I can find what portion of the
code requires/expects the window to be visible, then maybe I can alter it to work
while hidden.
Thanks,
Tom

Steve Jorgensen wrote:
On Wed, 25 Feb 2004 19:32:32 +0000, Trevor Best <nospam@localhost> wrote:
TR wrote:
Hi,
We have some code that uses automation to create/manipulate word
documents. This runs in a batch mode, generating dozens of documents in
sequence. The code works great, but while the automation code is working
in word, care must be taken not to "interrupt" it with a keystroke or
mouse-click, otherwise the current selection gets put somewhere its not
supposed to be, and subsequent code will fail. This means that while it
is running, the PC it is running on is effectively out of service.

Is there a way to disable the word application from receiving any input,
such that the PC can continue to be used without risking someone
clicking into the automated instance?
Thanks,
Tom


If I were you, I'd write Word Macros to manipulate the document without
resorting to keystroke poking. Google "SendKeys" for hundreds of
warnings about the dangers of this unreliable method of automatation.

Sorry if it's not the answer you want to hear but anyone who helps you
down that particular route is not helping you at all (apart from helping
you dig a hole for yourself). I've seen keystrokes destined for a
partcular app get directed into Windows Explorer, with cut and pastes
going on it was a hair raising time.


TR didn't say anything about using SendKeys, the quesiotn was how to prevent
the user from typing/clicking so as to alter the state of MS Word in a way the
code doesn't expect while the code is in progress. Personally, I just don't
make the MS Word application visible while doing automation, but I don't know
if that's an option here.


Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.