Welcome to MSDN Blogs Sign in | Join | Help

Microsoft Access Team Blog

Get product announcements, tips and tricks, and news directly from the team @ Microsoft.
Customizing the New Access UI

I described the new Access UI in this post and this post way back in March.  Now I'll run through how you program the ribbon UI using VBA.  In a future post (we're still working out the content) I'll do another post on how to do the same thing using macros (so the app will run in disabled mode). 

Customized Ribbons

The ribbon UI presents a ton of new flexibility for us creating Access and for you building apps on top of Access that wasn't there before.  As described in the posts on the ribbons, there are a lot of new control types that can be placed in the ribbon, and there's much more flexibility about how they are presented.  The downside to this additional flexibility is that the ribbons are more complex to create than the old command bars.  Building ribbons isn't beyond the reach of any successful Access user today, but it will take some more work.  The upside is that the end product can be significantly better.

Here's an example of an application with a customized ribbon UI:

(Click image to enlarge)

The app has a rich set of controls, including a dropdown to let different users log on:

And of course after each user logs on, you can fire code to both update the contents of the ribbon itself and to take actions inside the application.  Here is an example of the changes to the ribbon itself:

(Click image to enlarge)

The application can have multiple tabs, just as Access does, and the user switches between them just as in the regular Access ribbons.  Here's the Form ribbon:

(Click image to enlarge)

In addition, custom ribbons can use the full range of controls available in Access.  Here's an example of a dropdown button on the Reports tab:

And an alternate split button presentation for the same data:

Controls on the ribbons can how have "Super Tooltips" (not sure if that is the real name?).  These are extra large tooltips containing more, and richer information than the command bar style tooltips, but that launch in just the same way.

Customizing the Ribbon

There are 5 steps to customizing the ribbons:

  • Create the ribbon XML - the ribbon definitions are done through an XML file, and the first step is to build that file.  This is pretty easily done with a simple text editor, but can be made even easier with Visual Studio tools.
  • Specify callbacks - next, you need to build small VBA routines that handle ribbon actions like clicking a button or selecting something from a dropdown.
  • Create table for XML file - next, you create an Access table to hold the XML you created in step 1.
  • Add the ribbon to that table - next you create a record in the table for each custom ribbon, containing the ribbon name and the XML definition of the ribbon.
  • Set the Custom Ribbon property - finally, you set the Custom Ribbon property for the database as a whole or for specific forms and reports to load the ribbon you defined in the table above. 

Creating the XML Ribbon Definition

The ribbon definition is a simple XML file and can be easily created in any text editor, but if you're using Microsoft Visual Basic.NET 2005 Express Edition or Microsoft Visual Web Developer 2005 Express Edition, you can get IntelliSense for your code.  Visual Web Developer looks something like this:

(Click image to enlarge)

You can point it at the custom ribbon schema at http://schemas.microsoft.com/office/2006/01/customui and VWD should pick up the correct file, which is called customUI.xsd.  Alternately, you can download the file from http://officeblogs.net/UI/customUI.xsd

(Click image to enlarge)

This enables VWD to provide type-ahead IntelliSense for the correct ribbon xml.

(Click image to enlarge)

You can see the XML file for the sample application we're building by clicking here.  The contents of the file are:

  1. customUI - this is the top level element for a custom ribbon
  2. ribbon - defines the ribbon itself.  Set the startFromScratch attribute = "true" to create a new blank ribbon.  If this is omitted or left blank, the custom ribbon will merge with the existing Access ribbons.
  3. tab - creates a new tab in the ribbon
  4. group - creates a group (or "chunk" in my ribbon description post).  These are used to logically group controls in the ribbon.
  5. id - unique name of a control in the ribbon
  6. label - static text displayed with a control
  7. button - similar to a command button.  Use the onAction attribute to specify the name of a subroutine in the database which will be called when the button is clicked.
  8. dropDown - creates a dropdown list that cannot be updated.  To create a drop down that the user can type in, use a comboBox control instead.
  9. imageMSO - specifies the name of a built-in control in Office that can be used as in icon in your ribbon.

Creating VBA Call-backs

Next, you need to write the routines that are called by the ribbon when an action is performed.  Here's what to keep in mind when writing these routines:

  • You'll need a reference to the Microsoft Office 12.0 Object Library
  • Arguments to Sub routines are fixed
  • In many cases, you can use a single routine for many events.  For example, you might have a single subroutine that handles opening forms in your database using button controls in the ribbon.  The tag attribute in the button can be used to store the name of the form, and the generic routine simply opens that form name.  For example, such a routine might look like this:

Public Sub onOpenForm(control as IRibbonControl)

    ' Open the form which is specified in the tag attribute

    DoCmd.OpenForm control.Tag

End Sub

  • To refresh the ribbon, call the Invalidate method on the IRibbonUI object.  This object is passed to you in the onLoad callback when the ribbon is loaded.  You can save an extra copy of this object to use as needed:

' Cached copy of the RibbonUI. Used to invalidate the ribbon to

' refresh controls.

Public gobjRibbon As IRibbonUI

 

' customUI onLoad event handler

Public Sub onRibbonLoad(ribbon As IRibbonUI)

    ' cache a copy of the Ribbon so we can refresh later

    Set gobjRibbon = ribbon

End Sub

 

' Then, to refresh the entire ribbon, call:

gobjRibbon.Invalidate

You can look at the macros in this example database to get a better idea of the code to write.

Creating the Ribbon Table

Simply create a table in your database called USysRibbons.  This table should have 2 columns:

  • RibbonName - type: Text(255)
  • RibbonXML - type:  Memo

The table should looks something like this:

Adding the Ribbon XML

Now simple create a record for each ribbon you'd like to create in the table above.  Note that this is already done in the image above.

Set Custom Ribbon Property

Next, you go to the Access Options dialog and under Toolbar Options, choose the ribbon for the selected object.  Again, you can see these settings most easily in the attached database. 

Tips, Tricks, and Additional Information

Here are a few general things to remember:

  • If you use VBA callbacks, the database must be opened in enabled mode for the code to run.  You may receive an error in Beta 2 when opening a database with custom ribbons in disabled mode.
  • Set a reference to the Office 12.0 Object Library to use IRibbonControl.  You'll get a compile error if you don't have the reference included.
  • Elements and built-in names of controls and images may change prior to release.
  • To edit the ribbon, and XML editor such as Microsoft Visual Basic.NET 2005 is quite handy.  The Express Edition works great.
  • Show system objects in the nav pane to modify the USysRibbons table
  • You can hold down the SHIFT key when opening the database to open it with the Access ribbon rather than your custom ribbon.  However, this doesn't work in the Beta 2 build (sorry about that).
  • You can show errors in the UI XML by turning on an option in Access.  If you open the Office menu (the round button), and select Access Options / Advanced  and then check "show user interface errors", Access will show a dialog describing any problems in the Ribbon XML.  The dialog will look something like this: 

         

For additional resources take a look at these sites:

Next Time

The next post will be the first of several drilling down into using Access in conjunction with Windows SharePoint Services.

 

Posted: Thursday, July 13, 2006 10:58 AM by Erik Rucker

Comments

Colt said:

Wow. Looks very cool. I'm going to try to use it in my app. Should be interesting...
# July 13, 2006 10:40 PM

David W. Fenton said:

Is the ribbon UI implemented by using the the IE rendering engine, the way some parts of the Outlook UI? It worries me if it is, as it means that Access then becomes subject to any security flaw or bug of any other kind in the IE rendering engine.

