Third Of Five - just another voice in the Collective : Access 2007 (aka "Access 12")

Access 2007's Improved Command Buttons

ThirdOfFive — Thu, 19 Oct 2006 19:00:00 GMT

Up until this point, Access has supported command buttons with text or a picture, but never both at the same time. This has been a long standing request from users: the capability of showing both the caption and the picture. In Access 2007, you will notice a new property off of the command button called "Picture Caption Arrangement".

This property, which can be set to the following values:

No Picture Caption - This setting is the legacy behavior. If you have a caption specified, the button will show it. If you have a picture, only the picture will be shown;
General - The image will be shown to the left of the text (if you're in a left-to-right language, like English) or the right of the caption (if you're in a right-to-left language, like Hebrew);
Top/Bottom/Right/Left - The image will be shown in the specified arrangement: at the top, bottom, right or left of the caption (just pick one).

You will also notice that there is a new "Arrangement" property. This property allows you to position the caption and picture within the command button to the following settings:

General - This is the legacy behavior. The image and caption will be positioned the left of the text (if you're in a left-to-right language, like English) or the right of the caption (if you're in a right-to-left language, like Hebrew);
Left/Center/Right - The image and caption will be positioned to the left, centered or to the right (just pick one);
Distribute - This is equivalent to the "justified" setting in Microsoft Word. The image and caption will be spaced out to fill out the command button.

With these two new properties (which are of course also available through the OM), you will now be able to create some cool looking command buttons without any label trickery needed. Since you can now use JPEGs, PNGs and other newer image formats with Access 2007, you can create some really impressive buttons.

For example, in the snapshot below I created three buttons using Windows Vista backgrounds as the pictures. I changed the buttons' back style to transparent and played with the alignment and picture caption alignment settings:

The New Import/Export Specifications UI

ThirdOfFive — Tue, 17 Oct 2006 19:00:00 GMT

As I previously mentioned, we are now exposing Import/Export Specifications (Imex Specs) in the OM in a thorough manner. We also took the time to make importing and exporting less repetitive in the UI.

In the past, to make use of Imex Specs, you had to go through part of the import/export wizard until you could load the Imex Specs and then go through with the loaded settings. It was still required to go through a number of clicks that are, well, pointless since you had already saved all the settings required to execute the Import/Export operation.

In Access 2007, when you go through the Import/Export wizard, you will see a new option in the last page of the wizard. The "Save export steps" (or import for the Import case) will save all your settings in an Import/Export Specification (with the name and description you provide). You are also given the option of creating an Outlook task to remind you of going through this task again when you want to.

You will also notice two new buttons in the "External Data" tab called "Saved Imports" and "Saved Exports" (see screenshot below).

If you click on these buttons, you will see the list of Import/Export Specifications you saved, and you can simply click "Run" to run them or "Delete" to remove them.

If you click on the "Run" button the Import/Export task will be run automatically, so you won't need to go through the entire Import/Export wizard.

You might wonder if this new UI doesn't conflict with the legacy (Access 2003 and earlier) Imex Spec UI. The answer is yes and no.

As I hinted to in my previous post, there are new Import/Export Specifications in Access 2007 that are not backed by the MSysIMEXColumns and MSysIMEXSpecs tables. These new Imex Specs are created through the OM (as explained in my previous post) and through the UI above. They are not visible to previous versions of Access and are stored in the database storage stream - not in tables.

As for Imex Specs created in Access 2003 and earlier, they are not visible to the new OM or UI. They will still run fine though (since the "Advanced" option in the Import/Export Wizard is still made available and is fully functional). I hope this clarifies how the old and new Imex Specs fit into the overall picture.

Customizing the Office Button Menu (aka File Menu) and No-Ribbon Custom Solutions

ThirdOfFive — Fri, 13 Oct 2006 19:00:00 GMT

Even though most of the information on how to customize the Ribbon in Access 2007 is already out, there are two recurring question that I've been seeing being asked often:

