Third Of Five - just another voice in the Collective

After a long hiatus, I'm back to blogging.

And I also decided to move my blog elsewhere. Please do stop by...

(Happy 4th of July, everyone!)

I have decided to pursue other interests and will no longer be able to maintain this blog. It was a very interesting experience, to say the least. :)

Thank you for your time and all the comments!

Take care,
3oF

P.S.: I'll try to keep the posts around just in case. The blog itself will probably go read-only in a couple of days.

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:

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.

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:

1. Create a  "USysRibbons" table;
2. Create two fields: RibbonName (type 'Text') and RibbonXml (type 'Memo');
3. Add a new record with any RibbonName you want (say, "Default");
4. Edit the record's RibbonXml to add an XML like this:

   <customUI xmlns="http://schemas.microsoft.com/office/2006/01/customui">
    <ribbon>
     <officeMenu>
      
      <!-- First we hide all the items displayed by default -->   
      <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"/>
   
      <!-- Now let's show a single Print Command -->
      <control idMso="FilePrintMenu" visible="true"/>  
     </officeMenu>
    </ribbon>
   </customUI>

5. Save the table and restart the database;
6. 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');
7. 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.

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.

This is one of those features that almost nobody knows about because it isn't very discoverable. In Access 2007 (and earlier), you can change the default property values for any new controls in a form or report. Here are the necessary steps:

1. Open/Create form or report in design mode;
2. Select the "Design" contextual tab (or the equivalent toolbar with the controls for Access 2003 and earlier);
3. Open the Property Sheet (using the Ribbon or hitting ALT+ENTER);
4. Notice that the property sheet caption says "Selection Type: Default <Control>";
5. Change the properties at will;

From this point on, any new controls you create will have its default properties set to what you customized.

It's worth mentioning that any changes you make will only exist in the context of this form or report alone. However, you can also create settings that apply to all newly created Forms and Report. For this purpose, follow the same steps 1-5 above, and do one more:

   6. Save the Form or Reports with the name "Normal";

If there is a "Normal" (like Word's Normal.dot) form, all new forms will inherit its settings. The same goes for reports, but notice that form settings cannot be inherited by reports and vice-versa. Of course, if you delete the "Normal" form or report, you will not affect the default settings of the already created forms and reports since they already inherited them. Only newly form and reports from then on will not inherit the settings anymore.

This is a very neat feature to speed up creating a number of forms and reports that will use similarly set controls (or width/height even) without having to go through multiple copy and paste runs.

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:

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

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.

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.

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.

For troubleshooting Office 2007 Beta 2 Technical Refresh (B2TR) installs, you might want to check out this Knowledge Base (KB) article.

The most common problem that I heard so far is the that to install the B2TR update, you need at least 2 gigabytes (GB) of free disk space.

Good luck!

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.

I haven't seen any news about this yet, but it's already available for download. Check out this post on some of the changes in B2TR.

2007 Microsoft Office system Beta 2 Technical Refresh

Important: Prior to applying this Beta 2 Technical Refresh update, you must have installed the Beta 2 version of the associated 2007 Office system product. You can't just download the refresh and install it standalone.

You might also be interested in the PDF/XPS add-in made available right now:

2007 Microsoft Office Add-in: Microsoft Save as PDF or XPS

All of this downloads are listed here, alongside some other interesting downloads. Check it out!

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.