Please tell us that the IE rendering engine is not used for presenting the ribbon!
# July 13, 2006 10:44 PM

Stevbe said:

Is runtime going to include the necessary Office Lib?
# July 14, 2006 7:09 AM

Clint Covington said:

The ribbon rendering UI is an internal office library that is unrelated to the IE rendering engine.

>> Is runtime going to include the necessary Office Lib?

Sure. This is pretty fundamental to building an app.
# July 14, 2006 12:17 PM

Clint Covington said:

For those of you who want to completely get rid of the ribbon--here are the steps:

1. Create a new table called USysRibbons.
2. Add two fields RibbonName (text) and RibbonXML (Memo).
3. Create a new record with the name "Blank" (doesn't really matter what you call it). Also add the following XML:
<CustomUI xmlns="http://schemas.microsoft.com/office/2006/01/CustomUI"><Ribbon startFromScratch="true"/></CustomUI>
4. Restart your database.
5. Go into the Office Button | Access Options. Click on the Current Database.
6. In the Toolbars Option set the Custom Ribbon Id to Blank (name in step 3).
7. Restart the database.
# July 14, 2006 6:15 PM

Ken said:

I'm frankly more concerned with the new object task pane.  I would like to be able to display the objects in the database in a manner similar to the old database window so that we can see more objects without having to scroll down vertically as much.  As an example, I have a database that has 109 queries, 80 tables, 22 forms, 30 reports 18 modules, and several DAPs.  Navigating these objects using the current pane paradigm is somewhat of a pain (even with grouping option).  The problem could be solved if the current pane just provided the means to repint the object pane to allow the objects to form new columns when the pane is resized to the right.  Resizing the pane now has no effect as far as the contained objects are concerned objects are concerned.  It seems to me that as one resizes the pane to the right the vertical scroll bar should disappear and the objects should just appear in several rows as the view pane gets resizes to take up more of the screen.  This would make devolopment much easier when working with many different objects.
# July 17, 2006 1:07 PM

Annoyed said:


Microsoft:

There are 5 steps to customizing the ribbons:

Create an XML File and BLA, BLA, BLA...


Me:

I thought  Access was a RAD!

RAD:  Rapidity  Application  Developement...

I hope Access 12 supports still the old toolbars!



# July 18, 2006 6:35 PM

Andrew I said:

How are toolbars & buttons controlled by code?  How do you add a button to an existing toolbar using VBA?  Can you add/remove and enable/disable buttons and menu items at runtime any more easily than with current versions?

If you can still create toolbars and menus using VBA then it would probably be more convenient than the remarkable 5-step XML process you give above (admittedly the call-back routines would be required in any case).
# July 19, 2006 9:17 PM

Clint Covington said:

>> Navigating these objects using the current pane
>> paradigm is somewhat of a pain (even with grouping option).

Thanks for your feedback on the navigation pane Ken. Have you discovered the search bar? Internally, we have a db that we use for hours a day every day. It is about the size of your example and growing weekly. The people using the database have found the search bar far more useful than visually scanning through a large list of stuff. We are looking into improving the keyboard model so that it is easy to get focus into the control and quickly into the details section of the pane.

>> I hope Access 12 supports still the old toolbars!

The old toolbars OM is still supported. If you customized your toolbar using Access 2003 those customizations still apply. If you just extended our existing menus the commands get placed in the Add-Ins tab. If you have replaced our built in tool bars then your app should run without the ribbon. We don't support UI modifications of legacy menus and command bars.

>> How are toolbars & buttons controlled.
There is a new method called LoadCustomUI that takes a XML string. You add callback attributes (such as getVisible, getEnabled, and so forth) to the elements in your Ribbon XML that you want to change. Here is a list of all callbacks http://msdn2.microsoft.com/en-us/library/ms406047.aspx#office12customizingribbonuifordevelopers2_table12.

The following paper provides a pretty good overview with lots of details about Access specific details
http://msdn2.microsoft.com/en-us/library/ms406046.aspx.

I started working with ribbon customization last week and was surprised how easy it was to pickup. The syntax of the markup language is straight forward especially with a basic XML editor that provides type ahead. We will provide more and more icons, code and ribbon samples that should help get people started very quickly.

The model isn't perfect and could be easier for beginning developers; however, it does provide a rich system for building apps optimized for efficiency and discoverability.

# July 20, 2006 11:18 AM

Zen said:

Customizing Ribbons in Access 12 it is too much complex.

We need a "Visual Editor" to do it...

I have not understood if the icons must reside externally or they can be included in the FE.

IMHO the matter of  ribbons will be an enormous problem for Access Developers.

Access 2003 "forever"?   ;-)

Bye

P.S:
Setting reference to the Office library I have had many problems of "Lost References" with old Runtimes Edition of Access!!

The only solution:  www.sagekey.com



# July 21, 2006 4:09 AM

Mauro said:

Thank you for sharing with us your knowledge. Would be possible to have a sample of your database available?

Thanks, Mauro
# July 21, 2006 12:22 PM

Clint Covington said:

Zen,
I agree with you that a visual editor would be very cool--that was just something that couldn't get done in this release. I'm guessing third-parties will fill the gaps until we do something more native.

I think you might be surprised how easy it is to pull together--especially with a few examples. You simply import the USysRibbons table and start tweaking the Label, OnAction and msoImage attributes. When the next beta is released we will post a sample database that has rich ribbons and doesn't require any code--just XML markup.

The images are pulled from the Office library of images. There will be help documentation in the next beta that provides a list of all the available icons. You can load your own images from attachments with a few lines of code. We will have sample code available when folks have a build where it will work.

Mauro,
The sample database is provided in a link above... http://clintc.officeisp.net/Blogs/2006/36%20-%20Ribbon%20Extensibility/RibbonXBlogDatabase.accdb



# July 21, 2006 6:32 PM

Zen said:



Clint C:

"You can load your own images from attachments with a few lines of code"


The icons must reside externally, they cannot "embedded" in the FE?
I hope you understand that would be a very large limitation...

We recommend you not underrate the problems of Runtime distribution: the "lost references" and other problems of the package wizard are much serious.
We don't want to acquire the sagekeys scripts for all the life   : -)

Access without a rock solid runtime distribution, is a product that has no matter.

Bye
# July 22, 2006 5:29 AM

DataMouse said:

Hi chaps/chappettes

I see that the icons are from the Office library and that you cannot embed them.

Do they work differently from the OLE wrapper objects that previous version use?

I'm just wondering if I must ship custom icons with the application in an install package (to store them externally on the client's computer) or if they could be treated as OLE objects (or better still, BLOBs)?

DM

# July 23, 2006 5:26 AM

Ken said:

>>Have you discovered the search bar?

Have not really used it yet.  Will take a look at it tonight at home.  Thanks for the suggestion clint!

Ken
# July 24, 2006 8:52 AM

StepUP said:

You know, I always thought that the ability to customize and move toolbars and menus in previous versions of Office was one of the coolest features around. And once you got the hang of it, it was quite easy! It afforded both developers and end users great flexibility.

Now it is basically being taken away for a new paradigm. I think the Ribbon concept works well in some of the other apps like Word and Excel, but for me the same does not hold true within Access.

So why in the world would you kill it completely? Why not have it be optional, even be the default, but still have that great customization of the old mode as an option?

I also think its a big mistake to not have the ability to easily customize the ribbons. I just can't believe that it would be that great of an effort to offer some kind of basic tool to do this.

NO:
-ULS
-Toolbars or menus
-No replication
-No optional (i.e. old style) view with the Nav pane
-No further support of ADP's (they appear to be basically dead)