How can I customize the Office Button Menu (aka File Menu)?

We allow you to show/hide any controls off of the Office Button menu, effectively customizing it fully. The way to do it is by specifying a custom ribbon, following these steps:

Create a "USysRibbons" table;
Create two fields: RibbonName (type 'Text') and RibbonXml (type 'Memo');
Add a new record with any RibbonName you want (say, "Default");
Edit the record's RibbonXml to add an XML like this:
<customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
<ribbon>
  <officeMenu>

   
   <control idMso="FileNewDatabase" visible="false"/>
   <control idMso="SourceControlCreateDatabaseFromProject" visible="false"/>
   <control idMso="FileOpenDatabase" visible="false"/>
   <control idMso="FileSave" visible="false"/>
   <control idMso="ConvertDatabaseFormat" visible="false"/>
   <control idMso="FileSaveAsMenuAccess" visible="false"/>
   <control idMso="FileManageMenu" visible="false"/>
   <control idMso="FileSendAsAttachment" visible="false"/>
   <control idMso="MenuPublish" visible="false"/>
   <control idMso="FileServerMenu" visible="false"/>
   <control idMso="FileCloseDatabase" visible="false"/>

   
   <control idMso="FilePrintMenu" visible="true"/>
</officeMenu>
</ribbon>
</customUI>
Save the table and restart the database;
File Menu, Access Options, Current Database. In Toobar Options, set the "Ribbon Name" property in the "Ribbon and Toolbar Options" to the name you gave to this custom ribbon in step 3 (say, 'Default');
Restart the database.

In the example above, you will notice that the File Menu only has now the Print button. Of course, you can add your own commands here.

There is however a small caveat as you probably noticed above: you will still have the "Access Options" button in the File Menu. To get rid of it, you will need to change the "Allow Full Menus" property (off of the Current Database options in the Access Options - same location as the "Ribbon Name" option above) to "No". When you set "Allow Full Menus" to "No", not only 'Access options' goes away, but most of the Ribbon tabs as well. At this point it is expected that you really want to roll your own ribbons.

Can I keep my totally custom solution with custom toolbars or will I get the Ribbon anyway?

Finally, to allay some fears I heard being spread around: if you have a completly custom solution from Access 2003 or earlier where the built-in toolbars were disabled and you had custom menubars at startup, it will be shown as you designed it when opened in Access 2007. No ribbon will show up for it.

The New Import/Export Specification OM

ThirdOfFive — Thu, 12 Oct 2006 19:00:00 GMT

In previous versions of Access (such as Access 2003), you can save the steps from an import or export operation into what we call Import/Export Specifications (Imex Specs). After saving it, you can always load it back so you don't have to customize the settings over and over again.

One point of contention, however, has been that it was a complex procedure to be able to create, delete, copy or change imex specs programmatically. That is a pity because Imex Specs are all about allowing import and export commands (such as using DoCmd.TransferText) to be automated.

For Access 2007, we are now exposing Imex Specs programmatically so you can create, delete, copy or change them at will. You will notice that now there is a new method off of the CurrentProject object: ImportExportSpecifications. This object is a collection where three particular methods are interesting to us:

CurrentProject.ImportExportSpecifications.Count - allows you to get the number of Imex Specs that this database currently has.
CurrentProject.ImportExportSpecifications.Item - gives you access to the ImportExportSpecification objects, who in turn expose the data in the specs:
- Name - This obviously contains the name of the Imex Spec you specified when you saved it.
- Execute - This method will run the Imex Spec.
- Delete - This method allows the Imex Spec to be deleted.
- Description - Contains the description text for the Imex Spec.
- XML - This method will return an XML representation of the Imex Spec. For example:

? CurrentProject.ImportExportSpecifications.Item(0).XML

