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

msaccess.exe API calls: where to get the function call description

P: n/a
Hello,

I have a problem with one of msaccess.exe API calls that work on my desctop
but does not work on the laptop from within MS ACCESS. There is a lot of
differences between 2 computers including one running Office 2000 and another
running Office 2003. This code was created by a previous developer. I need to
find the description and parameters of the API calls. I found the article

http://msdn.microsoft.com/library/de...ce03082001.asp

Office VBA and the Windows API
that says that I should use Win32.API.txt that I don't have on my computer or
I should install
The Microsoft Platform SDK, which contains complete documentation for the
Windows API. I installed that, but could not find functions for MS ACCESS.
Please, let me know where to look for the function call description for MS
ACCESS API functions.
Another question is: why this fuction when called from Access 2000 does
accept hexadecimal value and when called from Access 2003 it does not accept
hexadecimal value for the Registry Hive.
Basically I will be grateful for the input format of all parameters. The
function definition is:

Declare Function adh_accRegWriteVal Lib "msaccess.exe" Alias "#71" _
(ByVal hkeyRoot As Long, ByVal strSubKey As String, ByVal strValName As
String, _
lpData As Any, ByVal lngType As Long) As Long

Thanks in advance for any help,

--
Regards,
Yelena Varshal

Message posted via http://www.accessmonster.com
Apr 11 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
"Yelena Varshal via AccessMonster.com" <u15452@uwe> wrote in
news:5ea0d9b8b74a3@uwe:
Basically I will be grateful for the input format of all
parameters. The function definition is:

Declare Function adh_accRegWriteVal Lib "msaccess.exe" Alias "#71"
_
(ByVal hkeyRoot As Long, ByVal strSubKey As String, ByVal
strValName As
String, _
lpData As Any, ByVal lngType As Long) As Long


What are you trying to do here? I can't think of a situation where
I'd ever attempt what you're doing here. If you want to automate
Access, then this is definitely *not* the way to go about it!

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 11 '06 #2

P: n/a
David,

I am working with existing code. The person who created this code does not
work for the company anymore. She used this function to write several entries
into the custom registry key to save application settings on exit. It works
really fine on my desktop with Office 2000. This function is a standard API
call , I posted just the declaration part of it. She calls it from a module
as follows:

rc = adh_accRegWriteVal(adhcHKEY_LOCAL_MACHINE, REGPATH &
"AppKeyName", "Top", .y1, adhcREG_DWORD)

where
adhcHKEY_LOCAL_MACHINE is a pre-defined constant &H80000002 which stays for
HKEY_LOCAL_MACHINE
REGPATH is a pre-defined constant with a path in the registry
AppKeyName is a key name for the registry key
Top is a Value Name
..y1 is a Value Data (this is just a numeric value from a record.

The part that does not work is adhcHKEY_LOCAL_MACHINE. As I say, its value
&H80000002 which is hexadecimal and it works for Access 2000. It does not
work with Access 2003. if I replace this value with the decimal
representation of the same number - 2147483650 then Access adds a pound sign
# at the end of the number an it works in Access 2000.
I was trying to get a feel for the proper syntax for this function and for
how I should enter values.
But if you say I shoul use soemthing else, please, let me know what should I
use from Access module to write to the registry.

Thanks,
Yelena

David W. Fenton wrote:
Basically I will be grateful for the input format of all
parameters. The function definition is:

[quoted text clipped - 5 lines]
String, _
lpData As Any, ByVal lngType As Long) As Long


What are you trying to do here? I can't think of a situation where
I'd ever attempt what you're doing here. If you want to automate
Access, then this is definitely *not* the way to go about it!


--
Regards,
Yelena Varshal

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200604/1
Apr 11 '06 #3

