You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
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).
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:
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:
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.
There are 5 steps to customizing the ribbons:
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:
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.
This enables VWD to provide type-ahead IntelliSense for the correct ribbon xml.
You can see the XML file for the sample application we're building by clicking here. The contents of the file are:
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:
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
' 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
' Then, to refresh the entire ribbon, call:
You can look at the macros in this example database to get a better idea of the code to write.
Simply create a table in your database called USysRibbons. This table should have 2 columns:
The table should looks something like this:
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.
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.
Here are a few general things to remember:
For additional resources take a look at these sites:
The next post will be the first of several drilling down into using Access in conjunction with Windows SharePoint Services.
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.
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,
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 (blogs.msdn.com/.../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?
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. :)
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 (msdn2.microsoft.com/.../ms406046.aspx).
"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.
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.
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 (my.advisor.com/.../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?
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?
>> 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).
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!!!
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.
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.
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 www.utteraccess.com/.../showflat.php
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?
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.