<?xml version="1.0"?>
<ImportExportSpecification Path="c:\temp\1.txt" xmlns="urn:www.microsoft.com/office/access/imexspec">
    <ExportText TextFormat="Delimited" FirstRowHasNames="false" FieldDelimiter="," TextDelimiter="{DoubleQuote}" CodePage="1252" AccessObject="Table1" ObjectType="Table">
        <DateFormat DateOrder="MDY" DateDelimiter="/" TimeDelimiter=":" FourYearDates="true" DatesLeadingZeros="false"/>
        <NumberFormat DecimalSymbol="."/>
        <Columns PrimaryKey="{Auto}">
            <Column Name="Col1" FieldName="ID" Indexed="NO" SkipColumn="false" DataType="Long" Width="11"/>
        </Columns>
    </ExportText>
</ImportExportSpecification>

CurrentProject.ImportExportSpecifications.Add - This method allows you to create ImportExportSpecification objects. By giving it the name of the Imex Spec and the XML representation, one can create as many Imex Specs as wanted. You can also use this to copy Imex Specs:

CurrentProject.ImportExportSpecifications.Add "New", CurrentProject.ImportExportSpecifications.Item(0).XML

As you can see, Imex Specs are now easy to be created, deleted and changed (by making changes to the XML data). This should make automating import/export tasks even easier to be automated than they already were.

There is one caveat to all of this, though. The Imex Specifications exposed through the OM above (or created through it) are not the ones created in the Import/Export Wizard through the "Advanced" button (as in Access 2003 and earlier). There are new Import/Export Specifications in Access 2007 that are not backed by the MSysIMEXColumns and MSysIMEXSpecs tables. I'll talk about these in my next post.

The New Access 2007 Switchboards

ThirdOfFive — Thu, 05 Oct 2006 19:00:00 GMT

Now that Access 2007 Beta 2 Technical Refresh (B2TR) is out, you will notice that we changed the Switchboard Manager functionality. Now that we have Disabled Mode and Embedded Macros, it was about time we revisited the switchboards that the Switchboard Manager cranks out and come up with something that is more up-to-date.

The first you will notice is that switchboards are now VBA free. They are run using embedded macros, and the primary goal is pretty clear: being able to run in disabled mode. The secondary goal is that this also makes them easy to change without major VBA knowledge.

To make switchboards easily extendable and maintanable, their design is actually pretty ingenious. There are two components: the switchboard forms (each created switchboard) and an underlying table for all switchboards (the "Switchboard Items" table).

The "Switchboard Items" table is a table with the following columns:

SwitchboardID (Number) - This ID indicates the switchboard this row belongs to.
ItemNumber (Number) - This is the ID of the item on the switchboard. This is of course only unique within a switchboard. Each item in a switchboard will translate to a button, except the one with ID = 0. The first item in the switchboard contains the title of the switchboard.
ItemText (Text) - This will contain the text used for the item in the switchboard.
Command (Number) - This indicates which one of the possible commands (e.g. open switchboard, open form in edit mode, etc) the button in the switchboard will execute.
Argument (Text) - Contains the argument that the command will need. For example, for opening a form in edit mode this argument will contain the form name.

For example, the switchboard table could look like this:

SwitchboardID	ItemNumber	ItemText	Command	Argument
1	0	Title		Default
1	1	foo	5
1	2	aaaa	3	Form1

In this case, this is a switchboard called "foo" with two buttons: the first ("foo") opens the switchboard manager and the second ("aaaa") opens "Form1" in edit mode.

Now, let's move on to the switchboard forms. Below you can see a snapshot of a sample one in design mode. The first thing you should notice is that it is bound to the "Switchboard Items" through a query that will limit it to only read switchboard items that are related to this specific switchboard (such as "SELECT * FROM [Switchboard Items] WHERE [ItemNumber]>0 And [SwitchboardID]=TempVars!SwitchboardID ORDER BY [ItemNumber];").

