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

SendKey Problems with Vista

P: n/a
JV
I am running a large Access 2000 application (installed using Access Runtime) that uses many VB SendKeys, primarily to expand combo boxes On Enter.

When trying to run it on Vista I get a "Permission denied" (error 70) error whenever entering a combo box. I have already changed the shortcut that starts access and opens the database to "Run as Administrator". I also changes msaccess.exe itself to "Run as Administrator".

I also tried using a macro to execute the SendKey action. It doesn't blow up, but neither does it expand the list.

Anyone else runn across this behavior? Any ideas how to correct it?

TIA,
John
--------------= Posted using GrabIt =----------------
------= Binary Usenet downloading made easy =---------
-= Get GrabIt for free from http://www.shemes.com/ =-

Mar 8 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a

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.

Mar 8 '07 #2

P: n/a
SendKeys should always, always, always be the tool of last resort! As
storrboy said, for the combo boxes dropdown use the combo box dropdown!

Private Sub YourComboBox_GotFocus()
YourComboBox.Dropdown
End Sub

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000

Message posted via http://www.accessmonster.com

Mar 8 '07 #3

P: n/a
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.
Mar 9 '07 #4

P: n/a
>
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.
Spot on.

I did just notice the same kind of behavior while testing my original
response. The KeyPress event seems to be ignored for (at least one of)
the arrow keys.
If KeyCode = vbKeyDown Then Me!Text0.Dropdown
works in the KeyDown event but,
If KeyAscii= vbKeyDown Then Me!Text0.Dropdown
does not work in the KeyPress event. It just moves to the next control
on the form.

I imagine there will be (are) cases where SendKeys is required, but
luckily I haven't had one, and I would still find away to avoid it
before relenting.

Mar 9 '07 #5

P: n/a
On 8 Mar 2007 14:22:02 -0800, "storrboy" <st******@sympatico.ca>
wrote:

That method is good, but better yet is to not change the behavior of
basic UI elements. Dropdowns don't dropdown on enter. Trying to make
it so, and YMMV.

-Tom.

>
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.
Mar 9 '07 #6

P: n/a
salad <oi*@vinegar.comwrote in news:ni1Ih.10543$Jl.4566
@newsread3.news.pas.earthlink.net:
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.
Many of us have developed many Access applications since Access 2.0 without
ever using SendKeys. I am one.

Regardless of my long experience I try never to say, "There is no way
.....". I find that, "I have not found a way ...." is likely to be more
accurate.

Almost all of the complaints about not being able to do things with
Access/VBA/JET, and requests for special and unusual procedures that I see,
begin with, "I am in the swamp, having stumbled here without much thought
ot preparation, and I now need the genie of the Access bottle to deal with
the alligators." Sometimes there are genies; more often it's a better plan
to get out of the swamp.
Mar 9 '07 #7

P: n/a
On Thu, 08 Mar 2007 22:01:27 -0700, Tom van Stiphout <no*************@cox.netwrote:
>That method is good, but better yet is to not change the behavior of
basic UI elements. Dropdowns don't dropdown on enter. Trying to make
it so, and YMMV.

-Tom.
Yet one feels that Microsoft could easily decide to change this behaviour, as
they have with many aspects of the OS UI. Dropdown on hover is the way things
seem to be going.

Mar 10 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.