Alison Balteramp;#039;s Mastering Microsoft Office Access 1002003 [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Alison Balteramp;#039;s Mastering Microsoft Office Access 1002003 [Electronic resources] - نسخه متنی

Alison Balter

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید



Using Full Versions Versus Runtime Versions of Access


Many people have the misconception that using the Packaging Wizard and distributing your application using the Access runtime version somehow means that the application is compiled. This is not the case at all! In fact, if you do not properly secure the database, anyone can install his own copy of Access and modify the application's data and other objects just as you can. Using the Packaging Wizard and distributing your application with the Access runtime version does not modify the database in any way. It simply gives you the license to freely distribute the engine required to run your application.

Actually, the engine is not even a modified version of the Access executable! The MSACCESS.EXE file that you distribute is the same as the MSACCESS.EXE that you use to build your application. When you create installation disks for your users with the Packaging Wizard, the installation process copies the same MSACCESS.EXE file to the installation disks. So, how can there be any difference between the retail and runtime versions of Access?

When the user installs your application, the installation process copies the MSACCESS.EXE to the user's machine. During this process, the installation program checks a Windows Registry licensing key to see whether the user owns a copy of Access. If the licensing key indicates that the user does not own a copy of Access, or if the key does not exist, the licensing key (which is a set of numbers and letters) is updated to indicate that the user will be using the runtime version of the product. When Access executes and the runtime licensing key is found, the product launches in runtime mode.

When the runtime licensing key is found, Access behaves differently than it does when the full licensing key is found. If you are not aware of the differences, you will be quite surprised when certain aspects of your application no longer function as expected. The following is a list of the limitations of the runtime versions of the product:

  • The Database window is hidden

  • Design views are hidden

  • Built-in toolbars are not supported

  • Some menu items are not available

  • Certain keys are disabled


Hidden Database Window


When users launch your application using the runtime version of Access, the Database window is not visible. It's actually there, but it is hidden because its colors are set to the same colors as the Windows background color. This means that you can interact with the Database window using code, but the users of your application will be unable to interact with the Database window directly.

The fact that the Database window is hidden tends to be a double-edged sword. On the one hand, it prevents most users from modifying the objects in your application. On the other hand, it puts the responsibility on you to build a complete interface for your application. Remember that, for you as a developer, the Database window is a starting point. You must provide a different starting point and navigational tools for your users to maneuver throughout your application.

Hidden Design Views


The users of your application won't have direct access to any design views, which means that they are unable to create or modify tables, queries, forms, reports, macros, or modules. You still can get to all this functionality through code, though. You can build a wizard that enables your users to define all aspects of a query or some other object, for example, and then build the query (or other object) using ADO (ActiveX Data Objects) code. Again, this helps protect your application from novice users, but it puts the pressure on you to ensure that your application provides its users with all the functionality they need.

Built-In Toolbars Not Supported


All built-in toolbars are completely unavailable with the runtime version of Access, which means that you must design your own toolbars and attach them to your forms and reports as appropriate. This is covered in the "Adding Custom Menus and Toolbars" section of this chapter.

Unavailable Menu Items


Built-in toolbars are not supported at all when using the runtime version of Access. Menus are simply modified after the runtime key is found. Many menu items are hidden in the runtime version. These hidden menu items prevent users from making changes to your application.

Although many of the menu commands are hidden from the user, they can be accessed by using the DoMenuItem command. In other words, the functionality is there, but it is simply hidden from your users.

Disabled Keys


Several keystrokes are unavailable to your users when they run your application with the runtime version of Access. Table 32.1 lists these keystrokes.

Table 32.1. Disabled Keys

Keys

Function

Ctrl+Break

Halts macro and code execution

Shift (when opening the database)

Prevents execution of the AutoExec macro and ignores Startup properties

Alt+F1/F11

Displays the Database window

F12

Displays the Save As dialog box

Shift+F12

Saves a database object

Ctrl+G

Displays the Debug window

Ctrl+F11

Toggles between custom and built-in toolbars

As you can see, these are keys that you would rarely, if ever, want your users to use. You might consider the disabling of these keystrokes a positive side effect of using the runtime version of the product.


/ 544