SendKeys action requires Microsoft Office Access Utility Add-in to

[Guest]

Using a macro which utilises the SENDKEYS Action produces the error message:

SendKeys action requires Microsoft Office Access Utility Add-in to be loaded

I have tried completely re-installing Access 2003 with no effect. Can
anyone suggest where I find the Access Utility Add-in.

I have listed the Macro below in case it is due to the construct of that:

Hourglass: On: Yes
SetWarnings: On: No
SendKeys: Keystrokes: STR321~
Wait : No
SendObject: Object Type: Report
Object Name: Consumables Report
Output Format: Snapshot Format
To: BaxtRos (a valid email address)
Cc:
Bcc:
Subject: Consumables Report
Message Text: Please find Consumables Report
Edit Message: No
Template File:

 

[Steve Schapel]

Martin,

I do not know why you are getting this error message. But in any case,
most experienced Access users avoid using SendKeys like the plague. It
is always trouble-prone, and as far as I know there is normally another
way to achieve the same thing. Can you explain what you are trying to
do with the SendKeys action, and someone may be able to suggest an
alternative approach.

 

[Guest]

Hi Steve

I am raising the question on behalf of one of our Finance Dept users who
created a number of macros using SENDKEY back in Access 97 and converted them
to 2003.

She runs a number of reports filtered by a User-entered parameter with the
data extracted respective to the parameter supplied.

In order to automate this she created a number of macros which effectively
run many versions of the same reports but with different parameters supplied
for each.

Does this help identify a solution?

Thanks

Martin

 

[Steve Schapel]

Martin,

Thanks for the further explanation. However, I am still in the dark as
to what the 'STR321~' is supposed to do.

I would guess that "user-entered parameter" means a criteria entered
into an unbound textbox on a form? On the basis of which the data
returned to the report is selected? Therefore she could probably just
reference the textbox, using syntax such as
[Forms]![NameOfForm]![NameOfTextbox] in the criteria of the query that
the report is based on.

 

[Guest]

Hi Again

As you say, STR321~ would normally be entered into a dialog box when the
Query behind the report is run because the query has the following in the
Criteria of one of the fields:
Like [Roll up GRP] & "*"
Where '[Roll up GRP]' is an expression created within the query.

As mentioned previously, she could manually enter this value in the Dialog
box each time but she needs to run many versions of the report and email each
to a different person. So the simplest method was do it via a macro.

I may have not made it clear but the sample text I provided from the macro
originally is one block which is repeated many times with different values to
STR321~ and different email addresses, such as: SOU001~ and KayAnd.

I presume it could be done using VB using a table to provide the criteria
data but neither her nor my VB skills are that good. ALso she has created
quite a few similar macros which would all need converting.

One final point, her colleague who is running the same version of Access
right down to the sub-version is able to run these without getting the Error
message. So it may not be a SENDKEYS issue but an erroneous error message.

Martin

Martin,

Thanks for the further explanation. However, I am still in the dark as
to what the 'STR321~' is supposed to do.

I would guess that "user-entered parameter" means a criteria entered
into an unbound textbox on a form? On the basis of which the data
returned to the report is selected? Therefore she could probably just
reference the textbox, using syntax such as
[Forms]![NameOfForm]![NameOfTextbox] in the criteria of the query that
the report is based on.

--
Steve Schapel, Microsoft Access MVP

Hi Steve

I am raising the question on behalf of one of our Finance Dept users who
created a number of macros using SENDKEY back in Access 97 and converted them
to 2003.

She runs a number of reports filtered by a User-entered parameter with the
data extracted respective to the parameter supplied.

In order to automate this she created a number of macros which effectively
run many versions of the same reports but with different parameters supplied
for each.

Does this help identify a solution?

Thanks

Martin