I understand that a huge effort has been made to add some significant features to Access. I appreciate the hard work that has gone into it. But as a long time developer of Microsoft Access applications, I am truly disappointed..and baffled.

# July 24, 2006 9:21 AM

rmcgaffic said:

StepUp,

You're not the only one disappointed.  Despite the really neat results achievable with gridlines and layouts, this menu issue is going to dissuade a lot of developers from considering this product further.  

Why isn't Microsoft forcing this new paradign on Visual Studio?  Why are they shoving it down the throats of Access developers, and not Visual Basic developers. If they did, you would surely hear howls from developers using that tool.

You heard it here first: Access 2007 is the "new Coke", a fiasco that resulted in Classic Coke.

For pity's sake, Microsoft give us a way to incorporate customer menu and toolbars a l a
Access 2003.  

Just my 2 cents.

Bob
# July 24, 2006 10:52 AM

Stuart said:

Conclusions:

0) Icons included in the Office library are not never useful

1) Our custom icons must reside externally...        ????
2) We must write code to specify the wishes icon in the ribbon.
3) There isn't a Visual Editor in Access 12 for Ribbons manipulation


There are no words: it was much better Access 97!

You must consult who REALLY develops application with Access, before working on the new releases of product.

You have mistaken many things in this version 12: some new features are amazing (new report engine: great!), other are annoying and much dangerous.

Microsoft Ribbons?   RAUS!

# July 24, 2006 4:17 PM

StepUP said:

"You must consult who REALLY develops application with Access, before working on the new releases of product."

I agree with that sentiment. Supposedly, developers WERE part of the early testing groups, but I find it hard to believe that there was a true representation of folks who are really serious developers. I can not imagine any developer, especially those that do it for a living like myself, who would be happy with options being taken away and crippling some of the great capabilities of past versions of Access, in spite of some of the new cool features.

BTW, another thing that I am not happy with is the basic look of the forms. I guess these XP theme styled type of forms are OK with many people but I prefer the classic Windows form style. I like a basic, clean look that uses screen real estate efficiently. AGAIN and AGAIN I have been asking myself, why take away this and other options?? Yes, Access is an end user tool, but it also is a SERIOUS development tool. Developers want options, so they can develop in whatever style they choose. As someone in this thread pointed out, can you imagine the reaction if Visual Studio developers were forced to use Ribbons and could not fully control the look and feel of there apps?

A second BTW: I followed the steps outlined earlier in this thread for removing the ribbons, but it did not work. Anyone else try this?
# July 25, 2006 9:44 AM

Clint Covington said:

Zen/DataMouse/Stuart,
I must not have made myself very clear. If you are using an ACCDB database you can put images in an attachment control and using a hidden form and a few lines of code load them into the database without having to have the files stored externally. It doesn't work in beta 2 but we will have code samples in beta 2 TR. For MDB or ADP users you can store the images in binary fields and save them in a temp directory. I expect we will have code samples of this as well.

StepUP,
There was a slight change in the casing of the ribbonXML that caused my sample to not work. I have uploaded a Db with a working sample of startFromScratch.

WRT - the basic look of the forms. You can still use the old windows 3-d style in your databases. There is a property under Access Options | Current Database called Use Windows-themed Controls on Forms. This should give you the old-style look if that is your preference.
# July 26, 2006 12:54 PM

Clint Covington said:

Sorry folks, I forgot to include the link to a database that has the start from scratch working correctly. I need to go home and start this day over :-).

http://clintc.officeisp.net/Blogs/2006/36 - Ribbon Extensibility/StartFromScratch.accdb
# July 26, 2006 12:56 PM

zen said:

Clint Convington:

"For MDB or ADP users you can store the images in binary fields and save them in a temp directory..."


Question:  have you never used Access in order to develop applications?  

What do you think about R.A.D?

Do you know the Access Runtime version and the "lost references" bugs of package wizard?







# July 26, 2006 3:58 PM

StepUP said:

Clint,

You link is incorrect. But I got to the file by going to http://clintc.officeisp.net/Blogs and then clicking on "36".

Anyway, when I tried to DL the "StartFromScratch.accdb" it asked for a login.

Can you correct this please?

Thanks
# July 26, 2006 4:15 PM

Tim Getsch said:

zen: Do you know the Access Runtime version and the "lost references" bugs of package wizard?

I am not sure exactly what bug you are referring to.  A known limitation of referencing libraries is that you need to compile for the lowest common denominator.  If you do development in Access 2003 and you want people to use the Access 2002 Runtime, you need to go to a machine that only has Access 2002 and make sure that your application works properly.  This may mean deleting missing references to future libraries and adding back references to previous libraries.  Once you have confirmed that it works correctly, you can deploy that copy of the database.  

If you open that database in a newer version of Access, that may cause your referenced to be bumped to the newer libraries that are installed.  That is why you need to make sure you test on the lowest common denominator as the last step before deploying.

References should always be forwards compatible (old references work for new libraries) but they are not always backwards compatible (new references may not work for old libraries).
# July 26, 2006 7:26 PM

Clint Covington said:

Here is a link that should work for the start from scratch database...

http://clintc.officeisp.net/Blogs/2006/36%20-%20Ribbon Extensibility/StartFromScratch.accdb
# July 27, 2006 1:12 PM

zen said:

Tim Getsch:

"I am not sure exactly what bug you are referring to"


Problems of "missing references" always have been frequent with the Microsoft package: as an example with access 2000 Runtime the recording of ADO libraries did not work well.

Beyond to the famous conflicts with other versions of Office preinstalled.

The only solution is to buy the sagekey scripts:  www.sagekey.com

Do you promise to give us a "rock solid" Runtime package for Access 12?
# July 27, 2006 2:57 PM

StepUP said:

http://clintc.officeisp.net/Blogs/2006/36 - Ribbon Extensibility/StartFromScratch.accdb

Nope....Still doesn't work.
# July 28, 2006 9:42 AM

clint said:

I missed a space. Does it not work if you don't paste in the entire URL from http to accdb?

http://clintc.officeisp.net/Blogs/2006/36%20-%20Ribbon%20Extensibility/StartFromScratch.accdb
# July 28, 2006 12:03 PM

StepUP said:

Clint,

Yes, that worked. Thanks.

Only problem is....if I design an app that I don't want ribbons for for the end user, I might still like to have them for the design of the app (well, really I'd rather have tool bars that I can easily customize to my liking), and it makes it that much more difficult to switch back and forth.

My point is, at the risk of being redundant, I think Microsoft is making a big mistake in not offering a tool to customize ribbons. It was always there for toolbars. Aren't Word and Excel users expressing the same concern?
# August 2, 2006 3:16 PM

Clint Covington said:

> My point is, at the risk of being redundant, I think
> Microsoft is making a big mistake in not offering a tool to
> customize ribbons. It was always there for toolbars.
> Aren't Word and Excel users expressing the same concern?

We are hearing similar feedback on this issue but the overall response to the ribbon has been very positive. There is interest in building customization UI but that didn't get done this release. In the Word and Excel case the most common scenario for heavy toolbar customization by developers is companies that build addins. From what I understand, they are doing great things with RibbonX. Access is a bit different because developers build apps that control more of the UI than the other applications more often.

The PM team has been thinking about putting together a database that will generate ribbons. The ribbonX schema isn't that difficult to where a tool would be hard to create. In fact, we had a database that generated ALL of the Access ribbon XML. Our internal format is bit different than the external format so we can't just provide our database. I also expect some third party addin people to do some interesting stuff here.

