sendkeys

[Paul Mars]

Is this still a no no in Access 2002 using 2000 file format? It was in
A2k.

How would I code this without SendKeys?

SendKeys {F11} 'to activate hidden db window

and

lstQueryList.SetFocus
SendKeys {Down} 'to select the first item in list

 

[Allen Browne]

AFAIK, they never fixed the problem where it messed with the NumLock key.

Sendkeys is always a last ditch thing anyway: stuffing something in the
keyboard buffer and hoping it finishes up being captured by the right window
of the right program is not the most reliable programming method.

For activating the hidden db window, use SelectObject:
DoCmd.SelectObject acForm,,True

For selecting the first item in a list box, set its value to .ItemData(0)

 

[Paul Mars]

Thanks Allen,

I am taking an Access course at my local college and they are teaching us
all sorts of bad things, as:
Using SendKeys
Object names with spaces
Using Functions for code that returns no value, in place of using subs.
p

 

[Tim Ferguson]

I am taking an Access course at my local college and they are teaching us
all sorts of bad things, as:

.... find a new course. Preferably led by someone who does know what he or
she is talking about.


Tim F

PS Using void functions is necessary if they are going to be called from
the GUI, e.g. in a Macro RunCode instruction, or directly from a form event
property. But in nearly every case there are better ways round.

 

[Dirk Goldgar]

PS Using void functions is necessary if they are going to be called
from the GUI, e.g. in a Macro RunCode instruction, or directly from a
form event property. But in nearly every case there are better ways
round.

I don't see any problem with functions used for this purpose. What are
your arguments against them?

 

[Paul Mars]

I was taught to use Functions when returning a value, subs otherwise. I do
not understand that void functions...GUI...

 

[John Spencer (MVP)]

If you have a button in the menubar and want it to do something, you MUST use a
function. You can not use any returned value.

A "void" function is (I assume) a function that doesn't return a value.

 

[Allen Browne]

To hide the database window, make sure it has focus, and:
RunCommand acCmdWindowHide

The RunCommand constants are not well documented, but Terry Wickenden has a
list at:
http://www.tkwickenden.clara.net/

 

[Allen Browne]

You are correct that functions return a value, whereas subs do not, but it
does not follow that you should use a sub if you do not plan to return a
value.

There are other valid reasons to choose a function, e.g. so that you can use
it directly in one of the event properties (which accept functions, not
subs).

Ultimately it comes down to a matter of style. I almost never write a sub
(other than the built-in event procedures), and generally return something -
True on success if nothing else is obvious. Even though the calling code
will probably ignore the return value, it can help with debugging, and you
may want to know if the thing worked one day.

Simple example: if you were writing something to open a report, would you
use:
Sub OpenTheReport()
give error 2501 if it failed? Or would it be a better interface to code:
Function OpenTheReport() As Boolean
Then if the user does not care if it opened or not, they use:
Call OpenTheReport
and if they want to take action depending on whether it opened, the use:
If OpenTheReport() Then ...

 

[TC]

I don't see any problem with functions used for this purpose. What are
your arguments against them?

My view is, make things as simple as possible. Don't say Public if Private
will do. Don't say Function (implying that it returns a meaningful value
that the caller will want), if Sub will do (clearly stating that it >won't<
return a value at all).

I realize there are cases where you have to use functions for implementation
reasons - eg. using them in control properties. But personally, it wouldn't
even occur to me to use a function, in other cases, unless it had a
meaningul return value that the caller will more-than-likely need to
examine.

Cheers,
TC

 

[Dirk Goldgar]

My view is, make things as simple as possible. Don't say Public if
Private will do. Don't say Function (implying that it returns a
meaningful value that the caller will want), if Sub will do (clearly
stating that it >won't< return a value at all).

I realize there are cases where you have to use functions for
implementation reasons - eg. using them in control properties. But
personally, it wouldn't even occur to me to use a function, in other
cases, unless it had a meaningul return value that the caller will
more-than-likely need to examine.

I agree in principle, but since Access doesn't let me use a Sub in
control properties, the Eval() function, or as an argument to RunCode, I
find there are times when I'll define a "logical Sub" as a Function. So
far, I can live with my conscience.

 

[TC]

(snip)

So far, I can live with my conscience.

*** BUT SO COULD ID AMIN, DIRK !!!! ***

(Sorry, had to say it)

Cheers,
TC
(off for the day)

 

[Dirk Goldgar]

(snip)


*** BUT SO COULD ID AMIN, DIRK !!!! ***

Great. I haven't finished my coffee yet, and already I'm being compared
to Idi Amin.

 

[Allen Browne]

Back to SelectObject again.

 

[Paul Mars]

book code:

Private Function PreviewQuery()
DoCmd.OpenQuery [QueryList], acViewPreview
End Function

Private Sub Form_Load()
[QueryList].SetFocus
SendKeys "{Down}"
End Sub

I have successfully replaced the Function with a Sub and the Form_Load with:

QueryList.Selected(0) = True