Dear,

Apart from the typical uses for the built-in VBA registry functions, I want to create a profile to create Splash Screens, Icons and Help files as mentioned in the below article.

http://www.advisor.com/Articles.nsf/AID/FISHS01

I want to first tell Access to look for the profile. This needs to be done when the user first installs my access project in his/her machine. Then I need to create a subkey specifically for my application. Can I do this 'under' \VB and VBA Program Settings or it should be done under any other key (created by me).

Before jumping in, I want to know whether its possible in-build VBA functions or should I use the API calls mentioned in Chapter 18.

Kindly clarify.

Best Regards
B Karthick

__________________
CJBGUY

You can place the actual profile anywhere you like, and you can use the in-built registry calls or the API calls, as you prefer. You only have to tell Access where to find the profile, by setting the apropriate registry path in a value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\11.0\ Access\Profiles.

With the Access Developer Extensions (ADE), you have the ability to create Registry settings when the user installs your application.




Graham R Seach
Microsoft Access MVP

Dear Graham,

Many thanks for your reply.

Your reply means that without the ADE its impossible to use profiles. Kindly correct me if I am wrong in any of my following understandings.

1) Installation will be done by the customer without the developer (myself).

2) There is no way to tell Access to look for the profile because I can't alter the registry before the client opens the project for the first time.

3) If the customer's registry needs to be altered manually, for asking access to look for a profile, then, it would be unnecessary to use VBA code for the entering the rest of the profile specific subkeys.

Await your confirmation. Thanks once again.

Best Regards
B Karthick

Replies in-line.

<<Your reply means that without the ADE its impossible to use profiles.>>
That's not what I said! What I said was that the ADE allows you to create and specify registry settings. That does not preclude you from creating registry settings in some other way.

<<1) Installation will be done by the customer without the developer (myself).>>
Not necessarily will be done by the customer, but can be done by them in your absence.

<<2) There is no way to tell Access to look for the profile because I can't alter the registry before the client opens the project for the first time.>>
Correct. But having said that, you can of course write your own installaton program.

<<3) If the customer's registry needs to be altered manually, for asking access to look for a profile, then, it would be unnecessary to use VBA code for the entering the rest of the profile specific subkeys.>>
Again, that's not what I said! You can setup the registry manually if you choose, or you can use VB/VBA to set them up using the in-built VBA registry functions, or the API functions.


Graham R Seach
Microsoft Access MVP

Dear Graham,

Many thanks for your patient replies. Let me clarify the situation which is specific to me. I did not intend to say that VBA or Access has those weakness. Following is my situation ...

1) I dont have the ADE
2) I dont want to visit the customer place.

Now, I can't ever alter the Registry key and customer will not do this because they do not have the knowledge or its awkward for me to ask them to alter the registry.

Now, I can just mail the Ms Access 2002-2003 *.Mdb file and without running the application atleast one time, I can't tell Access to look for a profile.

However, yesterday, I got a good freeware setup program which will both package the *.mdb and alter the registry for me once the setup disks are run. I hope there is no harm to mention the url here.

http://www.dev4pc.com/setup2go_download.html

I do not know if this is the best alternative but this solves my purpose. Once I am successful in creating the registry entry before access runs for the first time, I can create/check the other profile specific entries, through VBA in my CBF (frmSwitchboard for example).

I prefer built-in VBA over APIs because I have fewer lines to type. I am not a crisp writer, but want to tell you that with your help and internet, I have moved forward in my goal.

Thanks once again for all your expertise in Access and advise

Best Regards
B Karthick