Liren Large Software Subsidy 6/06.iso/a/a563/1.ddi/README.TXT

Text File | 1993-05-07 | 22.0 KB | 578 lines

   ---------------------------------------------
   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.