storrboy wrote:
SendKeys is a problem in any version/OS.
If you can make design changes I would highly recommend replacing them
with something else.
For instance, a combobox has a Dropdown method that does the same
thing.
I've used Sendkeys, not in many places, just where MS inhibits a person
from doing something except create a stupid kludge.
For example, there is no way to trap pressing the X button. MS stupidly
processes the BeforeUpdate event which I might want to cancel if the
validation doesn't pass. So MS presents a stupid error message if its
an error 2169 (can't remember what it is). You can use the Unload event
to cancel the close but only for an existing record. If you cancel at
the unload event on a new record, it leaves you with a blank record. I
would think that if I canceled the BeforeUpdate event, the X close event
(not trappable) would abort.
In a couple of places I wanted to remove what the op entered in a text
box in the BeforeUpdate event if it fails validation. I might have
something like
Cancel = True
Me.TextBox1.Undo
SendKeys "{Del}"
and it clears it out. I would think the Undo would clear the data
entered by the op but it doesn't.
I see NO REASON why the OS should stop someone from using Sendkeys.
Sure, there's security reasons. MS has gotten to the point one is
warned about using their own apps to open another of their apps...like
Outlook. For bypassing their security problems I use ClickYes written
by Sue Mosher.
http://www.contextmagic.com/express-clickyes/. I wonder
if that too has been disabled.
If I write a program for XYZ Company I think the USER, not MS, should
determine the security. They should be able to tag the apps that are
trusted. So if I give someone a program, since it's not in the trusted
table, it will produce the MS sec warnings. The person tags it as
trusted. Then it doesn't produce the sec warnings. I see no reason for
creating certificates for someone I'm doing custom work for. That puts
the burden on the developer. Put it on the user.
