|
|
ACCESS DEVELOPMENT
Create Personalized Access Splash Screens
Use profiles in the Windows Registry to add finesse to even the most mundane Access projects.
By Steve Fisher
Using Access profiles can add the bells and whistles that spice up a project and make a lasting and professional impression. Unfortunately, cool things take time to create and if you're like me, you probably have deadlines. The basic features have to be delivered first. That's where profiles come in. They're a powerful technique that can make your projects look and act sharp. When combined with an installation/setup program, profiles help hide the fact that your application uses an Access database, and they let you put personal touches on even the most mundane projects.
A profile is nothing more than a set of specific Windows Registry settings that control how an Access application behaves. Profiles are frequently used to store an individual user's preferences, the application's start-up parameters, and so on. Using a profile is straightforward:
- Install your application's files.
- Create Windows Registry settings for your profile.
- Create a shortcut to your application database using the /profile command line switch.
When a user starts the application with a shortcut, the command line can include the /profile switch to specify the name of a profile to use. (The /profile switch replaced the /ini switch used in Access 2.0.) In its simplest form, the command line looks like this:
C:\Program Files\Microsoft Office\Office\MSACCESS.EXE
/profile YourApp
where "YourApp" is the name of the profile for your application.
Profiles work well when distributing applications with an installation or setup program. Before working with profiles you need to be familiar with the Windows Registry, because you'll want your installation/setup program to write Registry values automatically. There are some tricks you need to know to correctly use profiles, which I explain in this article.
Why use a profile?
There are several things you see when a typical Windows application starts. In Excel, for example, the first thing that pops up is a splash screen that identifies the program and displays version, license, and copyright information. The splash screen gives immediate feedback that the application is starting -- it gives you something to look at while the program loads. On a fast PC this feedback isn't so important because the program may take less than a second to load. On a slow machine, though, the splash screen indicates that something is going on under the hood of that old 486-DX2.
Another thing that you see when a typical Windows application starts is a custom icon for the application. I'm sure you could draw Access' little yellow key icon from memory, right? If the icon isn't enough for you to recognize an application, the application's name appears in the title bar and in the Windows taskbar.
Profiles make your Access-based application behave like a typical Windows application. As you're probably aware, Access applications aren't compiled applications that run using a main executable file. Since an Access "application" is actually a file opened in Microsoft Access, you can design it so the user believes the application is its own entity. Access gives you several ways to let you specify a splash screen, icon, and title specific for your application.
Profiles vs. database startup properties
If you're thinking that these features correspond to database startup properties, you're right. These are also three of the runtime options profile settings that can make your applications look more professional (table 1).
Table 1: Startup properties vs. profile settings -- These are the database startup properties that correspond to runtime options profile settings
| Feature | Database Startup Property Setting | Profile "Runtime Options" | Profile Setting's Advantage(s) |
| Splash screen | StartupForm | StartupScreen | Your splash screen replaces the built-in
Access screen; you can rename the
bitmap so users can't mess with it. |
| Icon | AppIcon | Icon | The icon's path will always be correct
because it's saved when the application is
installed, not when the application is being
developed. |
| Application | AppTitle | TitleBar | None, really. But can conflict with startup
window title property if both are used. |
| Help file | -- | AppHelpFile | Applies globally to your application. |
It's common to use the database startup properties (Tools > Startup...) to specify a startup form, icon, and title. The AppTitle and AppIcon settings can be saved with your database. This is simpler than fussing with profiles in the Registry, and if you're not distributing an installation program this is probably your best option.
Database startup properties generally work well but, if you want to hide Access from the user, they don't do a complete job. Your startup/splash form isn't displayed until after Access has loaded and opened your database. That means Access displays its own splash screen with its own user and license information while it loads. There are also cases when your custom icon won't be displayed.
Some startup properties not needed
You may wish to leave some database startup properties empty when using a profile. Consider the AppIcon property. For example, I have the working copy of my app in the D:\Clients\Client1\App1 folder on my office machine, with both the application database and icon file saved in this folder. I set the database startup property to point to the icon, D:\Clients\Client1\App1\app1.ico, and then happily distribute my application. The installation/setup program installs both files to the same folder on my client's machine: C:\Program Files\MyCompany\App1. Does my custom icon appear when the application runs?
It doesn't. The built-in Access icon appears. When you specify an icon in the database startup properties, you don't have an option to embed the icon file into your database. Instead, the path to the icon is hard-coded. This causes a problem when distributing your application because you don't know the exact drive letter and path where users install.
To get around this, use an Access profile with the Icon setting which contains the true path to the icon file on each user's machine. Bingo! Your application is smarter than Access. If you prefer to save the application icon as a database startup property, you can use code (listing 1) to synchronize your icon settings. You can easily modify this code to do the same thing for the application title settings. The full code to these procedures, a module for working with the registry, and an example installation/setup program that uses profiles is included on the Professional Resource CD for this issue.
Listing 1: Synch the icon -- Run this code in your application's startup routine to synchronize the AppIcon database property and the Icon profile setting. The database startup property is broken when the user installs your application to a different folder, but this code fixes it.
Public Sub FixAppIcon()
' Purpose: Fix the AppIcon database startup
' property to match the profile's Icon setting.
Dim dbs As Database
Dim varDbStartupIcon As Variant
Dim strProfileIcon As String
Dim prpTemp As Property
Set dbs = CurrentDb()
' Compare values for profile Icon property and
' AppIcon database startup property.
strProfileIcon = RegistryGetKeyValue( _
eRootKey:=rrkHKeyLocalMachine, _
strKeyName:="Software\YourCompany\Some Thing\ _
1.0\Runtime Options", _
strValueName:="Icon")
On Error Resume Next
Set prpTemp = dbs.Properties("AppIcon")
If Err.Number = 0 Then
varDbStartupIcon = prpTemp.Value
Else
varDbStartupIcon = Null
End If
On Error GoTo 0
' Only fix application icon if the property
' already exists. Since you're using a profile,
' it's actually best to omit this property and
' let the profile specify the icon.
If Not IsNull(varDbStartupIcon) Then
If Nz(varDbStartupIcon, "") <> _
strProfileIcon Then
SetDbStartupProp "AppIcon", dbText, _
strProfileIcon
End If
End If
End Sub
Public Function SetDbStartupProp( _
pstrName As String, _
plngType As Long, _
pvarValue As Variant) As Boolean
' Purpose: Save a database startup property
' In: pstrName - name of property
' plngType - data type for value.
' Use DAO's DataTypeEnum constants:
' dbText, dbDate, dbNumeric, dbBoolean
' pvarValue - value data
' Returns: True if property is saved successfully.
Dim dbs As Database
Dim prp As Property
Dim fExists As Boolean
Set dbs = CurrentDb()
' Does property already exist?
On Error Resume Next
Set prp = dbs.Properties(pstrName)
fExists = (Err.Number = 0)
On Error GoTo 0
' Create property if necessary.
If Not fExists Then
' Use new value
Set prp = dbs.CreateProperty(pstrName, _
plngType, pvarValue)
dbs.Properties.Append prp
Else
' Property already exists, just save new value.
dbs.Properties(pstrName).Value = pvarValue
End If
SetDbStartupProp = True
Set dbs = Nothing
End Function
What about the AppTitle database startup property? If this property doesn't correspond to the TitleBar registry setting for your profile, Access displays one title while it loads (the profile setting), then another title after your database opens (the database startup setting). If you close your database and leave Access open, the application title from your profile is displayed again. When using a profile, you can see why it's best to leave these startup properties alone.
Splash screen
In contrast to the StartupForm database startup property, the StartupScreen profile setting specifies a bitmap file to display in place of the built-in Microsoft Access splash screen (figure 1). This bitmap displays before Access has completely loaded, so it gives the user immediate feedback that the application is starting. Using this option can give a professional appearance, and, along with the Icon and TitleBar properties, can virtually hide the fact that your application runs using Access.
Figure 1: Built-in Access splash screen -- With a profile, you can replace the default Microsoft Access splash screen, which displays user and license information.
Access handles the splash screen issue differently depending on if you're using a fully licensed or runtime installation. With a fully licensed installation, Access always displays its built-in splash screen unless you tell it otherwise. If you use a custom bitmap, Access displays the user, company, and registration number for Microsoft Office on top of your bitmap (figure 2). Be careful, because Access gives no regard to whether you left blank space on your bitmap to paint its text -- Access paints right onto your graphics without so much as an apology.
Figure 2: Custom splash screen -- A custom splash screen bitmap can replace the default Access splash screen. Access paints its user and registration information onto your bitmap.
Runtime or fully licensed?
With a runtime installation (or when using the /runtime switch), Access doesn't display its built-in splash screen; it's up to you to provide one. If you use a custom bitmap with a runtime installation, Access won't display the Office registration information on your bitmap.
When it comes to the StartupScreen setting, things can get kind of confusing. Remember that you need to take into account the environment in which your application runs: fully licensed or runtime. Basically, if you're developing for a runtime installation it's safe to use any splash screen bitmap. If you're developing for a fully licensed installation, you're best served to leave space for Access to paint its information. And if you're developing for both environments, you might find it easier to forego a splash screen bitmap, or do something unconventional. (See the sidebar "Methods for Using a Splash Screen Bitmap," on page 25 for a more extensive discussion on custom splash screens.)
You may know that Access also gives you a quick and dirty method to use a custom splash screen bitmap without creating a profile. Just name your bitmap the same as your database and install it to the same folder. For instance, for an application named PartsAndServices.MDB, name the bitmap PartsAndServices.BMP. When you open a shortcut to the database, Access first looks for a bitmap with the same name as your database. If it finds one then it displays it instead of the built-in Access splash screen. This works for both runtime and fully licensed installations.
This quick and dirty method lends itself to unanticipated events, however. Any user can browse to your application's folder and double-click on the .BMP file to open it. After that, it's open season on your splash screen. (How would you like to have your company's name or copyright erased from the splash screen?)
User-proof
The most user-proof method is to specify the startup screen as a profile setting. Then you can prevent users from mucking around with your application's files; just change the bitmap file's name and/or location. This method has a couple of advantages. First, you can install the bitmap to a folder other than the application's folder. Second, you don't have to name the bitmap the same as the application database.
For the most user-proof situation, name the bitmap with a different file extension. Use an extension Windows won't recognize and that isn't associated with any other application. Then, if a user double-clicks on the file, Windows won't know what program to use to open the file, and neither will the user.
I prefer the extension *.splash, for two reasons. First, it's longer than a usual file extension (which is usually three characters), so it's highly unlikely that another software manufacturer will develop a file type and register it with anything other than a three character extension. (The 8.3 DOS file naming habit will probably persist for the foreseeable future.) Second, *.splash is handy for developers, because it immediately identifies the use of this file. (Plus it's cool to see SPLASH File as the description in Windows Explorer).
The last runtime options profile setting, AppHelpFile, stores the path to the help file for your application. This setting doesn't correspond to a database startup property. AppHelpFile is used to specify the default help file which opens when the user presses F1, clicks on the What's This? button, or uses the help menu items. Remember that this setting only works for runtime installations.
Profiles in practice
As an example of how to create a profile, assume you're working on a project named Some Thing, version 1.0. First, you must install the application's files somewhere, like C:\Program Files\YourCompany\Some Thing. That's the easy part, which you can do manually or by an installation/setup program.
Next, you must create a registry key for the application. A good location for this key is here:
HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\Some Thing\1.0. This is where you store information for the profile, as well as any other information you want to store for your application (figure 3). Replace YourCompany with the name of your company. The 1.0 indicates the version number for the application, so substitute the version number of your application. This allows multiple versions of your application to coexist on the same machine, which is the convention Microsoft Office uses.
Figure 3: Startup properties vs. profile settings -- These are useful registry settings for your application, and are helpful if you do, or don't, use an Access profile.
You may want to create some of your own settings, which can be accessed while the application is running. This is a good way to store persistent information between sessions which won't be lost if you distribute a new application database. For example, you can store form screen positions and user preferences. These settings can easily be created using a third-party installation/setup utility. These settings aren't part of the profile, but can be used by the application and are informative documentation for your program.
Next, create the main key you're interested in -- the one that controls how the app starts -- which must be called runtime options. Access looks for this key under your application's main key whenever you use a profile. The runtime options key doesn't correspond to any existing Access registry keys; that's what makes it special. Although the name implies that this key only affects runtime users, it actually applies any time you use a profile. Create this key under the app's main key (figure 4):
Figure 4: Runtime options -- The runtime options key is crucial for your application's profile.
HKEY_LOCAL_MACHINE\SOFTWARE\YourCompany\Some Thing\1.0\runtime options. The runtime options key contains the values used by your profile when your app opens: TitleBar, used for the caption of the Access application window; Icon, your custom application icon; StartupScreen, which specifies a splash screen bitmap; and AppHelpFile, the path to a custom help file for your application. Creating a profile with these four settings constitutes an effective technique to immediately make your application look more professional.
Beware of the app
The Office Developer's Edition (ODE) help file says in several places that the values under runtime options should all start with the prefix "App" (like AppIcon, AppTitleBar, etc.). This isn't exactly correct. For Access to recognize these settings, they must be named as follows:
StartupScreen
TitleBar
Icon
AppHelpFile
Note that the help file setting is the only one that begins with App.
Make Access aware of your profile
Once you've created registry keys for your application and runtime options settings for your profile, you have to tell Access that the profile exists. You do this by adding a value to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\8.0\Access\Profiles key. The Profiles key isn't created when Access is installed. Unless there are existing profiles, you have to create the Profiles key and then add profile values.
The value names under the Profiles key are the names of profiles, and the data are strings that point to locations in the registry where Access can find your custom settings (figure 5). It's important to note here that the registry string is relative; the top-level of the key name is always assumed to be HKEY_LOCAL_MACHINE. The names of these values are the profile names to use with the /profile switch on the command line.
Figure 5: Point Access to your profile -- Profiles are defined so Access knows where to look elsewhere in the registry for the profile settings.
To tell Access that your profile exists, create a new string value called Some Thing under the Profiles key. This is the name of the profile, which is also the same as the name of the application. For its data, enter SOFTWARE\YourCompany\Some Thing\1.0.
Omit the backslash -- or, why won’t my profile work?
The Access documentation states that you should include a backslash as the first character for the profile's value data. Actually, you must omit the initial backslash for the profile to work.
You now have a profile set up for the Some Thing application. You can find documentation for profiles in the Access help file under the topic "Customize your application's environment with user profiles," and in the Office 97 Developer's Edition Tools help file under the topic "Microsoft Access runtime option settings."
Beyond runtime options
This article concentrates on the runtime options profile settings, but you can create many other settings to control the behavior of Access and Jet. Copy any of the keys and values under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\8.0\Access (except the Profiles key), and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\3.5\ Engines to your application's registry key, and change the settings to meet your needs. You can tweak settings for add-ins, wizards, ODBC, and clipboard formats, for example.
When it comes to developing quality, professional, bullet-proof applications, Access profiles give you the power to control the little details that make a big impression.
Methods for Using an Access Splash Screen Bitmap
Access lets you replace its built-in splash screen with your own bitmap. There are at least four methods for using a splash screen bitmap, each with its own merit.
The first method is simple to implement and relies on Access: Create a bitmap in the same folder as your database, with the same name as your database. For instance, if your database is named zippy.mdb, your bitmap would be named zippy.bmp. When you double-click on the database to open it or start the database from a shortcut, Access first looks for a bitmap with the same name as the database. If it finds one, it displays yours instead of the built-in Access splash screen. This method requires no registry entries or profile; however, users can easily open the bitmap file and modify it.
This first method is consistent with the behavior of Windows and Microsoft Office products, in which the application displays its splash screen while loading. However, with a fully licensed (not runtime) installation, Access displays the Access/Office user, company and registration number information on top of your bitmap. (It doesn't do this with a runtime installation.) If you distribute an installation/setup program that writes your own user, company, registration number, etc. to the Windows Registry, it's not possible to display your application's information on the startup bitmap. You have no programmatic control over the splash screen bitmap—Access doesn't care about any information your application saved to the registry -- it only displays its own version of this data.
The second method, described in the article, is to use an Access profile that stores the path to the bitmap file. Use the Icon profile setting, which is a Windows Registry value that can be created by an installation/setup program like the ODE Setup Wizard or Wise.
When using the first and second methods you must decide whether you want to display Access/Office information on your splash screen. Of course, this isn't a concern for runtime applications, but if you're distributing to both fully licensed and runtime users, you will have issues with these first two methods:
- If you leave room on your splash screen bitmap for Access/Office information, it will look fine to fully licensed users, but it will have a blank area for runtime users.
- If you don't leave room on your bitmap for Access/Office information, fully licensed users will see text on top of your graphics, but runtime users won't be affected.
This leaves the last two methods, which can serve as workarounds when using a combined fully licensed/runtime distribution. The third method is to use the startup bitmap as an intermediate status screen (figure 6). This can be a small screen with a short message, like Loading..., that displays while Access is loading. The trick here is to make the bitmap smaller than the Access splash screen, because Access tries to paint its user/company/registration information a fixed distance from the top left corner of your bitmap. If your bitmap is small enough to force Access to paint outside the edges of your bitmap, Access won't paint any text at all. (The Access splash screen is 400 by 247 pixels. It paints the text about 103 pixels from the left and 165 from the top of your bitmap, so a bitmap thinner than 103 or shorter than 165 pixels should be fine. Keep these dimensions in mind if you use this method.) Display your real splash screen when Access has opened your application.
Figure 6: "Pre-splash" screen -- You can use a small bitmap to prevent Access from displaying its registration information, then display a larger, more informative splash screen form when your database opens.
This method has several advantages. First, it gives the immediate impression that your application is doing something. Second, it gives you complete control over the main splash screen, since the main splash screen is just a form in your database. You can display registry values saved by your installation program, or even create an ActiveX DLL OpenGL spinning logo splash screen with sound (don't get me started!). The disadvantage of this method is that it isn't standard Windows and Office behavior to display two splash screens: a pre-splash screen and then the main one.
The last method is useful if you don't want to display the built-in Access splash screen and also don't want to display a custom startup screen bitmap to replace the built-in one. Create a 1 by 1 pixel bitmap (black works well), and name it the same as your database, or use an Access profile with the Icon setting to point to this file. When Access starts, it displays your little bitmap, but it's so small that the user will probably never notice it. Then display your own splash screen after Access loads and opens your application.
Access may do some weird things to the colors in your bitmap. Gradients may appear blocked instead of smoothed, and your bitmap may not be represented accurately. If you know the minimum color depth your users will be running, save the bitmap using that number of colors. Use 256 colors if you don't know, and try to use standard Windows colors with as few custom colors as possible. You should test it out by changing your color settings in the Windows Display properties.
-- Steve Fisher
Steve Fisher is a systems analyst for FMS, Inc., best known for their add-in products for Access and Visual Basic. He works for the consulting side of the company, and develops custom applications with Access, Visual Basic, and SQL Server. His experience includes projects for the health care industry, federal and state governments, telecommunications, and defense contracting. Steve lives and works in a Virginia suburb of Washington, D.C. steve@fmsinc.com. Keyword Tags: Application Design, Forms, Microsoft, Microsoft Access 97
|
ARTICLE INFO
Print Edition: January 1999
 FREE ACCESS
|
|
|
 ![]()
Read the advanced guide to creating custom business database solutions with FileMaker software. Subscribe now to gain access to all the archives and downloads.![]()
Learn the fundamentals of using FileMaker Pro software. Every issue gives you step-by-step instructions on creating the databases you need. Subscribe now!![]()
![]()
![]() ![]()
Submit your tips, techniques and advice and let Advisor promote your business and build your career. Show the world what you know!![]() ![]()
|
|