After beta 2 TR ships I will post a database that has custom ribbons without any code. It took me less than 2 hours to build. Once you have an XML editor and the XSD--it is really easier than you think. My guess is most beginners will simply start from a sample and tweak the labels, icons, and functions. I think most developers could be pretty productive in a couple of hours playing with the XML once they have some good examples and help documentation.

There have been some questions about RAD on this thread. After using Access 2007 for the 1.5 years to build all our templates--I couldn't stand to go back using 2003 because the new product is so much easier to use. It has been our experience from personal use and usability research that developers are far more productive than before. Would we like to have shipped customization UI--you bet! However, I think it is more important to develop a super stable base and nail the user experience around the ribbon.

# August 3, 2006 1:29 AM

Stevbe said:

<I think most developers could be pretty productive in a couple of hours playing with the XML once they have some good examples and help documentation. >

While an original skeptic and still eagerly anticipate better documentation I found this to be true for myself. A couple hours reading and playing, I have been able to start my custom ribbon. I work for a large corporation and we only deploy runtime so I basically have "Data Entry" and "Reporting" that uses MS standard controls (but not all of them) and usually all I need after that it is "Navigation" and finally "Administation". I am trying to get these all on one tab but each will have it's own group. I have not got far enough to see what this will all look like once I standardize the control size (I dislike the LARGE, I write business apps and not edutainment) but am switching my view to cautiously optimistic.
# August 3, 2006 7:03 AM

Mike Groh said:

Okay, I've downloaded both the "StartFromScratch.accdb" and the "RibbonXBlogDatabase.accdb" ribbon examples, and neither follows the steps outlined in Frank Rice's MSDN article (http://msdn2.microsoft.com/en-us/library/ms406046.aspx) -- NEITHER of these examples run LoadCustomUI to load the ribbons. I cannot tell how the ribbons in the RibbonXBlog example are being loaded. I can't even begin to guess at how the ribbons in this example are implemented other than looking at USysRibbons and guessing how it's done.
Also, while it's good to have an MSDN page devoted to ribbons (http://msdn.microsoft.com/office/tool/ribbon/) the "video" on "Extending the Office 2007 UI with a Custom Ribbon" is AUDIO-only! You can't see what the guy is doing, so what's the point? There's no way to follow the discussion at all without seeing the process. Also, why is this guy using Visual Studio to build Office ribbons? Is .NET a requirement for custom Office ribbons?
This is extremely frustrating -- Microsoft ditches CommandBars, a well-established paradigm, documents the new paradigm in the MSDN article, then none of the available examples follow the documentation!
There's a nice discusson on Jensen's Harris's page (http://blogs.msdn.com/jensenh/archive/2006/04/06/569876.aspx) about controlling ribbon images, but no listing of the built-in image names -- how are we supposed to get this information? Where did "HappyFace" come from? It does no good to publish examples that leave tell only part of the story. All the example I've seen so far use information (like the "imageMSO" values) that isn't available to everyone.
In Jensen's April entry, Savraj says "In the sample above, my C# callback, getM, grabs the PNG file, converts it to an IPictureDisp, and returns it to Office." -- Okay, where's the C# code? Where's the example? Why throw something out there like that if you're not going to show us the example? Also, Access, of course, doesn't support C# -- is every Access developer who wants to build custom ribbons going to have to become a .NET developer to do it?
We appreciate the effort the Office team is making to educate people, but half-baked examples, discussions that present only part of the information, and "videos" that teach nothing, aren't going to make it.
I'm struggling to finish the ribbons chapter in my Access 2007 book, and I'm not finding enough complete information to fill a single paragraph. Unless Microsoft really digs in and fully supports the developer community with documentation and examples that really explain how to create and customize ribbons, ribbons will never be accepted by developers. Ribbons are, without a doubt, the biggest single change in the Access UI. IMO, poor documentation of the ribbon customization process is going to dramatically inhibit adoption of Access 2007.
Thanks Erik! I know you guys are working hard on this stuff, but a lot of us are still very confused and aren't getting anywhere yet.
# August 11, 2006 7:14 AM

StepUP said:

Access Items:

1) Auto repeat on forms, reports
2) Color scheme
3) Switch file, QAT has some icons twice
4) Recent files not shown until you close the current file.
5) Nav pane - toggle (completely) on F11, or way to hide it; have options for tabs like old style (too hard to find stuff); have detail in columns like the old way
6) When you change window option it doesn't update until you close and open.

6/1206

Well, once again I strongly agree with Alex.

I installed the new beta last week. I really like some of the features. PDF is great, sorting and filtering in reports is awesome, I can see where tabs could be nice. And I think the Ribbons interface works very nicely in Word and Excel.

Overall, however, from strictly a developer perspective, I must say, I am disappointed.

I apologize if I am misinformed on some of the following points. If there is a workaround on any of these, please enlighten me.

