   ---------------------------------------------
   Microsoft Access Distribution Kit README File
                  April, 1993                
   ---------------------------------------------

     (C) Copyright Microsoft Corporation, 1993

This document provides complementary or late-breaking
information to supplement the standard Microsoft
Access Distribution Kit (ADK) documentation.


------------------------
How to Use This Document
------------------------

To view README on screen in Windows Notepad, maximize
the Notepad window.

To print README, open it in Windows Write, Microsoft
Word, or another word processor. Then select the entire
document and format the text in 10-point Courier before
printing.

--------
Contents
--------

Duplicating Standard Microsoft Access Menus
Hiding the Database Window at Startup
Printing Forms and Reports in a Secure Application
Halting Execution of Macros that Use Queries
Installing Common Dynamic-Link Library Files
Required Files on Disk 2
Making Sure All Sections Are Included in Your INI File
Changing Your Application's Workgroup
Invalid Characters in an Application Name
Screen Display Problems While Running SUFILES.EXE
Errata and Omissions in Documentation

-------------------------------------------
Duplicating Standard Microsoft Access Menus
-------------------------------------------

The ADK provides a set of macros that let you duplicate 
standard Microsoft Access menus and commands in your 
application. You can duplicate all the menus, or select 
only the menus you want to duplicate. These macros are 
located in the SETUPWIZ.MDB database included with the 
ADK.
 
NOTE: Although these macros are distributed in the 
SETUPWIZ.MDB database file, they are not used by the 
SetupWizard.

To duplicate the standard Microsoft Access menus on a
form:

1 Import the following macros from SETUPWIZ.MDB to the 
  database containing the form.

  Form Menubar
  Form Menubar (Edit)       
  Form Menubar (File)       
  Form Menubar (Help)       
  Form Menubar (Layout)       
  Form Menubar (Records)       
  Form Menubar (View)       
  Form Menubar (Window)       

2 Set the OnMenu property of the form to the Form Menubar
  macro. 

  Microsoft Access uses the Form Menubar macro to create
  a custom menu bar that includes the standard Microsoft
  Access menus. The Form Menubar macro uses the other 
  macros from SETUPWIZ.MDB to create individual menus.

To duplicate selected standard Microsoft Access menus on
a form:

1 Import the Form Menubar macro from SETUPWIZ.MDB, along
  with the macros corresponding to the menus you want to 
  include on the form. For example, if you want to 
  duplicate the Edit and Records menus, import the Form 
  Menubar (Edit) and Form Menubar (Records) macros.

2 In standard Microsoft Access, open the Form Menubar 
  macro.

3 Delete the AddMenu actions for all menus except the 
  menus you want to include on the form.

4 Save the Form Menubar macro.

5 Set the OnMenu property of the form to the Form Menubar
  macro. 
 
To remove a command from a menu, delete the corresponding
DoMenuItem action from the macro that creates the menu. 
For example, to delete the About command from the Help
menu, delete the corresponding DoMenuItem action in the
Form Menubar (Help) macro.

For more information about creating custom menus and menu
bars, see Chapter 24, "Using Macros for Application Design,"
in the "Microsoft Access User's Guide" or search Help for
"customizing menus."

-------------------------------------
Hiding the Database Window at Startup
-------------------------------------

If you want to ensure that your application can't be 
modified by users, it's a good idea to hide the Database 
window when your application starts, then design the 
application so that users are prevented from opening the
window.

To hide the Database window at startup:

- In your application's AutoExec macro, include a 
  DoMenuItem action that carries out the Hide command on 
  the Window menu.

Note that the Microsoft Access run-time executable hides 
the Database window similarly to how it hides Design 
windows and views -- by setting the color of the window to 
the default Windows background color. Contrary to the 
description on page 4 in Chapter 1 of the "ADK Guide," 
it does not minimize the window.

You can still use the Database window menus and commands
in your application by selecting the Database window and 
then carrying out commands using a DoMenuItem or SendKeys
action in a macro or module.

Note that even if you've hidden the Database window at 
Startup, the run-time executable will display a blank
version of the window, when it is selected, unless you 
disable screen updating. The blank version of the window
has no border and is set to the default Windows background 
color. To hide this blank window from users, design your 
application so that it disables screen updating, using the 
Echo action, before it selects the Database window.

--------------------------------------------------
Printing Forms and Reports in a Secure Application
--------------------------------------------------

In a secure application, users will not be able to change 
the printer where they print forms and reports unless they 
have Modify Definitions permissions for those forms and
reports. Microsoft Access stores printer settings for a form 
or report with the form or report's definition; a user must
have Modify Definitions permissions for the form or report 
in order to change those settings.

To ensure that a user can print a form or report on the 
user's default printer, specify Default Printer as the form
or report's printer setting while you're developing your
application. 

