sendkeys

  • Thread starter Thread starter Paul Mars
  • Start date Start date
P

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
 
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)
 
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
 
I am taking an Access course at my local college and they are teaching us
all sorts of bad things, as:
Click to expand...

.... 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.
 
Tim Ferguson said:
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.
Click to expand...

I don't see any problem with functions used for this purpose. What are
your arguments against them?
 
I was taught to use Functions when returning a value, subs otherwise. I do
not understand that void functions...GUI...
 
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.
 
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 ...
 
Dirk Goldgar said:
I don't see any problem with functions used for this purpose. What are
your arguments against them?
Click to expand...


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
 
TC said:
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.
Click to expand...

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.
 
-----Original Message-----
To hide the database window, make sure it has focus,
Click to expand...

'nuther dumb question: how do I do that?

Tried Application, Windows, CurrentProject, CurrentDB,
etc. and can't find a Windows object to grab.

TIA,

Terrell
 
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
 
Back
Top