As expressed in some of the other threads, there are too many things I am "forced" to comply with in the new version. If someone wants ribbons, that's fine, but why I am forced to NOT used standard menus and a standard (classic) Windows interface? For an end user that is just using the application (not developing), the interface simply doesn't work! (My understanding is that custom menus ONLY work with Access 2003 versions? Couldn't get them to work in Access 2002 versions. Not good!).

I really don't like the Navigation Pane. The old tabbed version was much easier to navigate and understand. I miss the multiple columns in detail view!

Its been said many times, but I am compelled to say it again. Sharepoint and/or SQL Server is usually NOT an alternative for a custom Access solution. People use Access as a mid point solution between Excel and SQL; the idea is to AVOID the high cost of a server solution when client server functionality is not needed for a particular solution.

And finally...per the post of Alex..is the security issue! SO IMPORTANT! And so ignored in Access. Its nice to have the functionality of using Sharepoint and SQL, but to offer it as the solution to security just doesn't cut it!

I now see there really is NO end user security model (I guess it was stated in earlier posts, I was in denial). Why can't this be an option?? The old security model was really very good, but totally ruined by the crackability of SYSTEM.MDW.

PLEASE...make this an option, with strong encryption of passwords. It would be SO simple to implement, and by making it optional, even if defaulted to off, wouldn't we have best of both worlds for users across the board, as well as developers?

Are we developers beating a dead horse? Seems our ilk raise the same issues here over and over again, and quite honestly they seem to be pretty much ignored. If things aren't going to change, please level with us now and just dish it out directly. I for one am getting much more involved in Dot Net. As amazing and powerful as Dot Net is, there is still no beating Access for its RAD capabilities (and, BTW, performance!). If things don't change in A12, I'll just bid my fond farewell and uninstall the Office 12 Beta.

An equally unhappy StepUP.

--------- 7/12

Erik,

Thanks for responding to my post today on the blog.

I have been so upset with a few issues relating to the new version that I have not really proceeded with any testing of the new features.

I really think the user level security issue will be a sore point for many other developers like myself, as well as users. I simply do not understand why it can't be included as an OPTION, rather than the only option being "use SQL or Sharepoint if security is a concern". Access IMO has always had a good security model, but it has been rendered essentially worthless by the weak encryption of passwords. Also, not allowing menus as an OPTION leaves me clueless, especially when other Office 12 products still use menus!

I have been developing Access app for over 13 years. SQL or Sharepoint would simply not be a possibility for most of my end user customers. The reason they went with Access in the first place for their applications was because it was a low cost alternative with minimal management requirements. You are shutting out this type of user if they require even minimal security in their apps. Many government agencies and larger companies will no longer use Access for this reason. I surely understand that it could not have the level of security of a SQL Server, but it COULD be made quite secure, and quite easily, by Microsoft.

I have a retail product that I sell, written with Access XP. You are more or less killing Access retail products without these options available. I DO NOT want an end user seeing ribbons! I want to have the choice of presenting a standard Windows interface, which everyone that uses a computer pretty much understands. Again, why can't these be optional? Why not include standard features, that already exist, for those that want to use them?

If you feel that you have no influence in passing these concerns on to Microsoft management, would it be possible to direct them elsewhere through other channels? As great as many of the new features in Access are, if the status of some of these core issues is not changed, I will be abandoning the product as a developer. I believe you will see a similar trend with other developers as well, based on the concerns expressed in the blog.

Thanks for listening.

Regards,

John Fitz
StepUP Consulting


---------

You bet, and thanks for being an enthusiastic Access user!

I'd encourage you to play with the application.  I believe you'll find a lot of things to like, and you may find that I've done a bad job of describing the things you're concerned about and they may actually work fine for you.

Access 12 does have strong encryption of passwords and does a great job of encoding databases - this is all significantly improved over Access 2003.  An encrypted Access database is reasonably secure on the user's machine (in fact the user can swap out our encryption for any that they choose and make it arbitrarily secure).

User-level security is another story.  I assure you that we didn't remove the feature lightly, and had a number of really smart people think about the problem for a long time, and still fail to figure out a solution.  The challenge is we can't figure out how to make user level security secure.  I'm sorry that I can't go into the details here, but the general problem is that it is impossible to decrypt only part of the database.  Since we can't make it secure, we're really doing users a disservice by calling it user level security.  I understand that it created a speed bump for users wanting to see other data, but it didn't provide sufficient security.  We couldn't ship it without it being secure, and we couldn't make it secure.  Making it an option is simply the same problem again.

As far as the ribbons, there's no reason your app has to show the ribbon.  If you've replaced Access's toolbars with your own in XP, they'll carry forward unchanged to Access 12.  We actually think the ribbon is a significant improvement (and have a whole lot of user data to support this) but if you'd like to use your existing command bars, they should carry forward just fine.

Thanks again for your long-term usage of the product and for sharing your concerns with Access 12.  They definitely help us make the product better and we really appreciate the time and effort you've shown.

Thanks,
Erik Rucker
Group Program Manager, Access


--------- 7/14

Erik,

Again thanks for the reply.

Please allow me to address some of your points purely from a developer's perspective.

I see many of the new features in Access being directed to the end user, and that is fine. If a non-programmer type of user wants to develop an application, many of these features will be a great help.

But here is what I have found in my 13 years of working with Access. End users are very limited in going beyond just the basics of developing a true relational database app. Even with some of the nice new templates that are in A12, as soon as new functionality is required (and of course, that ALWAYS happens), they pretty much make a mess of things. You can't expect a non-technical person to understand normalized database structure, or write VBA code. The new macro capabilities are nice, but we all know that coding is simply required to do a lot of more advanced stuff. I have made a business in large part of fixing Access apps, built by end users, that were broken or causing major problems.

Ribbons? I think they work great in Word (better than great...awesome!), but for an end user that is not doing development...well, IMO, just confusing and a waste of screen space. Yes, they don't have to be displayed and that is great. But again, why TAKE AWAY the ability to show a custom menu? This is just completely baffling to me. Also, did I miss something? The docmd.showtoolbar is no longer available in macros, although it IS in code. Also, I can do CommandBars("MyCustom").Visible=True. But they only show within an "Add In" tab. Why?? Again, its a big waste of space.

As for some of the other new features:
-Email forms....nice, but I've been doing emails with merge and file attachment capabilities via CDO for years.
-PDF...nice, also been doing that with code for quite some time.
-Advanced filtering...yes, this one I like. But again, I've done some really cool things in filtering with custom shortcut menus, and have had the ability to filter reports from an interface since 2.0 (I DO very much like the in report filtering though).

And many more examples. People have complained that Access hasn't really progressed since A97. I say..that is great! Its a great testament to just how powerful an app Access really is, once you know how to tap into its power (much of that is via VBA, with the abilities to declare Windows APIs).

Now as for security...the points you make about it, and what I am looking for, I think are 2 different things. You said "the general problem is that it is impossible to decrypt only part of the database". Why I would like to see has nothing to do with that. I am talking about just 1 thing : strong encryption in System.mdw. THAT is what is severely broken in the security model, and to fix that, it seems to me, would be a no-brainer. A critical part of many of my apps is the ability to control, by user or group, who-can-see-what (i.e. accounting can see XYZ report, but can't edit its data). WHY TAKE THIS AWAY? Its SUCH a fundamental part of any decent data application.

I plan on getting back into Beta 2 now. Forgive me if some of my concerns are due to lack of understanding or knowledge of the new version. Please reconsider some of the se fundamental issues that are critical to the developer community. After all, without the developer, Access would certainly not me where it is today..the most popular desktop DB in the world.

Thanks,

John Fitz
StepUP Consulting

7/17

Thanks for the explanation on security, but again I'd have to say we are talking 2 different worlds here. In most apps that I deploy, I don't give a hoot about database encryption.

Basically, with no ability to restrict access to data, forms or reports, using an Access 12 format for a custom app becomes a total deal breaker for me. Every system that I have ever used or seen, no matter the environment, employs some kind of user identification to enforce security. So if a client refuses to go the SQL or Sharepoint route I have to say to them that Access 2007 is out of the question.

The following comments on Garry Robinson's blog from developers reiterate some of my concerns:

----------------------------------------------------------------
-I love Access but currently feel a little gloomy about the future. Access is being dumbed-down. Microsoft said Access 12 would be much easier for novice users - then don't make it part of Vanilla Office. Most users will therefore use Excel rather than trying Access anyway. MDB seem to be an endangered species. ACE will not support user-level security or replication. These were powerful features. Why didn't Microsoft beef up User Level security and replication rather than ditch it (unless it's to force us to use SQL Server as a back end). Access is brilliant for the SME environments I develop application for. I find .NET unfriendly and backward, much less 4GL than VBA, and I don't want to use SQL Server as a backend for most applications. For one thing, some clients will not allow SQL Server on their networks. For another, the extra development time will push my costs up. The much-hyped extra functionality with SharePoint is surplus for most of my clients too.

-I find it difficult to comment on this loss of workgroup security apart from saying that I am very concerned. There is very little information on what is happening. We know we are losing it, but all we have heard is that there is a beefed up database password. There is new navigation stuff being built in, but does this mean no-one can get at, say, the Connect property of a linked table? Assuming, perhaps wrongly, that this version of the database password mechanism won't be cracked (unlike previous versions), it gives just the one level of access to the database. In previous versions, developers used user-level security because the one level afforded by a database password was insufficient.
Two questions for Microsoft (asked elsewhere but no reply received):
1) Why are you removing an important feature that has been in the product since the start? I thought MS were hot on security now.
2) If I have misunderstood what is happening, why, oh why won't anyone at MS tell us how to bring at least a modicum of security to the way we work at least 90% of the time, i.e. with an MDB/ACEDB back end (I'm assuming SQL Server and Sharepoint back ends manage to reach something like 10% of the total)?

The other stuff in this next version of Access looks really good to me, but this security thing has got me really worried. If it is not done properly, the new Access becomes just a whizzy toy (unless your customer can pay the extra for a SQL Server or Sharepoint back end. Many will not.)

-With the loss of User security and replication, I see little reason to upgrade myself or clients.

My clients do not want the added cost of SQL Server, (most are clients with 5 to 50 users and a shared data MDB on the server works just fine), and I make extensive use of user/group managed security to manage the applications.