To set the printer setting to Default Printer:

1 While the form or report is open, select Print Setup from 
  the File menu.

2 In the Print Setup dialog box, select Default Printer.

3 Choose OK to close the Print Setup dialog box.

4 Save the form or report.

If you want users to be able to change the printer they 
use to print forms and reports, make sure they have Modify 
Definitions permissions for those forms and reports. 
Otherwise, they won't be able to change printer settings 
in the Print Setup dialog box.

--------------------------------------------
Halting Execution of Macros that Use Queries
--------------------------------------------

Although the run-time executable disables the CTRL+BREAK
(or BREAK) keystrokes for halting macro execution, users 
may still be able to use these keystrokes to interrupt a 
macro when the macro uses a query. As with standard 
Microsoft Access, you can use the CTRL+BREAK (or BREAK) 
keystrokes to halt query processing in the run-time 
environment.

To ensure that users can't use these keystrokes to 
interrupt the flow of your application, use Access Basic
rather than macros for operations that use queries. You
can then use the error-handling features of Access Basic 
to trap any errors that result from the interruption.

--------------------------------------------
Installing Common Dynamic-Link Library Files
--------------------------------------------

The following dynamic-link library (.DLL) files listed 
in Chapter 3 of the "ADK Guide" must be installed in the 
\WINDOWS\SYSTEM directory rather than the directory 
where the user has installed your application:

    MSABC110.DLL
    MSAES110.DLL
    MSAJT110.DLL
    BTRV110.DLL
    PDX110.DLL
    XBS110.DLL

The files are used both by Microsoft Access and by other 
applications. Setup automatically installs these files 
in the \WINDOWS\SYSTEM directory if you create your 
custom Setup using the SetupWizard or one of the sample 
information (.INF) files.

The entries for these files in the [Standard Setup Files] 
section of your custom Setup's information file must 
include the VERSION keyword, which sets the version 
number of the file. Otherwise, Setup may overwrite the 
correct version of the file when a user installs your 
application.

However, you should not specify a version number 
yourself, or change an existing version number setting.
The version number is set automatically by the 
SetupWizard, or preset for you in the sample information 
files.

------------------------
Required Files on Disk 2
------------------------

Chapter 3 of the "ADK Guide" lists the following files as
required on Disk 1 of your distribution disks; they are
instead required on Disk 2:

    OLECLI.DL$ 
    OLESVR.DL$ 
    SHELL.DL$ 

In addition, the compressed file REGEDIT.EX$ is a 
required file that must be distributed on Disk 2. 
This file is the object linking and embedding (OLE) 
registration file. Custom Setup automatically installs 
the file in the directory where Windows is installed.

However, the "ADK Guide" incorrectly states that the 
Microsoft Access registration file, MSACCESS.RE$, is a 
required file on Disk 2. This is not a required file. 
Setup creates this file automatically when a user 
installs your application. 

------------------------------------------------------
Making Sure All Sections Are Included in Your INI File
------------------------------------------------------

When you create your application's initialization (.INI) 
file, make sure to include all sections and entries from
your MSACCESS.INI file that are used for data 
manipulation. Microsoft Access and other applications 
that use the Access database engine use many entries in 
the MSACCESS.INI file to initialize the database engine.

If two or more applications that use the database engine
are running simultaneously, the engine is initialized to
the .INI file settings of the application that was 
started first. 

For example, when you start your run-time application,
Microsoft Access initializes the Access database engine
according to the settings in your application's .INI 
file. If you then start standard Microsoft Access while 
the run-time application is still running, the Access 
database engine will use your application's .INI file
settings rather than the settings in MSACCESS.INI.

Proper database initialization is especially important
when you are using data in other database formats or
applications, such as dBASE, FoxPro, or Paradox. For 
example, the Access database engine uses entries in the 
following sections of the .INI file to access data in 
other formats:

  [Installable ISAMs]
  [Paradox ISAM]
  [dBASE ISAM]

If those entries are not included in the .INI file of 
first application that starts the Access database engine,
then no application that uses the engine will be able
to use dBASE, FoxPro, or Paradox data while the first
application is running.

-------------------------------------
Changing Your Application's Workgroup
-------------------------------------

If you want users to be able to change your application's 
workgroup, your custom Setup must display the Change 
Workgroup dialog box during Setup or install a Change 
Workgroup item in your application's Program Manager 
group. You can enable this feature when you create 
custom Setup using the SetupWizard, as described in the
"ADK Guide" in Chapter 3, "Creating Your Custom Setup
Program."

In addition, you must modify the Change Workgroup
information file, WORKGRP.IN_. By default, this file 
instructs the Change Workgroup utility to change a user's 
standard Microsoft Access workgroup by modifying the
SystemDB entry in [Options] section of the MSACCESS.INI 
initialization file. To instruct Change Workgroup to 
change your application's workgroup rather than the 
standard Microsoft Access workgroup, you must replace 
references to MSACCESS.INI in this file with the name 
of your application's .INI file.