The form has an embedded macro on its OnOpen event (below). The embedded macro will set the Temporary Variable (TempVar) called SwitchboardID with the ID for this switchboard and will set the label of the buttons to match the values in the table (in the example above, "foo" and "aaaa"). There should be one SetProperty call here for each button in the form. Notice that the query mentioned above makes use of this SwitchboardID TempVar to be able to narrow down the data to only relevant items.

As for the button on it, it has an embedded macro on the OnClick event. This embedded macro is the real brain of the switchboard. It contains all the necessary actions to perform all the possible commands you choose in the Switchboard Manager. Below is the embedded macro:

This embedded macro is actually straightforward. Based on the Command # (the column value for the record you clicked on the continuous form) you clicked on, we will only run the necessary code to run that action. The error handling is basically putting up an error message with the last erorr hit. If you run an unknown command, the "Unknown Option" message is shown.

As you can see, it's a very simple design that can be extended in a straightforward manner. You can add your own command ID and logic in the button embedded macro, even one that call VBA (say, after checking that this is not a disabled solution, as explained here). Of course, the switchboard manager will not necessary understand what you did, but who cares? Now you know enough to go on your own.

Disclaimer: everything discussed in this article is subject to change until Access 2007 ships. Note, however, that we don't expect any major changes. Perhaps some of the embedded macro logic and the visuals will change, but I wouldn't expect (don't guarantee however) anything "major". Of course, you should not take this as a guarantee and blah blah bla (see blog disclaimer for legalese).

Quick Trick: Copying Embedded Macros from one Property to another

ThirdOfFive — Thu, 28 Sep 2006 19:00:00 GMT

Now that we spent all this time talking about templates, how about we put to use something we learned about it in a totally unexpected way? Remember that we talked about how embedded macros are really represented as SaveAsText/LoadFromText alongside objects?

Unlike VBA code associated with event properties (e.g. OnLoad, etc) and like other 'simple' properties (such as the Default view Property), you can copy an embedded macro from a control/form/report's property to another (or the same) control/form/report property.

The trick is that for each event property off of form/report/controls, there is a "shadow" property that contains the embedded macro for that event property. For example, the OnLoad property has a dual OnLoadMacro property that contains its embedded macro (if there is one, otherwise it's empty).

So, it's very easy to copy embedded macros around by simply writing code that looks like this:

Forms(0).Controls("foo").OnLoadMacro = Forms(1).Controls("bar").OnOpenMacro

Of course, if you look at what actually is in the .*Macro "shadow properties", you will find out that it is the same output that a DoCmd.SaveText acMacro, "foo", "Macro1" has. This means that you can easily load/save/copy standalone macros to/from embedded macros.

Templates: How to create your own

ThirdOfFive — Wed, 27 Sep 2006 07:00:00 GMT

Now that we discussed extensively all about templates, we can talk about how this all this can be put at your service.

You see, we will give you the capability (though not in the Access product itself - details will be forthcoming soon, hopefully) to generate templates out of any database (not ADPs, though). By using a very simple wizard where you simply feed in the preview image, title, description and such, you will create an ACCDT file.

Additionally, if you work in a corporation, you can use deployment scripts to copy your own company templates into the template store folders. This is a very effective way to deploy your workflow Access applications across your whole organization. This means that you can develop a database, brand it as you will and make it up to spec with your corporate guidance and then simply generate a template that can be deployed throughout your organization using traditional Window group policy mechanisms.

Templates: Programmability

ThirdOfFive — Thu, 21 Sep 2006 19:00:00 GMT

Now that we talked about what Access 2007 templates are made of and how Access makes use of them to create brand new databases, it begs the question as to what you can programmability-wise.

The answer to that question lies in the fact that we changed Application.NewCurrentDatabase by adding a new couple of optional arguments. Here is the new signature of this function:

Sub Application.NewCurrentDatabase(filepath As String, _

Optional FileFormat As AcFileFormat, _

Optional Template As Variant, _

Optional SiteAddress As String, _

Optional ListID As String)

Here are the new optional arguments:

· Template - String path to the template to instantiate or an integer SharePoint list template ID;

· SiteAddress - URL to the SharePoint site to link to;

· ListID - GUID or Name of the list to link to;

As we mentioned before, templates can be closely tied to SharePoint. The last two parameters allow you to instantiate a template and link to a SharePoint site in the process. Under the covers, this is very similar to the functionality made available through DoCmd.TransferSharePointList, which links SharePoint lists.

Templates: SharePoint comes into Play

ThirdOfFive — Tue, 19 Sep 2006 19:00:00 GMT

When you go create your new database from a template using Access 2007, you will notice a checkbox right by the OK button and path where you will create the file. By checking the “Create and Link your Database to a Windows SharePoint Services Site”, instead of just creating a local database, lists will be created in the SharePoint site and the database will link to them. The Access database will then serve as a rich front-end client running with SharePoint as its back-end.

To put it in simple words, with the new templates, the data backend can be either Access or SharePoint.

It’s worth mentioning that the templates made available for Access 2007 are made in such a way that they translate their functionality perfectly (such as the Append Only feature we talked about some time ago) between Access and SharePoint.

Templates: The Template Store

ThirdOfFive — Thu, 14 Sep 2006 19:00:00 GMT

No, that is not a new franchise opening near you. So far we talked a lot about what templates are, how we use them and all, but where are they?

Well, they are actually in different locations in your hard drive. Do you think we would make this easier on you?

Templates that are shipped with Access 2007 and are not SharePoint-related live in

<Office Install Folder>\Templates\<LCID>\Access\.

SharePoint-related Templates are installed in < Office Install Folder >\Templates\<LCID>\Access\WSS\

Templates downloaded from Office Online are installed to %USERPROFILE%\Application Data\Microsoft\Templates\

If you are wandering what these LCIDs stand for, they stand for Locale IDs and they identify what language/country/area your version of Office comes from. If you are using English and you’re in the US, this is 1033.

More recently, these kind of locale IDs in software products have been gravitating towards the standardized RFC 3066 language codes, such as “en-us”. However, for this release at least, this is not the case for these template locations.

Templates: The Instantiation Process

ThirdOfFive — Tue, 12 Sep 2006 19:00:00 GMT

As we’ve seen in the previous posts, Access 2007 templates are not really database files per se, but simply a set of data and meta-data that will allow Access to create a brand new database file every time.

At a high level, the process to instantiate a template works like this:

1. First, we create a blank database in user-specified location;

2. The database is opened in disabled mode;

3. We load the database objects and properties;

a. Set the Database Properties;

b. Add the VBA references;

c. Create each of the Access Objects (forms, tables, reports, macros and queries);

d. Create the Relationships;

e. Load the Navigation Pane information;

4. Do the necessary localization: flip right-to-left, name autocorrect and fix up labels if necessary.

5. Close the database;

6. Open the database again;

Templates: Where did the embedded macros go?

ThirdOfFive — Thu, 07 Sep 2006 19:00:00 GMT

Now that we saw how macros, queries, forms, reports and tables are persisted in templates, we can ask: what about embedded macros?

Since embedded macros live in the event properties of form, reports and controls, they are persisted along with the object that contains them. For example, let’s say that a form has a control which OnClick event has an embedded macro. If we look at how the form is persisted, the embedded macro will be clear. See below in red:

Version =20

VersionRequired =20

Checksum =1875235619

Begin Form

DividingLines = NotDefault

AllowDesignChanges = NotDefault

DefaultView =0

TabularCharSet =204

PictureAlignment =2

DatasheetGridlinesBehavior =3

GridX =24

GridY =24

Width =8884

DatasheetFontHeight =11

ItemSuffix =1

Right =7755

Bottom =7860

RecSrcDt = Begin

0x5e1d77333303e340

End

GUID = Begin

0x215548c7105bb74f9c5a62a34852d43e

End

NameMap = Begin

0x0acc0e5500000000000000000000000000000000000000000c00000004000000 ,

0x0000000000000000000000000000

End

DatasheetFontName ="Arial"

FilterOnLoad =0

DatasheetBackColor12 =16777215

ShowPageMargins =0

DisplayOnSharePointSite =1

DatasheetAlternateBackColor =16053492

DatasheetGridlinesColor12 =16765357

FitToScreen =1

Begin

Begin CommandButton

FontSize =11

FontWeight =400

ForeColor =-2147483630

FontName ="Calibri"

LeftPadding =30

TopPadding =30

RightPadding =30

BottomPadding =30

GridlineStyleLeft =0

GridlineStyleTop =0

GridlineStyleRight =0

GridlineStyleBottom =0

GridlineWidthLeft =1

GridlineWidthTop =1

GridlineWidthRight =1

GridlineWidthBottom =1

End

Begin Section

Height =7560

Name ="Detail"

GUID = Begin

0x074cc32161de494c80853bffa393c314

End

AutoHeight =1

Begin

Begin CommandButton

OverlapFlags =85

Left =2820

Top =300

Width =1800

Height =1560

Name ="Command0"

Caption ="Command0."

GUID = Begin

0x57ec04af6fab7346a743706d495ed583

End

OnClickEmMacro = Begin

Version =196611

ColumnsShown =8

Begin

Action ="MsgBox"

Argument ="foo"

Argument ="-1"

Argument ="0"

End

LayoutCachedLeft =2820

LayoutCachedTop =300

LayoutCachedWidth =4620

LayoutCachedHeight =1860

End

The reality is that this persistence representation of the object and the embedded macro shows some implementation details about embedded macros. The key is in the “OnClickEmMacro” property name used above.

Embedded macros actually are not store in the event property themselves (say, On Click), because those only hold things like “[Event Procedure]”, “Macro1”, “=Foo(1+2)” and such. Embedded macros are actually store in hidden properties that exist corresponding to every single event property. We call them “shadow” properties. These shadow properties are actually exposed through the OM, but also in a hidden manner. You will notice that for every event property OM (e.g. Control.OnClick) there is a corresponding shadow property (e.g. Control.OnClickMacro).

Even further, if you create an embedded macro and open the immediate window in the VBE editor and query for the shadow property (such as: “? Form(0).Controls(“foo”).OnClickMacro”), you will see an output that looks something like this:

Version =196611

ColumnsShown =8

Begin

Action ="MsgBox"

Argument ="foo"

Argument ="-1"

Argument ="0"

End

Doesn’t it look familiar? Well, it is the same output as it was saved in the form above for templates. You see, you can read (and write!) to these shadow properties using the SaveAsText/LoadFromText format for plain macros.

Do I smell an embedded macro to standalone macro converter add-in? How about an embedded macro reporter and analyzer for databases? The world is the limit here…

Templates: Access Objects parts

ThirdOfFive — Tue, 05 Sep 2006 19:00:00 GMT

Last week I talked about how the template core data is laid out. Now, I’ll focus on the actual Access objects.

For every Access object part (each file in template\database\objects), there is a corresponding” XML file in the \template\database\objects\properties folder containing it’s properties: type and name. For example:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

- <AccessObject xmlns="http://schemas.microsoft.com/office/access/2005/04/template/object-metadata">

<Type>Form</Type>

<Name>Add Related Issues</Name>

</AccessObject>

Now, as for the object itself, there are two types of objects: tables and everything else (form, reports, macros and queries). The table objects are XSD files, with the customary .xsd extension.

Since XSD files only define schema, the actual data within these tables are saved in the template/database/objects/sampleData folder, in XML format. There is one XML sample data file for each XSD file in the folder above: both constitute one table.

As for the form, queries, reports and macros, these are simple text files in template\database\objects. These are not XML, XSD or such – they are actually the SaveAsText/LoadFromText persistence format already used elsewhere in Access. For example, here’s what a query looks like:

Operation =1

Option =0

Where ="(((Issues.Status)<>\"Closed\" Or (Issues.Status) Is Null))"

Begin InputTables

Name ="Issues"

End

Begin OutputColumns

Expression ="Issues.*"

End

Begin OrderBy

Expression ="Issues.Status"

Flag =0

Expression ="Issues.Priority"

Flag =0

Expression ="Issues.[Due Date]"

Flag =0

End

dbBoolean "ReturnsRecords" ="-1"

dbInteger "ODBCTimeout" ="60"

dbByte "RecordsetType" ="0"

dbBoolean "OrderByOn" ="0"

dbByte "Orientation" ="0"

dbByte "DefaultView" ="2"

dbBoolean "FilterOnLoad" ="0"

dbBoolean "OrderByOnLoad" ="-1"

dbBinary "GUID" = Begin

0xa26c0cbd84d1be499edb2029597a5e25

End

dbBoolean "TotalsRow" ="0"

dbLongBinary "DOL" = Begin

0x0acc0e5500000000cce68fc558b3bd4a9ab9ec7673e9b5cd00000000ea387df8 ,

0xef00e3400b000000c05f11004900730073007500650073000000000000007c14 ,

0xd0158996884e8e1461b254a168da07000000cce68fc558b3bd4a9ab9ec7673e9 ,

0xb5cd53007400610074007500730000000000000046b553afdd076a40a5be3384 ,

0x98df0bda07000000cce68fc558b3bd4a9ab9ec7673e9b5cd5000720069006f00 ,

0x72006900740079000000000000004a6c0fd2c964584eb9cea65e577d52090700 ,

0x0000cce68fc558b3bd4a9ab9ec7673e9b5cd4400750065002000440061007400 ,

0x6500000000000000000000000000000000000000000000000c00000004000000 ,

0x0000000000000000000000000000

End

Begin

End

Begin

State =0

Left =0

Top =0

Right =776

Bottom =710

Left =-1

Top =-1

Right =760

Bottom =213

Left =0

Top =0

ColumnsShown =539

Begin

Left =48

Top =12

Right =192

Bottom =156

Top =0

Name ="Issues"

Name =""

End

As per our previous discussion about the LoadFromText and SaveAsText formats and functions, it is not surprising that tables use a different mechanism, right?

The other folders (“AddFuriganaVariation”, etc) are internal mechanisms we use to be able to generate localizable templates. We need to be able to deal with requirements such as right-to-left content flipping, font replacement depending on locale and others. That’s why we have copies of specific objects in these folders – so we can do specific treatment when necessary.

Templates: Quick Overview of SaveAsText and LoadFromText (aka let’s get boring again)

ThirdOfFive — Thu, 31 Aug 2006 19:00:00 GMT

Before we dive into the way the Access Objects are persisted in the Access 2007 template files, I thought it would be best if we talked briefly about the Application.SaveAsText and Application.LoadFromText methods and what they generate and read in, respectively.

In case you don’t recognize these two methods, don’t be surprised: they are hidden and undocumented. Before we get all cloak and dagger, it’s worth saying that these methods are not undocumented as in here, but as in here. Now, let’s take a look at the signature for these methods:

Sub Application.SaveAsText(ObjectName As String, _

ObjectType As AcObjectType, _

FileName As String)

Sub Application.LoadFromText (ObjectType As AcObjectType, _

ObjectName As String, _

FileName As String)

For both of these methods, you specify an object type, the name of the object and a name of a file. For SaveAsText, the given object is stored in a text format in the given file, and for LoadFromText, an object is created given a text format in the given file.

If you look at the text format for a simple form with a single button on it, it looks like this:

Version =20

VersionRequired =20

Checksum =-540535037

Begin Form

DividingLines = NotDefault

AllowDesignChanges = NotDefault

DefaultView =0

TabularCharSet =204

PictureAlignment =2

DatasheetGridlinesBehavior =3

GridX =24

GridY =24

Width =8884

DatasheetFontHeight =11

ItemSuffix =2

Right =7755

Bottom =7860

RecSrcDt = Begin

0x5e1d77333303e340

End

GUID = Begin

0x215548c7105bb74f9c5a62a34852d43e

End

NameMap = Begin

0x0acc0e5500000000000000000000000000000000000000000c00000004000000 ,

0x0000000000000000000000000000

End

DatasheetFontName ="Arial"

FilterOnLoad =0

DatasheetBackColor12 =16777215

ShowPageMargins =0

DisplayOnSharePointSite =1

DatasheetAlternateBackColor =16053492

DatasheetGridlinesColor12 =16765357

FitToScreen =1

Begin

Begin CommandButton

FontSize =11

FontWeight =400

ForeColor =-2147483630

FontName ="Calibri"

LeftPadding =30

TopPadding =30

RightPadding =30

BottomPadding =30

GridlineStyleLeft =0

GridlineStyleTop =0

GridlineStyleRight =0

GridlineStyleBottom =0

GridlineWidthLeft =1

GridlineWidthTop =1

GridlineWidthRight =1

GridlineWidthBottom =1

End

Begin Section

Height =7560

Name ="Detail"

GUID = Begin

0x074cc32161de494c80853bffa393c314

End

AutoHeight =1

Begin

Begin CommandButton

OverlapFlags =85

Left =1800

Top =960

Width =900

Height =840

Name ="Command1"

Caption ="Command1"

GUID = Begin

0x3822e4b79de09b4b8acf9150c95debd3

End

LayoutCachedLeft =1800

LayoutCachedTop =960

LayoutCachedWidth =2700

LayoutCachedHeight =1800

End

As you can see, this format is pretty straightforward: blocks are defined by the BEGIN … END clauses and each property off of the object takes the format of <PROPERTY NAME> = <VALUE>.

The control, called “CommandButton” is within a BEGIN … END loop at the end of the description of the form, and its own properties are also described under them. Tabs clearly define a hierarchy here.

You will also notice that the binary properties (such as NameMap and GUID) get BEGIN … END blocks with their value codified in hexadecimal numbers. The LoadFromText/SaveAsText format obviously handles all property types for all Access objects: numbers, text, binary, enums…

Finally, Access is smart enough to only write out properties that have values that don’t match their defaults. This way we save a lot of space writing things we already know.

As an interesting tidbit, you will notice that the option to load and save tables is missing. Yes, you cannot save or load tables using this mechanism, and that’s for historical reasons. This mechanism was never meant as a import/export entry point, but as a simple way to create form, macros, report and queries from a pre-canned source, such as a number of the wizards shipped with Access.

Templates: The Meat of the ACCDT Template Files

ThirdOfFive — Mon, 28 Aug 2006 19:00:00 GMT

In my previous post, we cracked open an Access 2007 template file. For this post, I’d like to delve into the / template/database folder, where pretty much all the template content resides.

In the root of this folder you will notice four files, with very important roles:

· databaseProperties.xml – This file contains the database-level properties that the database created from of this template should have (such as what is the start up form, size of the Navigation Pane, etc). You can generally access these properties through the OM as well: CurrentDb.Properties(“StartupForm”). Here is a sample file:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

- <Properties xmlns="http://schemas.microsoft.com/office/access/2005/04/template/properties">

</Properties>

· NavPane.xml – This file describes the contents of three system tables: MSysNavPaneGroupCategories, MSysNavPaneGroups, MSysNavPaneGroupToObjects and MSysNavPaneObjectIDs. As the names obviously indicates, these tables define all the content within the Navigation Pane. Having both these tables and the NavPane-related properties in databaseProperties.xml, Access can completely define the state of the Navigation Pane.

· Relationships.xml – This file describes the contents of the MSysRelationships system table.

· vbaReferences.xml – This file contains the VBA external references.

Below the root folder is the objects folder. This folder contains all the database’s top level objects: forms, reports, query and macros. We call these AccessObject parts. I’ll post in more detail next week about these.