P: n/a
Yelena-
the "adh" at the beginning of the function name makes me think that this
code came from the Access Developer's Handbook, by Getz, Gilbert, and
Litwin. You might look there for clues. (It's a great book, in case you
haven't seen it.)
-John

"Yelena Varshal via AccessMonster.com" <u15452@uwe> wrote in message
news:5ea0d9b8b74a3@uwe...
Hello,

I have a problem with one of msaccess.exe API calls that work on my
desctop
but does not work on the laptop from within MS ACCESS. There is a lot of
differences between 2 computers including one running Office 2000 and
another
running Office 2003. This code was created by a previous developer. I need
to
find the description and parameters of the API calls. I found the article

http://msdn.microsoft.com/library/de...ce03082001.asp

Office VBA and the Windows API
that says that I should use Win32.API.txt that I don't have on my computer
or
I should install
The Microsoft Platform SDK, which contains complete documentation for the
Windows API. I installed that, but could not find functions for MS ACCESS.
Please, let me know where to look for the function call description for MS
ACCESS API functions.
Another question is: why this fuction when called from Access 2000 does
accept hexadecimal value and when called from Access 2003 it does not
accept
hexadecimal value for the Registry Hive.
Basically I will be grateful for the input format of all parameters. The
function definition is:

Declare Function adh_accRegWriteVal Lib "msaccess.exe" Alias "#71" _
(ByVal hkeyRoot As Long, ByVal strSubKey As String, ByVal strValName As
String, _
lpData As Any, ByVal lngType As Long) As Long

Thanks in advance for any help,

--
Regards,
Yelena Varshal

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

Apr 11 '06 #4

P: n/a
Thanks John,

I will check this book, sure!

Do we have any reference for MS ACCEESS API functions? I searched online,
found none.
I did install Platform SDK and in the documentation I found Windows API
reference with the function
RegSetValueEx
but I did not find reference for the msaccess.exe functions, including the
one I am asking about.
I also installed API Viewer from
http://www.only4gurus.com/v3/download.asp?resource=3748
but did not find my function in the list there too.

So going to the bookstore to check out Access Developer's Handbook

Thanks,
Yelena

John Welch wrote:
Yelena-
the "adh" at the beginning of the function name makes me think that this
code came from the Access Developer's Handbook, by Getz, Gilbert, and
Litwin. You might look there for clues. (It's a great book, in case you
haven't seen it.)
-John
Hello,

[quoted text clipped - 30 lines]

Thanks in advance for any help,


--
Regards,
Yelena Varshal

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200604/1
Apr 11 '06 #5

P: n/a
Take a look at this site: http://www.allapi.net/

Piter

Apr 12 '06 #6

P: n/a
"Yelena Varshal via AccessMonster.com" <u15452@uwe> wrote in
news:5ea221aba2228@uwe:
I am working with existing code. The person who created this code
does not work for the company anymore. She used this function to
write several entries into the custom registry key to save
application settings on exit. It works really fine on my desktop
with Office 2000. This function is a standard API call , I posted
just the declaration part of it. She calls it from a module as
follows:

rc = adh_accRegWriteVal(adhcHKEY_LOCAL_MACHINE, REGPATH &
"AppKeyName", "Top", .y1, adhcREG_DWORD)
That function namd indicates that it comes from the Access
Developer's Handbook.
where
adhcHKEY_LOCAL_MACHINE is a pre-defined constant &H80000002 which
stays for HKEY_LOCAL_MACHINE
REGPATH is a pre-defined constant with a path in the registry
AppKeyName is a key name for the registry key
Top is a Value Name
.y1 is a Value Data (this is just a numeric value from a record.
What language are you working in that you don't have native registry
editing functions?
The part that does not work is adhcHKEY_LOCAL_MACHINE. As I say,
its value &H80000002 which is hexadecimal and it works for Access
2000. It does not work with Access 2003. if I replace this value
with the decimal representation of the same number - 2147483650
then Access adds a pound sign # at the end of the number an it
works in Access 2000. I was trying to get a feel for the proper
syntax for this function and for how I should enter values.
But if you say I shoul use soemthing else, please, let me know
what should I use from Access module to write to the registry.


If you're programming *in* Access, then there's no need to declare
an Access API -- just use the VBA functions for writing to the
Registry.

Now, perhaps the ADH has extended functionality there, but I
strongly doubt they'd have declared a reference to the MSAccess
executable. That just makes absolutely no sense. Ah, yes, I see the
function you've quoted above referenced in the Access 2000 ADH on p.
1288 of the first volume.

The authors of the ADH have written their own registry functions to
get around limits to VBA's registry functions. The main reason they
give is that the VBA functions only have access to the CurrentUser
registry hive. But that's the only *correct* way to write to the
registry -- you shouldn't count on a user running Access under an
administrative logon which would give them permission to write to
LocalMachine hive, which is normally read-only for a user-level
Windows logon.

What you write above about the adhcHKEY_LOCAL_MACHINE makes no
sense. It's defined as a Long, so there should be no need for a # if
you use the literal value. And if you're using the ADH code, the
constant should be defined and you shouldn't have any problems using
it.

My guess is that there's a difference in the permissions on the A2K
registry keys vs. the A2K3 registry keys under the LocalMachine
hive, and the A2K keys are user-writable while the A2K3 keys are
not.

So, this isn't a code problem, but a registry permissions problem,
seems to me.

Actually, just pulling up the code from the ADH CD, it appears that
you were using some kind of vastly altered version of the code, as
there is no function definition in the code for adh_accRegWriteVal.
There is just an elaborate custom function. The declaration you
quoted with Declare Function adh_accRegWriteVal Lib "msaccess.exe"
Alias "#71" is not found in the original ADH code, and really
doesn't make any sense to me at all. There *are* such msaccess.exe
function declarations in other modules of the sample CD, but none of
them has Alias #71. Perhaps that reference is from one of the other
ADH chapters. It certainly doesn't have anything to do with the ADH
registry functions, though.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 12 '06 #7

P: n/a
On Tue, 11 Apr 2006 20:38:28 GMT, "Yelena Varshal via
AccessMonster.com" <u15452@uwe> wrote:

I would suggest you study the reason for these registry writes.
Speculating I think it is saving the X,Y location of some object,
perhaps a form. Such coordinates should probably be user-specific: I
want my form here while you want it there. If that is the case, all
this code can be replaced by simple calls to the built-in VBA
functions GetSetting and SaveSetting, which save to HKCU. They work in
any version of Access.

-Tom.

David,

I am working with existing code. The person who created this code does not
work for the company anymore. She used this function to write several entries
into the custom registry key to save application settings on exit. It works
really fine on my desktop with Office 2000. This function is a standard API
call , I posted just the declaration part of it. She calls it from a module
as follows:

rc = adh_accRegWriteVal(adhcHKEY_LOCAL_MACHINE, REGPATH &
"AppKeyName", "Top", .y1, adhcREG_DWORD)

where
adhcHKEY_LOCAL_MACHINE is a pre-defined constant &H80000002 which stays for
HKEY_LOCAL_MACHINE
REGPATH is a pre-defined constant with a path in the registry
AppKeyName is a key name for the registry key
Top is a Value Name
.y1 is a Value Data (this is just a numeric value from a record.

The part that does not work is adhcHKEY_LOCAL_MACHINE. As I say, its value
&H80000002 which is hexadecimal and it works for Access 2000. It does not
work with Access 2003. if I replace this value with the decimal
representation of the same number - 2147483650 then Access adds a pound sign
# at the end of the number an it works in Access 2000.
I was trying to get a feel for the proper syntax for this function and for
how I should enter values.
But if you say I shoul use soemthing else, please, let me know what should I
use from Access module to write to the registry.

Thanks,
Yelena

David W. Fenton wrote:
Basically I will be grateful for the input format of all
parameters. The function definition is:

[quoted text clipped - 5 lines]
String, _
lpData As Any, ByVal lngType As Long) As Long


What are you trying to do here? I can't think of a situation where
I'd ever attempt what you're doing here. If you want to automate
Access, then this is definitely *not* the way to go about it!


Apr 12 '06 #8

P: n/a
Tom van Stiphout <no*************@cox.net> wrote in
news:nk********************************@4ax.com:
I would suggest you study the reason for these registry writes.
Speculating I think it is saving the X,Y location of some object,
perhaps a form. Such coordinates should probably be user-specific:
I want my form here while you want it there. If that is the case,
all this code can be replaced by simple calls to the built-in VBA
functions GetSetting and SaveSetting, which save to HKCU. They
work in any version of Access.


I would suggest that there is *no* justification at all for any
user-space application to write to any registry hive other than
HKCU. Doing otherwise is outdated security practice, dating back to
the days when there was no security in Windows at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Apr 12 '06 #9

P: n/a
MSAccess was not created with the notion that its functions would be
called in the method you are suggesting. Many Windows functions are.
This is because Windows is an OS. Applications do their things by
calling OS functions, a basic understanding of programming that many or
most discussions, classes and textbooks ignore.
To use MSAccess functions one would have to find an entry point. And
then one would have to find some documentation for parameters, types
and return values. TTBOMK this documentation is not public. Its
possible that parameters would be of such types that they could not be
emulated in VBA. And its possible that misuse of these functions could
result in massive damage to one's database and perhaps many of the
programs on the machine where the attempt is made.
The task you are describing is most unusual and difficult. If it were
attempted by an eperienced and resourceful programmer of VBA and C+ it
would be challenging. You will know if it's appropriate for you, but
one guess that since you are not familiar with the fundamentals of
using the Windows API, it is not.
If you are a genius, I suggest you work your way through your problem
and astound us with your solution. If not, I suggest you content
yourself with simple questions such as, "How can I write a value to
the Registry?"

Apr 12 '06 #10

P: n/a
Thanks to all of you for your replies:

- Peter, I will take a look at this site

- David,I am using VBA code module in MS ACCESS. I do agree with you thta it
may be permission issue, I am investigating. Yes, a lot of things don't make
sense to me. Yes, putting these entries under the Current User will be a
better solution, I will suggest it as a modification for the next release. I
did not write this code, it was a previous developer(s). As for outdated
secirity practice, yes, this code was written a while ago, yes, it may be
outdated. I will use your input to make a case for my project manager that we
have to modify that.

-Tom, thanks. I will probably use GetSetting and SaveSetting as you suggest.
The only thing we want tis to save form coordinates on exit in order to read
them on the startup

- Lyle, you say: "If you are a genius, I suggest you work your way through
your problem
and astound us with your solution" I am MCSD (which means Solution Developer)
, MCSD.NET and MCDBA, I just did not work that much with VBA. My first
solution was to ask the experts and I was right!

- All: please, visit www.sqlservercentral.com if you have any SQL Server
problem or question. I mostly monitor Administration forum there, but there
is a feature to send the direct email to a member, so I can answer your SQL
Server questions should you have any. Meanwhile, I will try all of your
suggestions.

Thanks so much,
Yelena

Lyle Fairfield wrote:
MSAccess was not created with the notion that its functions would be
called in the method you are suggesting. Many Windows functions are.
This is because Windows is an OS. Applications do their things by
calling OS functions, a basic understanding of programming that many or
most discussions, classes and textbooks ignore.
To use MSAccess functions one would have to find an entry point. And
then one would have to find some documentation for parameters, types
and return values. TTBOMK this documentation is not public. Its
possible that parameters would be of such types that they could not be
emulated in VBA. And its possible that misuse of these functions could
result in massive damage to one's database and perhaps many of the
programs on the machine where the attempt is made.
The task you are describing is most unusual and difficult. If it were
attempted by an eperienced and resourceful programmer of VBA and C+ it
would be challenging. You will know if it's appropriate for you, but
one guess that since you are not familiar with the fundamentals of
using the Windows API, it is not.
If you are a genius, I suggest you work your way through your problem
and astound us with your solution. If not, I suggest you content
yourself with simple questions such as, "How can I write a value to
the Registry?"


--
Regards,
Yelena Varshal

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200604/1
Apr 12 '06 #11

P: n/a
Writing to HKLM just silently fails on many client machines now.

Unless you have Admin rights on your PC, which is not standard
in government or large corporates, you just can't write there.

(david)
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...
Tom van Stiphout <no*************@cox.net> wrote in
news:nk********************************@4ax.com:
I would suggest you study the reason for these registry writes.
Speculating I think it is saving the X,Y location of some object,
perhaps a form. Such coordinates should probably be user-specific:
I want my form here while you want it there. If that is the case,
all this code can be replaced by simple calls to the built-in VBA
functions GetSetting and SaveSetting, which save to HKCU. They
work in any version of Access.


I would suggest that there is *no* justification at all for any
user-space application to write to any registry hive other than
HKCU. Doing otherwise is outdated security practice, dating back to
the days when there was no security in Windows at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Apr 12 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.