Otherwise, the Change Workgroup utility won't change
your application's workgroup. Instead, if a user has 
Microsoft Access installed, the utility will change the 
user's Microsoft Access workgroup. If the user doesn't 
have Microsoft Access installed, it will create a new 
MSACCESS.INI file and SystemDB entry.

To enable Change Workgroup to change your application's
workgroup:

1 Before running the SetupWizard or creating your custom
  Setup manually, edit the file WORKGRP.IN_ in the 
  directory where you have installed the ADK using a 
  text editor such as Windows Notepad. 

2 In the [Update INIs] and [Custom] sections of 
  WORKGRP.IN_, replace references to MSACCESS.INI with
  the name of your application's .INI file.

3 Run the SetupWizard or create your custom Setup 
  manually.

  The SetupWizard will create a compressed version of
  WORKGRP.IN_ on Disk 1 of your distribution disks. 

  NOTE: If you want to distribute an uncompressed 
  version of WORKGRP.IN_, copy your edited version of
  the file to your Disk1 directory after running the
  SetupWizard or creating your custom Setup manually.

When users run custom Setup, it will rename 
WORKGRP.IN_ to STFSETUP.INF on their disks. If the 
InstallChangeWorkgroup entry in the [Custom] section 
of STFSETUP.IN_ was set to "YES," custom Setup also 
creates a Change Workgroup item in your application's 
Program Manager group.

NOTE: If you use the Change Workgroup utility to try
to create a new SYSTEM.MDA in the same directory as an
existing SYSTEM.MDA, the existing SYSTEM.MDA will not 
be overwritten. Microsoft Access won't create a new
SYSTEM.MDA, although it will update the timestamp of 
the existing SYSTEM.MDA if it isn't in use.

-----------------------------------------
Invalid Characters in an Application Name
-----------------------------------------

When you create your application's custom Setup, do not
use brackets ('[', ']') or parentheses ('(', ')') in the
application name. If you use these characters in an 
application name while using the SetupWizard, the 
SetupWizard displays an alert message. If you are 
creating custom Setup manually, Setup fails to create 
a Program Manager item for the application.

-------------------------------------------------
Screen Display Problems While Running SUFILES.EXE
-------------------------------------------------

If your computer has an outdated version of the CTL3D.DLL
dynamic-link library in your \WINDOWS directory, you may
encounter screen display problems while running the
Setup Files utility, SUFILES.EXE. To correct the problem,
delete CTL3D.DLL from the \WINDOWS directory.

IMPORTANT: Do not delete the file from the 
\WINDOWS\SYSTEM directory. Microsoft Access installs the 
current version of CTL3D.DLL, which is required by 
Microsoft Access and by the run-time environment, in the 
\WINDOWS\SYSTEM directory.


-------------------------------------
Errata and Omissions in Documentation
-------------------------------------

The following errata and omissions in the printed 
documentation were discovered after the books were 
delivered for printing. Please mark the changes in your 
copies of the books. We apologize for any inconvenience.

Some of these errors may be fixed in later printings
of the books. 


Manual:   MICROSOFT ACCESS DISTRIBUTION KIT GUIDE
    
Chapter:  Introduction
Section:  "Distribution Kit Requirements"
Page:     vii
          The second item in the list incorrectly says the 
          ADK requires a hard disk with 3 megabytes of free 
          space. The ADK requires a hard disk with about 
          4 megabytes of free space.

Manual:   MICROSOFT ACCESS DISTRIBUTION KIT GUIDE
    
Chapter:  1, "Developing Run-Time Applications: An Overview"
Section:  "Hidden Windows, Views, and Toolbars"
Page:     4
          The second paragraph and Tip refer to the behavior
          of the Database window, saying that the run-time 
          executable hides the Database window by keeping it 
          minimized and never displaying the minimized 
          window's icon. The run-time executable hides the
          Database window by setting the color of the window 
          to the default Windows background color.

Manual:   MICROSOFT ACCESS DISTRIBUTION KIT GUIDE
    
Chapter:  1, "Developing Run-Time Applications: An Overview"
Section:  "Hidden Windows, Views, and Toolbars"
Pages:    4-5
          The Tip on Page 4 refers to the Exit action. It
          should refer to the Quit action. The Tip on Page 5
          refers to Quit and Exit actions. Delete the
          reference to the Exit action. Microsoft Access
          doesn't include an Exit action.

Manual:   MICROSOFT ACCESS DISTRIBUTION KIT GUIDE
    