As an Access programmer since v1.1,I am tired of MS constantly forcing radical change requiring TOTAL rewriting of applications, simply to produce incompatibility with previous versions and forcing users to upgrade. MS has been kicking the Access community like an old can.

-I have been considering upgrading an Access 97 project for some time, but it relies heavily on user level security to allow groups of users varying read and write access. With the possibility of needing to completely re write these areas the attraction of Access diminishes!

-The missing user-level security in the new Access 2007 turns out to be a big issue for me as well. I have no way of joining a workgroup file I created, and thus when trying to open one of our databases, I just get an error message saying I don't have enough permissions.

It seems to me that Microsoft doesn't want people to get away with developing serious database systems with Access. They'd rather have you purchase a SQL Server license, I suppose... I'm rolling back to 2003.

-I've been having a play with Beta 2 and it appears to me that security is just about dead in Access 2007. Even with the Navigation Pane set to restrict access to database objects, you can still get to all of them by opening another database and using GetObject to hook into your so-called secure database. For example, any linked table is easy to get at and alter the data. I have done it with a front end linked to an Access back end, but would think the same thing would be true for a front end linked to SQL Server (and Sharepoint?). So that means Access with linked tables has no security. Oh joy.
The only thing that comes to my mind to get round this is to use stored procedures for all data access (if you have SQL Server as your back end and more time on your hands than most people), make all your forms unbound (again, time consuming) or bind your forms to a DAO or ADO recordset built from inline SQL opening up a password-protected Access back end or server database. Don't bother storing queries in the front end as they are wide open too.

-Being yet another developer since v1.1 I have applications that rely on workgroup security.

Why can't MS provide a simple method of locking users from the "guts" of the system? Stop users accessing tables directly for a start in an MDE, then we can control user access via code simply enough.

My users can not afford to implement MSSQL nor do I have the time to redevelop apps. (I'd love to, but it's not going to happen).

MS needs to support the many developers who develop for small/medium sized business for whom Access provided a very cost effective solution.

Sharepoint? Who cares?

----------------------------------------------------------------

Erik, as to your comment that ".. given our stature as a company, it is legally nuts for us to ship something like ULS that isn't actually secure", I don't really get that one, since this has been a known problem in Access for many years, yet I have never heard of any prior legal ramifications of it to date.

As for menus, you stated "The only alternative would be to resurrect all the old, but of course that UI is (a) gone, and (b) missing all the new or modified functionality which makes up most of the app.  So this would be a huge effort and the result would be a worse user experience (again, since all of our data shows that the ribbon really is a significant improvement)." If that is true, why is the "Old UI" still in the 2007 versions of Outlook, InfoPath and Publisher? I disagree with your assessment, I think another alternative would be to have the new UI as the DEFAULT, but give the user (and developer) the OPTION of using the standard Windows interface. Why is it a huge effort to keep something that is already there? Can you imagine the backlash if Microsoft decreed that .Net developers could not add menus to their UI, only ribbons?

Isn't the art and profession of programming and custom application development all about options? It always has been for me, in fact its really why I have been in business for the past 13 years. Whereas most canned software can only fulfill 80% of a user's needs, with Access I almost always can say to a customer "Yes, we can do that". With some crucial options in the the new version being taken out, this will no longer be the case, and that is sad.

I know you guys are working really hard on the new version and have done a great job in many respects. But with some of these fundamental issues, I really feel you are going to short circuit the evolution of Access being a premier development tool going forward.

Thanks,

John Fitz
StepUP Consulting

7/18 UA Forum

I'm curious as to how many people, particularly developers, are aware of the new "security" model in Access 12? User level security (ULS) has been removed from the new version of Access. Replication has also been taken out.

Many people know that security in Access has been broken for a long time, mostly because passwords in the database and workgroup file can be easily cracked. But I have always thought that the security model in Access was a really good one for a local, file based database. Seems to me it could be fixed, or at least considerably shored up, easily by Microsoft with stronger encryption. Why this was never done has always baffled me.

So what is Microsoft's "fix" for this situation? Just TAKE ULS OUT, and replace it with the "Trust Center" model. Now, you can no longer restrict access to objects in the database by user or group. Its pretty much an all or nothing scenario with this new model. The standard response to this concern in the Access 12 blog has been that, if security is a key concern, then SQL Server or Sharepoint should be used on the back end.

I simply do not understand the thinking here. What secure system does NOT employ some kind of user identification?

Seems to me that the intent with the new version is to simplify Access for the end user, but in doing so they have removed a great deal of capability to do customization in an application. How many people are aware that you can not have menus in Access 12? You can still have toolbars, but they are placed with a ribbon tab. Maybe some people will love "Ribbons" (I really DO like them in Word and Excel), but to force them on an end user is kind of..well...crazy. Why not leave in the OPTION to have a standard Window interface? Why not have the OPTION to use the existing Access security model and just fix the "crackability" of the security model?

I would like to carry this further, perhaps make an appeal to Microsoft in some way. I have been in contact with Erik Rucker, Program Manager of the Access development team. The team has worked really hard on the new release, and many of the new features are really very nice. Erik has been very gracious in explaining the thinking behind the decisions on interface design and security. But to me, as a long time Access developer, I think some of their decisions will have a real adverse effect, particularly on developers.

You thoughts please.

7/25

"You must consult who REALLY develops application with Access, before working on the new releases of product."

I agree with that sentiment. Supposedly, developers WERE part of the early testing groups, but I find it hard to believe that there was a true representation of folks who are really serious developers. I can not imagine any developer, especially those that do it for a living like myself, who would be happy with options being taken away and crippling some of the great capabilities of past versions of Access, in spite of some of the new cool features.

BTW, another thing that I am not happy with is the basic look of the forms. I guess these XP theme styled type of forms are OK with many people but I prefer the classic Windows form style. I like a basic, clean look that uses screen real estate efficiently. AGAIN and AGAIN I have been asking myself, why take away this and other options?? Yes, Access is an end user tool, but it also is a SERIOUS development tool. Developers want options, so they can develop in whatever style they choose. As someone in this thread pointed out, can you imagine the reaction if Visual Studio developers were forced to use Ribbons and could not fully control the look and feel of there apps?

A second BTW: I followed the steps outlined earlier in this thread for removing the ribbons, but it did not work. Anyone else try this?

7/31 AA