Chapter:  3, "Creating Your Custom Setup Program"
Section:  "Files Required on Disk 1"
Pages:    35
          The Description of the WORKGRP.IN_ file incorrectly
          states that the file is renamed to WORKGROUP.INF on
          the user's disk. Setup renames the file to 
          STFSETUP.INF on the user's disk.

Manual:   MICROSOFT ACCESS DISTRIBUTION KIT GUIDE
    
Chapter:  3, "Creating Your Custom Setup Program"
Section:  "[Custom]"
Pages:    48-50
          The documentation of the RunExeName entry in the 
          [Custom] section of STFSETUP.IN_ incorrectly refers 
          to a disknum argument. RunExeName does not require 
          this argument. 

          On Page 48, delete the RunExeName entry from Syntax 
          and replace it with the following:

          RunExeName="exename"

          On Page 49, delete the disknum argument from 
          Remarks. On Page 50, delete "5, " from the 
          RunExeName example.

 Manual:   MICROSOFT ACCESS DISTRIBUTION KIT GUIDE
    
Chapter:  3, "Creating Your Custom Setup Program"
Section:  "[INI File]"
Page:     52
          In the Example for entries in the [INI File} section
          of STFSETUP.IN_, the first CreateIniKeyValue entry 
          is missing a value argument. Depending on whether
          MYLIB.MDA should be opened for read-only (ro) or 
          read-write (rw) access, replace the example with one 
          of the following:

          CreateIniKeyValue, $(WindowsPath)$(IniFileName),_
          "Libraries", $(AppPath)"MYLIB.MDA", "ro"

          CreateIniKeyValue, $(WindowsPath)$(IniFileName),_
          "Libraries", $(AppPath)"MYLIB.MDA", "rw"

          NOTE: The underscore character (_) is used here as
          a line-continuation character. In your STFSETUP.IN_
          file, these entries should appear on a single line.

Manual:   THE SECRETS OF ACCESSWIZARDS
    
Chapter:  2, "Incantations: AccessWizard Functions and Properties"
Section:  "CreateControl, CreateReportControl Functions"
Page:     12-15
          Documentation of the CreateControl function omits the
          fact that the function does not generate an error if 
          you specify a parent control that does not exist.

          Also, this section omits the fact that controls created 
          with these functions are not immediately visible. To 
          make them visible, you can perform an action that 
          causes Microsoft Access to display the control; for
          example, set a property for the control.

Manual:   THE SECRETS OF ACCESSWIZARDS
    
Chapter:  2, "Incantations: AccessWizard Functions and Properties"
Section:  "CreateForm, CreateReport Functions"
Page:     15
          In the Remarks section, the database argument 
          description incorrectly says that if the argument is
          omitted, Access Basic uses the same value as returned
          by the CurrentDB function. Access Basic uses the 
          database name, not the value returned by the CurrentDB
          function, which returns a database object. Replace, to 
          the end of the sentence, the phrase beginning with "if 
          the argument is omitted..." with the following phrase:
      
          "if the argument is omitted, Access Basic uses the name 
          of the current user database."

          NOTE: The name used must be the name of an open 
          database rather than the path of a database file.

          Also, documentation of these functions omits the fact
          that they do not generate an error if you specify
          a formtemplate or reporttemplate that does not exist.
          If the template does not exist, Access Basic uses the
          form or report template set with the Options command
          on the View menu.

Manual:   THE SECRETS OF ACCESSWIZARDS
    
Chapter:  2, "Incantations: AccessWizard Functions and Properties"
Section:  "CreateGroupLevel Function"
Page:     16
          Documentation of the CreateGroupLevel function omits the
          fact that the function generates an error if the Sorting
          and Grouping dialog box is open when the function is 
          called.

          The best way to handle this error is to trap it in 
          Access Basic, use a DoCmd action to close the dialog
          box, and then reinvoke the function.
     
Manual:   THE SECRETS OF ACCESSWIZARDS
    
Chapter:  2, "Incantations: AccessWizard Functions and Properties"
Section:  "DeleteControl, DeleteReportControl Functions"
Page:     17
          DeleteControl and DeleteReportControl are documented as
          functions, but instead they are Access Basic statements.
          Replace the Syntax entries for DeleteControl and
          DeleteReportControl with the following:

          DeleteControl formname, controlname
          DeleteReportControl reportname, controlname

          Also, replace references to DeleteControl and
          DeleteReportControl as functions with references to them
          as statements in the section title and throughout the
          manual.

Manual:   THE SECRETS OF ACCESSWIZARDS
    
Chapter:  2, "Incantations: AccessWizard Functions and Properties"
Section:  "PrtMip Property"
Page:     27
          The description of the Item Layout setting incorrectly 
          says you can enter an integer value of 1 for Horizontal 
          layout or 2 for Vertical layout of report columns. The 
          valid values are 1953 for Horizontal layout and 1954
          for Vertical layout.