I wonder how many developers are following the Access 12 blog (http://blogs.msdn.com/access/default.aspx). Certainly some of the items in the wish list have been addressed. I like the new filtering capabilities, especially in reports. A layout view for forms and reports is nice. A Totals row in datasheets is pretty neat.

However, overall I am very disappointed in what I have seen so far in Access 2007. It looks like the thrust of the new features is to "dumb down" Access, I guess in an attempt to attract more end users who might otherwise try to build an Excel worksheet to hold their data.

In doing this, however, they have taken away a good deal of flexibility in this new version. In the new format (.accdb) there will be:

-The new Office 2007 "Ribbon" UI which takes up a whole lot of extra screen real estate, and which has NO visual tool for modifying it (It can be modified through a complicated process of creating an XML file, using VBA code and creating a "USysRibbons" table in the app).

-No User Level Security. The standard answer in the blog for questions about ULS is that if you require security in your application, use SQL or Sharepoint on the backend. You will no longer be able to restrict rights based on user or group for tables, queries, forms and reports.

Many people know that security in Access has been broken for a long time, mostly because passwords in the database and workgroup file can be easily cracked. But I have always thought that the security model in Access was a really good one for a local, file based database. Seems to me it could be fixed, or at least considerably shored up, easily by Microsoft with stronger encryption. Why this was never done has always baffled me.

So what is Microsoft's "fix" for this situation? Just TAKE ULS OUT, and replace it with the "Trust Center" model.

-No replication

-No menus

-No support for independent toolbars (toolbars can be displayed with a "Ribbon" tab)

-A "Navigation" pane which replaces the database window, but which can not display object names, descriptions and dates in separate columns, and can only be docked or hidden.

-A UI that currently only has 2 color choices (I believe they are going to add additional ones) and which shows windows only in an XP, theme type style.

08/11/06

I'm glad to see someone from the Access development community speaking out here. I'll say it again...I can not believe that there is not a tool to customize the ribbons. Mike stated that "Unless Microsoft really digs in and fully supports the developer community with documentation and examples that really explain how to create and customize ribbons, ribbons will never be accepted by developers". I would add that they will not be well accepted by end users either. Most "power" users and many everyday users of previous Office versions customize their toolbars to suit their particular needs. When you create an entire new UI and don't have the ability to customize it, aren't you defeating the purpose of a better UI in the first place? And for a true developer tool (i.e. Access) to not have the OPTION to use either ribbons or standard menus and toolbars is outrageous, IMO.

Clint, you mentioned that "After using Access 2007 for the 1.5 years to build all our templates--I couldn't stand to go back using 2003 because the new product is so much easier to use". Could you please be more specific and how HOW you find it so much easier to use? I am honestly making an effort to work with the new version, and just don't see it. For me, the ribbons are just in the way during the development process. They take up far too much space and don't react as I would like them to. I was never a fan of templates, so years ago I built my own templates and code to go along with them, so the new templates are pretty much useless to me. I guess the auto-format is OK, but again using my templates, I already have forms and reports formatted the way I want them to be. The Nav pane is, well, a Pain. I have seen the same complaints about it again and again. At the risk of being redundant...why not have the OPTION to display the database window as in the older versions? The coding IDE is pretty much unchanged (thank goodness!) so there is no gain there. I DO like the layout view, especially in reports. But other than that, again from a developers standpoint, I find it actually more difficult to work in the new version.

I am very surprised that there are not more comments from the developer community about Access 2007. I can only guess that developers have already in large part abandoned Access, and if that is true in perhaps it is because the have given up on known issues like security, or have seen the new version and do not want to be so severely restricted in their development options.

Mike, I have been an Advisor subscriber for years and have always enjoyed your articles. What kind of feedback are you guys getting about A12?
# August 11, 2006 10:27 AM

StepUP said:

Ooopppsss....sorry I inadvertently copied my entire text file of Access posts and notes to the last thread. Well, maybe it will make for some good reading by anyone who is interested.

For anyone who is NOT interested, please skip down to the section after todays (8/11/06) date.

:)
# August 11, 2006 10:30 AM

Mike Groh said:

Well, so far people are pleased that Microsoft is paying so much attention to Access. Really -- people love the stuff they're finding, like the new capabilities to search and sort datasheet view, the ability to create custom Navigation Pane groups, the report "layout view" -- those are exactly what a lot of people have been wanting.
The main issues are the removal of user-level security, replacing toolbars & menus with the ribbon, and (to a lesser extent) the loss of replication. Many people are finding that Access 2007 really doesn't care what version of data file you open (MDB, MDE, ACCDB, etc), so people who really need ULS can just continue using their existing MDBs and have it all.
Even then, however, they have to deal with ribbons. Because there's no support for 'traditional' toolbars & menus in '07, they'll have to do something like use forms to build a good menuing system for the MDBs they run under '07.
My concern, and I'm sure we share it equally, is that a segment of Access developers will decide that '07 isn't worth the upgrade if they end up running their old MDBs under '07, and lose their toolbars and menus in the process. The question is how large that segment is.
I just wish there was a -painless- upgrade for menus and toolbars (BTW: Today I'm picking on the ribbon because that's the chapter I'm writing this week!) -- you know, a tool that'd analyze the command bars in an Access MDB, build the equivalent XML, etc. -- essentially do it all.
I'll tell you the #1 off-putting thing for Access developers: A Microsoft guy (or gal!) opening Visual Studio.NET to compose the XML for an Access ribbon. I heard numerous guffaws and complaints at the April Advisor conference about that one. The fact that there's no acceptable XML editor built into Access is a biggie for a lot of people. I've begun using the "Visual Web Developer 2005 Express" for composing the XML -- now, THAT'S a smart XML editor! But, please, stop using Visual Studio.NET for building XML in demos -- it makes it look as though .NET is a requirement for customizing ribbons!
Also, I finally figured out that "USysRibbons" is a magical table name -- the MSDN article that discusses "LoadCustomUI" is, apparently, out of date. Just adding USysRibbons table is enough to get Beta 2 to pick up custom ribbons. Apparently, you do not have to use LoadCustomUI as documented in Frank Rice's MSDN article (http://msdn2.microsoft.com/en-us/library/ms406046.aspx).
# August 11, 2006 12:54 PM

A User said:

"Building ribbons isn't beyond the reach of any successful Access user today, but it will take some more work."

Beyond overstatement, this is complete misstatement. Customizing menus and toolbars was completely accessible to the end user. This is an affordance for developers who use Access, not for Access users.

I am sure developers will love it. Many IT folks will love it. If for no other reason than that it makes the user more dependant on their expertise.

No amount of puffery can disguise the fact that user customization has been completely deprecated in Office 2007, except of course for the all-important choice of color scheme.
# August 11, 2006 5:27 PM

StepUP said:

Thanks for the update Mike.

I find it interesting that you stated that "the ability to create custom Navigation Pane groups" was something that developers wanted (I assume you are referring to developers?). I really don't get that one. The only thing I ever wanted for the database window (now Nav pane) is a permission to disallow end users from viewing it. Of course, since there are no longer "permissions", its kind of a moot point. I really am not a fan of the Nav pane. I wish it wasn't docked, and also wish it had the capability to display columns like the old database window.

I'd love to see a poll in Advisor as to what people like and dislike in the Access 2007 beta.
# August 11, 2006 8:46 PM

Mike Groh said:

Some time ago I ran an article titled "Access Wish List" (or something like that) and invited people to add their own wishes to a blog on the Advisor site (http://my.advisor.com/doc/13958). Over the last year and a half this article has picked up about 150 responses (Advisor only posts the last 30 or so). One of the more frequently-requested "wishes" was the ability to add a custom group to the Database Window, and add all different types of objects (tables, queries, forms) to it.
You could, for instance, put all the "Data Entry" objects into one group, and all the "Reporting" objects into another. And, even though you add an object (like a table) to a group, it still appears along with all the other tables when you view by object type.
Access 2007 supports grouping -- you can add custom groups and add any type of object you want to it. Right-click on the Nav Pane's header and select "Navigation Options". The left side is "Categories" (which I haven't quite figured out!) and the right side is groups. Use the Add Group button to add a group, then when you return to the Nav Pane, use the Navigate to Category>Custom to show the group you created. You can then drag and drop from the "Show All" list to your group.
It's not the most intuitive interface -- I would have preferred a simple right-click on the Nav Pane, then select "Add Group" or something, but the current design works.
Most Access apps are so small developers don't need groupiing, but not too long ago I heard about a massive Access app used by the St Louis Airport that has over 2,000 database objects in it (I haven't any idea why he hasn't broken this out into smaller front-ends!). You can see the value of logically grouping objects in this size of application.
It's cool that it lets you put dissimilar objects into each group -- that keeps all the "functionally" related items together. You know how hard it is, sometimes, to know which queries go with which forms and reports -- this is, at least, one way to group these objects. (Personally, I believe logical grouping is better done with a strong prefix naming convention but I like how the Nav Pane groups things.
Viewing an object's details in the Nav Pane is a real PITA -- I still have discovered how you can easily tell which form is newer than some other form. I really wish the Nav Pane supported columns so we could see modification and creation dates easily. Or, perhaps a tool to quickly generate a datasheet view of objects and their primary properties for maintenance purposes?
# August 12, 2006 12:41 PM

Isaac said:

I've some Access applications with a "main" Menu Bar AND a ToolBar with the more common options.

How I make to obtain the same one, with Access  2007?
# August 12, 2006 2:00 PM

Clint Covington said:

Mike,
>> I would have preferred a simple right-click on the Nav
>> Pane, then select "Add Group" or something

In custom groups you can multiselect objects and right click and choose Add to group | Group names. There is also a way to create new groups.  

>> I still have discovered how you can easily tell which
>> form is newer than some other form. I really wish the
>> Nav Pane supported columns so we could see
>> modification and creation dates easily.

There is a grouping option for Created Date and Last Modified date. These options should make it easier to see what objects were recently changed. Also, if you right click on the header there is a View | Details option. We don't list them in a table but with the grouping headers the objects should start falling out into nicely grouped buckets.

I also find the search bar makes it really easy to find specific objects (especially, if you are using a naming convention).
# August 14, 2006 12:29 PM

StepUP said:

Mike, I just read your Advisor article on Access 2007. Nice job on summarizing the new features, and I was glad to see your comments about the Ribbon interface and removal of ULS and replication.

I posted a comment to your article and hope other Advisor readers will do the same.

I would love to see a rallying of developers who are as concerned as I am about what is being done to Access 2007.

I say..lets start a movement to save Access!!!
# August 14, 2006 4:29 PM

Mike Groh said:

Thanks for the tip, Clint! I hadn't noticed the 'grouping' shortcut. Office 12 makes good use of right-clicks. I haven't worked enough with the Search Bar to discover all its options, but I like it a lot, especially for large projects.
I'd still like a "list view" of db object details, though. I'm sure FMS or someone will create an add-in to provide that sort of lookup.
StepUP: Thanks for the compliment on the article! Initially I started out to show how many of the reader "wish" responses had made it into Access 2007, but quickly ran out of space. It goes without saying that a lot of suggestions didn't make it into Access 2007, but a ton of other new things made it. So, I reduced the piece to "10 features" -- not even, necessarily, a "top 10" list.
My hunch is that we'll see a ribbon customization tool for Access before too long -- Clint & Erik's comments make it clear they understand the need for a way to graphically customize ribbons. Clearly, using the "Add In" ribbon to support legacy toolbars & menus is a compromise. I'm sure we'd all rather have an intelligent conversion tool that'd reproduce toolbars and menus as 'real' ribbons.
I'm with you on ULS, though. Microsoft is focusing exclusively on data security by suggesting we look to SQL Server and Sharepoint as security vehicles. The suggestion that we use a database password to secure Access application fails to address the need to secure different portions of an app from different segements of users. The only real solution is to stick with the 2000/2003 format MDB, which sort of defeats the reason to migrate to Access 2007. I don't know what it is about the ACCDB format that makes ULS and replication so difficult. After all, security and data exchange are two fundamental operations (and requirements) in database systems.
# August 15, 2006 7:26 AM

StepUP said:

Mike, I agree with your assessment on ULS 100%. Having permissions on individual objects has always one of the key features I use in my apps, in spite of the security flaws. I would have no problem writing my own security structure within an application, but that is rendered pretty much useless with the all or nothing "Trust Center" model as I understand it. If anyone can think of a way to make individual objects secure with the new design, I'd love to hear it.

As it stands now, I see no reason to upgrade to Access 2007 from a developer perspective. Clint stated that he finds it far easier to develop apps in 2007, but I have been at a loss to find this to be the case, with the exception of layout view in reports. Taking away ULS, menus and toolbars, and replication is far too big of a price to pay for some of other feautures that have been added.

# August 16, 2006 11:53 AM

Alan Cossey said:

I know the title of this thread is "Customizing the New Access UI", but there has been quite a bit of discussion about the non-repairing of User Level Security (ULS) with the new Access 2007 file format, which is, for me, a huge issue. You may be interested in a thread over at UtterAccess.com where Brent Spaulding and I (Alan Cossey) have been trying to set up a method to get back to this. At present our method is just stopping users from access data in tables and queries directly (we hope!) and we have not got down to specifying who can use what forms and reports. That latter part could be done in a variety of ways, e.g. checking the user's Windows ID with code, and so we are not looking at that bit. For us the most important bit is that we think we are getting some control back by stopping the user from getting at tables and queries directly. The basic idea is to open a connection (via a class so that the connection is not public) to the tables or queries in a separate database using code with that database's password embedded in the code, then open our form or report, then close the connection. It seems that if this is done, the user can use this particular form or report OK, but they can't open other forms or reports from the Navigation Pane. Since this involves security, we may well have missed something and there may be a huge hole in our thinking, which we hope someone will find before we put too much faith in this method. Hopefully, however, we are heading down the right track and would be interested in people's thoughts.
Note we have assumed that the user will be able to always get to the Navigation Pane and see what forms and reports are in the front end.

The thread is at http://www.utteraccess.com/forums/showflat.php?Cat=&Board=81&Number=1242310&page=0&view=collapsed&sb=5&o=&fpart=1
# September 5, 2006 6:08 AM

Ken Hayden said:

I'm a part time and amateur developer responsible for an Access based system for thirty guys who work from my HO and from remote offices. I find Access 2007 (Beta 2) an exciting opportunity to roll out solutions I have needed for some time (easy access to sharepoint being the main one).

I love the new ribbon but I need to have custom icons displayed depending on the data. I have tried everything to get them and the closest I can get is a non-tranparent image! I've done it using .Net and directly in Word or Excel. Anyone got a simple solution (without using .Net) or is this coming in Beta 2 TR or the release version?
# September 28, 2006 8:45 AM

Third Of Five - just another voice in the Collective said:

Even though most of the information on how to customize the Ribbon in Access 2007 is already out , there

# October 13, 2006 7:32 PM

Clint's Access blog said:

I recently came across a blog post about common design elements for web 2.0 sites. http://f6design.com/journal/2006/10/21/the-visual-design-of-web-20/

# November 24, 2006 10:58 AM

Clint's Access blog said:

A couple of months ago I spent a few days learning how to write XML for ribbons. I got pretty excited

# December 8, 2006 8:03 PM

marcnz said:

Can anyone tell me where to find the names for each option/menu that can be disabled or enabled in a customized application? I try to get rid of the top form tab where user can right-click, even if the right-click is disabled on the form. Very annoying.

Thanks.

# January 23, 2007 6:00 PM

Ribbon in Access Project file said:

I create a table in an Access Project with 2 fields, VarChar & Text (because in sql server there is no text & memo)... My project does't show the customized ribbons...

What can I do?

# February 1, 2007 8:48 AM

Access Team Blog said:

Despite my passion for all things related to code, I've always had a soft spot for UI that is exciting

# August 22, 2007 8:52 PM

Noticias externas said:

Despite my passion for all things related to code, I&#39;ve always had a soft spot for UI that is exciting

# August 22, 2007 9:26 PM
New Comments to this post are disabled
Page view tracker