Do you like the new navigation pane?

Article
06/07/2007

The team is considering some refinements to the navigation pane. What do you like about the changes? How would you like to see it improved? If we added an OM would you use it? Do you use the new tables and views mode?

I have a feeling there will be a number of comments on this post... :-)

Comments

Anonymous
June 07, 2007
The comment has been removed
Anonymous
June 07, 2007
NOOOOO why can't it be simpler...for some reason the default is not to show queries and stuff...anoying
Anonymous
June 07, 2007
I really like the filter tool. I dislike the default selections as well, especially that the filter tool is turned off. I haven't converted any big databases (object count wise) to 2007 so I haven't had any issues. I don't see why it can be set up so that when it is dragged to a wider size it can't show multiple columns. This to me would fix almost any issues I foresee. Ken
Anonymous
June 07, 2007
NO. The old naviation wiindow was far easier to use. I see no benefit to this as opposed to the Access 2003 and prior version
Anonymous
June 07, 2007
RGKaye, Thanks for the feedback but what specifically do you miss from the old design?
Anonymous
June 07, 2007
The comment has been removed
Anonymous
June 07, 2007
Having the ability to float the navigation pane or see it as a tab (like the Access option to see screens in tab format) would be nice. Love the ribbon and likewise would love to see the navigation pane as a ribbon.
Anonymous
June 07, 2007
The comment has been removed
Anonymous
June 07, 2007
I'm hesitating to comment, since I've only had a copy of Access 2007 for a few weeks, and as an amateur "enthusiast", my Access "playtime" has been limited to a few hours, so I might be completely wrong, but.... I have found the navigation pane to be initially confusing. I have looked around enough to discover it is a whole little "world" in itself, and provides lots of opportunities for customization - but all I really want to do with it is to find and open a table/form/query. I'm not sure I'd ever bother customizing the navigation pane. Maybe professionals, who have many more objects than me, would like this, I don't know. BUT my big beef at the moment is the following: say I want to work on the design of a form - I open the file, select the form in the navigation pane, and then I want to click on the button to go to "Design View". But I can't - it's not available. I have to double-click the form, wait for it to open, then click on the "Select View" menu, then click on the "Design View" selection. And maybe I didn't want to open the form, 'cause I knew there was a problem and wanted to go directly to design view, or open the IDE... I'm sure it was easier in Access 2003, let me check... Oh, dang it... it's reinstalling... 'Oh yeah! I've got both versions on this computer. Rats, this will take forever! Listen, I'll run upstairs and open Access 2003 on another computer - it'll be easier than trying to switch between them on this computer - and I need the exercise... ;) (Ok... two beefs! <g>) Cheers! Fred
Anonymous
June 07, 2007
The comment has been removed
Anonymous
June 07, 2007
Maybe I should have hesitated. ;) I actually followed the link provided and read the document about the nav pane, and was reminded that the shortcut menu did provide a quick way to get to design view without first opening the file. Doh! However, you can't get to the IDE that way in one step, and you could using the menu in earlier versions. I do miss that - maybe add that to the shortcut menu? Cheers! Fred
Anonymous
June 07, 2007
The comment has been removed
Anonymous
June 07, 2007
Hi Clint, I think it should be an option to use old database window. Perhaps new nav pane is better then old database window, but you have to give people a chance to use what they used many years. Plus more options, like Henry wrote. Alex
Anonymous
June 07, 2007
The comment has been removed
Anonymous
June 07, 2007
Hi clint, I'm pretty new to access so I don't know if this will help you but having used A2007 now on serveral medium to large sized databases (just started working in a firm where they used nothing but access) I can say that the ribbon is an improvment at least that's how I see it. Now about the nav pane. Like said before I don't like the fact that I have to scroll so much. Most databases I've had to use contain a large amount of tables, forms, reports, macro's, modules (we can speak of several hunderds) and being new to these databases I don't know how the are called so I can't search for them (otherwise the search option has ben very helpfull). So having a tabbed window of some sorts would be helpfull. I wouldn't like to return to the A2003 database window. A few years ago I had to learn about A2003 and I remember being very anoyed that I had to close almost al my open windows before reaching the database window (I know ctrl-tab works too but not like a window that's always there). So the fact that the nav pane is always in my sight is definatly a improvment but maybe an option to easier switch between objects would be better. I appoligize if there are mistakes in my language but written english is not my strongest point (my language is Dutch) Tom
Anonymous
June 07, 2007

When doing design work it is a bit of a pain having to exit the database and then open it again if I want to hide it.
More importantly for me, having it show as one long list means it takes a while in a complicated database to find the object I want. If I have several similarly named objects, I want to be able to see them all and choose the correct one visually, not have to use a search facility.
I like the suggestions that a collapsed NP will appear if the mouse is moved over it without having to first click it and then disappear again if the mouse is moved away from it.
I also like the suggestion that the NP appear over the top of whatever other database object is already open. With 3) that would mean it would work like a ribbon down the side of the screen. That leads onto the question of whether it would be possible for the current ribbon could be made to be dockable, say, down the side of the screen. With wide screens all the rage these days, they are getting further away from the shape of hard copy of whatever we are handling which is usually a piece of paper in portrait (rather than landscape).
The current NP suffers from the fact that you can not securely hide it away, bearing in mind that user-level security was broken and then removed rather than repaired/replaced. Alan Cossey PS I think the ribbon is great though a built-in graphical designer including creation of callback procedure stubs would be a huge improvement. PPS M. David Matney you don't have to use macros with the ribbon (hope I have understood you correctly here) and there should be no need for security warnings, e.g. if you use a Trusted Location.

Anonymous
June 07, 2007
First, a comment to Tom Deketelaere: You could always bring up the Database Window by hitting F11 in earlier versions, as long as you had not disabled Special Keys, under Tools > Startup. The comment that David Matney shared was very familiar to me as a child. I loved to tinker with stuff, which usually meant I had no problem taking it apart, but putting it back together was another matter. An example was my parent's alarm clock; my mom found all the parts in a bowl, hidden under the dresser when I couldn't figure out how to put it back together again! My father quite often said "Son, if it isn't broken, don't fix it". Your team made an attempt to fix the Database Window, when it wasn't broken at all. Now, we have the Navigation Pain (sic) as a result. The comment written by tom (June 07, 2007 9:38 PM by tom) was not written by me, but I'm sure many of my friends may think so, based on private comments I shared in the past! Alex is right on when he wrote "you have to give people a chance to use what they used many years." Change for the sake of change is not improvement at all. I absolutely hate the new Nav. Pain and the ribbon. These two "improvements" have taken a lot of the fun out of working with Access for me, and I'm quite serious when I say that. My hope is that the market, as a whole, will reject these features and force Microsoft to return the Database Window and Toolbars/menus. I know, resistance is futile. I would be a lot more tolerant of these new features if they had not been shoved down our throats; in other words, the ability to use the more familiar Database Window in leiu of the new Navigation Pane, and the ability to use the more familiar toolbars and menus in leiu of the ribbon.
Anonymous
June 08, 2007
The ribbon is way cool. Some of my long time clients who use word and excel nearly all day for 10+ years have upgraded to office 07, and they LOVE the ribbon. (a real surprise to me). Seems us developers don’t like the ribbon as much as users do! I love the ribbon interface. When we start changing labels, and enabling/disabling controls, quite change occurs from menubars. Access applications use FAR more ribbons then a typical excel/word application (they likely have one ribbon). So, that means we need greater program access to the ribbon object. When one stays away from callbacks, the ribbon is great. When callbacks are needed, then we need a handle to the ribbon. Since we likely to have LOTS of ribbons, then we need a collection exposed (just like forms(), or reports().) Without a exposed handle to the ribbon, we are forced to build a global custom collection. (because the ribbon load event only occurs once), or shy away from call backs. I do now have a working class object that handles the whole ribbon like a menubar anyway. I plan to post the example ASAP. As for the nav paine? Well, #1, you taken away the alt-d shortcut. I used to highlight an object, and then go alt-d to open the object in design mode. This key is gone, so, now I use right click->design I like the nav pane, but when you have more then 30 items of ONE type, then scrolling is a bit of a issue. So, for new users, nav is likely easier, and more intuitive. As a tip to all here, if you right click on the nav, you can turn on the search bar. This search bar will filter all of the categories. So, if you start naming your forms, reports, quires by a group, or even with the SAME name, then you simply type in the first few chars in the search bar, and ALL OF the nav categories are filtered. So, it is rather nice/cool that the search filters all the categories at the same time. That means you can display the forms, reports and queries that you need to work with as a group. (assuming you adopt a naming convetion). This is very cool. Of course, for my current long time applications, I used frm, rpt etc for prefix and this search suggestion thus don’t work! So, right now, as item counts rise, then I do prefer the old way. Perhaps we just make each category able to be un-pinned. Then, we have the ability to have each catagories in a separate window. We thus change the view from details->list->icons like we always had and simply size the window. Being able to pull off these separate would allow forms list, reports list etc to be viewed in separate windows (at the same time!). Albert D. Kallal Edmonton, Alberta Canada
Anonymous
June 08, 2007
> Of course, for my current long time applications, I used frm, rpt etc for prefix and this search suggestion thus don’t work! I meant to say “don’t work that great” (the search is a instr type search). So, if you leave out the previx..you can still often filter the objects displayed. Distpite this tip, I still do find the lists a bit long.
Anonymous
June 08, 2007
Well, I was thinking about this some more while I was making the kid's lunches this morning (..discard the uneaten carrots.. add fresh carrots...) and I still think that there is a problem with getting to design view (...eat the untouched, bruised bananas, add fresh new bananas...). You can use a right-click (Thanks, Crystal - that did occur to me after I originally posted), but I do know from helping non-power users that they often don't know about using a short-cut menu, and they don't tend to just "try it" and see if something happens. So, imagine a new user, looking at a list of objects. Let's call him Sam :) Sam has selected a form, and knows he wants to work on the design of the form. Will he know about shortcut menus? Maybe not. Will he even know enough to double-click the name of the form to open it? I wonder. And there is nothing highlighted on the menu to give him a hint. Now, if the "View" menu item was hightlighted when he slected a form, he'd say "Hey! That menu item just changed - maybe I should click there and it will tell me what I can do...". I mean, the idea is that the ribbon is more "context sensitive", right? One other thing - I'm a little hesitant... (ok, I guess I'm not <g>)... to mention, but I teach blind and visually impaired students - and I wonder about the accessibility of the navigation pane/ribbon, etc. Can you use all of the features without touching the mouse? Maybe I'll try at lunchtime today... I haven't the latest adaptive software so I can't test this, so perhaps this might just be taken as a "flag" for the designers.. Cheers! Fred
Anonymous
June 08, 2007
The comment has been removed
Anonymous
June 08, 2007
I have a question for the access community. Do you guys actually let your users use the object names to start forms? My users NEVER see queries, forms, reports, etc. They are all called by the application via buttons, menus, etc. As I am reading peoples posts I am gathering that you actually use the navigation pane (or the database window in 2002/2003) for end users to navigate. To me the navigation pane is not an end user tool, its part of the development interface itself.
Anonymous
June 08, 2007
I can't stand the new navigation pain. (sp. intentional) Not only is it a more difficult container to use, it is far more difficult to hide. Of all my apps, less than 10% of my users ever get to see a database container. They get to see forms and reports, through menus. Everything else doesn't matter.
Anonymous
June 08, 2007
I love the new navigation pane. It's much faster to find what I'm looking for with the search and the list allows me to get work done quickly. I do have a couple of 'annoyances' about it though.

Shortcut commands do not work when an item is highlighted (or the ribbon has stolen the commands). I used to the Alt+D all the time to open objects, now I have to use the mouse. It really just needs to be more accessible for keyboard junkies like myself.
The default setup when you open a new database or a database that hasn't been opened in A2K7 is not configurable. I would like to be able to define whether or not the search shows by default, which list is used, and what view (list, icon, detail) is shown.
In relation to item 2 - I *NEVER use Tables and related Views view. Ever. Did I say that strongly enough? Why, even if I cannot set my own defaults, would someone assume you only want to see a few of the objects in the database when you start? C'mon, common sense here guys. (sorry, this is a bit of a rant because I find it incredibly frustrating). How do I use this feature (I do totally love it). Always use Object Type, List View, All Access Objects view sorted by type with Search bar turned on. The Search bar is my new best friend. I love it. I really can't say that enough. Working in an access database with any more than 10 objects now is so much better. I can live without the keyboard shortcuts because this feature saves me so much time. Occasionally I sort by Created Date or Modified Date but Access has a problem with keeping a reliable Modified Date so this isn't as helpful as I would like. But it is useful. I also really love the addition of sorting by type so that it's faster to find queries etc when you know what type they are in combination with the search.

Anonymous
June 08, 2007
Thanks for the comments everyone. I will try to summarize comments once they slow down. David--You can use trusted locations to completely get rid of security warnings in 2007. Here is an article about it: http://office.microsoft.com/en-us/access/HA100319991033.aspx. If you need to deploy a trusted location path, here is a article about how to do it through policy: http://blogs.msdn.com/clintcovington/archive/2007/02/05/how-to-deploy-trusted-locations-with-group-policy.aspx. You shouldn't need a code signing cert for Access 2007. From what I understand the runtime will allow you to write that key when installing a runtime app. Yes folks, it is coming shortly. Hopefully within the next couple of weeks. I know some of you are frustrated but the team is working hard to make sure it is done correctly.
Anonymous
June 08, 2007
The comment has been removed
Anonymous
June 08, 2007
I would rather not have to scroll through the list of objects. The older version let you size the window to see any number of columns. And I like the group style in 2003. Now ask us about the stupid ribbons. <g>
Anonymous
June 08, 2007
Most of what I would say about the new nav pane has been said by others, and said better, so I'll restrict myself to a few summary comments. The "one-size-fits-all" approach to configuring the nav pane suggests to me that it is aimed at the lowest common demoninator: i.e., the elusive "knowledge worker". But, most professional developers would rather die than let their regular users navigate through the nav pane to forms, etc. IMHO, all the nav pane does is annoy the majority of the developers who find it less flexible than its predecessors. George
Anonymous
June 08, 2007
The comment has been removed
Anonymous
June 08, 2007
The comment has been removed
Anonymous
June 08, 2007
Ken, On another side-note, the point originaly made was that Ribbons are for navigation for end users, or to accomplish a task, such as bold, Italics, etc. So, if we are FORCED to use ribbons, and ribbons can only call macros. Then my point was give us the ability to make direct calls to modules from ribbons vs. forcing us to use macros which forces the issueance of threat messages. Microsoft creates a catch22 and thats my complaint about it. I would never use macros if it weren't for the fact thats all a ribbon will call (other than using callback routines which is not a very intelligent workaround)
Anonymous
June 09, 2007
David Matney calling code and not using macros? I not sure where you missed something, but all of my menubar code for 10+ years has ALWAYS called code. I have NEVER used macros. The ribbon does not change this one bit. Your ribbon buttons can and should call standard access code in a module.. The process is identical to that of menubars. You simply set the on-action to the name of a public function, and you done. Further, remember, the public function run will be the current one in the FORM THAT HAS THE FOCUS. This allows you to build a ribbon that can be used for different forms. It also means that you code for the current form can remain in the current form where it belongs. For example, most of my forms have a public function called MyDelete. So, I can use the same “delete” button (in fact same ribbon) for multiple forms. And, what is REALLY great if the current form with the focus does NOT have a public function with that name, then a public function in a standard code module will be used. (so, you can have a global mydelete function, and for special forms that need to run different code…simply place that public function name in the current form.). I have no idea where or why you thought that menubars, or now ribbons need to call macro code. I never USED macro from a menubar (or now ribbon). So, this ability to call code from a ribbon, or menubar has not changed one bit in more then 14+ years of ms-access. So, set the on-action of the ribbon to your public function name you want to call. Eg: =MyInvoicePrint() You ribbion xml will look like: <button id="invPrint" label="Print Invoice" onAction="=MyInvoicePrint()"/> And, keep in mind, you can even pass parmaters. =MyInvoicePrint(“Customer”) You code would be standard access code that gets run. Eg: Public Function MyInvoicePrint (the above myinvoiceprint does not have a string parmaters, but it could have one to work with the MyInvoicePrint("Customers") example). So, I not sure why you thinking that you have to use macors for ribbon code…I never used macors, and the ribbon calls code the same way it did for menubars in ms-access. Albert D. Kallal Edmonton, Alberta Canada
Anonymous
June 09, 2007
Albert D. Kallal I didn't say call a form, I said call code, i.e. calling a function in a module. I realize you can use menus and could for years to call a form or a report. Thats different in access than calling a module. Last time I tried to call a module from a menubar in access 2000, you could not do it. Now if they added the ability to do that since, well my bad, I havn't tried since access 2000, and I do read the release notes on whats new for each version and I don't remember it ever being indicated that a menu option can now call a module directly. So if it is there, I will test is out, however, I know it was not available in Access 2000 unless via a convulted method. I do not plan on reloading 2000 just to confirm it though.
Anonymous
June 09, 2007
Ok, I did one more test and added the Equal sign inside the quotes and it worked. I do not remember being able to do this in access 2000, unless it was undocumented. IfI remember correct in Access 200, the GUI interface to build menus did not even allow you to choose modules it only listed forms, reports and macros as selectable items for the menu option. So if you had to manually key it vs. selecting it as an access object, then I never tried that and never saw any documentation that allowed you to do that as a workaround.
Anonymous
June 09, 2007
The on-action property setting been that way all along…. As I said, I done this for 10+ or more years. It works even in a97, and Even before that… Pay careful attention to my addition comments about have the function declared public in the forms module, or a standard module. The tip I gave means that the same menubar (or now ribbon) can call code In each forms module – whichever form has the focus will have the function code Run. So, adopt a common function name (eg: MyDelete). Then, each form can Run it’s own code. However, if you don’t place the function in the forms module, then it is global And, for global public functions, I often pick up the forms name: Public Function AskInvoicePrint() Dim tblgroupid As Long Dim frmActive As Form Set frmActive = Screen.ActiveForm tblgroupid = frmActive.frmMainClientB.Form!ID If frmActive.InvoiceNumber = 0 Then frmActive.InvoiceNumber = nextinvoice frmActive.Refresh End If DoCmd.OpenForm "guiInvoicePrint", , , "id = " & tblgroupid End Function The above is code that the invoice print button runs. note how I right away pick up the active form. After that, I can easily ref the forms object as if the code was running much like the code would if put behind a button on the form. In the above example, I also check if a invoice number has been generated before printing. And, the Refresh forces a disk write if in fact I do change the invoice number. And, in addition the above clip also passes the currently selected sub-form item that the invoice print form needs. Also, if the code you write is for the particular form, then as mentioned, you can simply place the code into the forms module code. There is no need to pick up the active screen...and you can use “me.” as you always used. I done the above since access97 and it likey worked in versions before that… Albert D. Kallal Edmonton, Alberta Canada kallal@msn.com
Anonymous
June 09, 2007
The comment has been removed
Anonymous
June 09, 2007
No, I don't like the navigation pane. I don't particularly like it personally, but if my clients and users liked it, I'd smile, learn to tolerate it, and get on with business. You know that what I'm leading up to is my clients and users don't like it, and I like that situation even less than I like the nav pane. It seems to be just another instance of trying to make things easier for end users but failing to fully consider the end users' situation. The users of my applications are also end users -- they typically do not have the screen real estate that Microsoft designers appear to think they should. I take that into account in my application design, and see no reason that the Access team can't do the same. My users don't see any reason that you can't, either. Whether they are working directly in Access, or whether they are using my application, they tell me that they need the ability to view just what they are using... no "this pane", no "that pane", no "the ribbon only takes the space of three menubars" (to people who have never, ever used three menubars), no "you can hide that, it only takes a few keystrokes", no "it only takes a few more keystrokes to get it back", and no"it's not really much effort to learn where we've moved things this time". <SIGH>
Anonymous
June 09, 2007
David Matney - I do happen to have A2000 still loaded on a machine...I created a menu bar, added a NEW MENU ITEM to it, and then went to the ON ACTION property. I hit F1, and the following message pops up: "Select the name of a macro or Visual Basic Function procedure that runs when you use the selected control. When you specify a Function procedure, you must use the syntax, =functionname()." I'd call that documented. You seem to have gone sideways off on a rant here; the problem is, what you are upset about is a non-issue, and has been for many versions of Access now.
Anonymous
June 10, 2007
David, The discussion about certificates and so on has been carried on by others, so I will stick to the ribbon. I, probably like you, are used to “normal” VBA functions and so callback functions seem weird. Having the return value in the parameters of a sub routine (by making the parameter By Ref and therefore updateable and returnable to the object calling it) seems a strange way of doing things. However, once you get going with them , they are OK. There are some articles on MSDN about the ribbon, some of them with .NET examples, which is a pain. It seems to me that the job with the ribbon was only half done by Microsoft. Perhaps it is understandable that they did not manage to get everything done before the launch of Office 2007, but it does make it difficult for Access developers. Anyway, here is how I handle things. It suits me, but there may well be better ways of doing it and would love to hear from other people how they manage things.

Use the USysRibbons table as explained in various documents. This holds the XML for the ribbon.
Use XML Notepad 2007 to create the XML. As you create the controls, you don’t get to seem them as they will look laid out on the ribbon (if only….), but you do see them in a sort of tree. It took me a while to get used to this, but as long as you make sure your ribbon controls are created as “elements” and that the control properties are child “attributes”, things work pretty well. You can even drag and drop controls from one place to the other, so, for example, if, as I did, you had a series of buttons on your ribbon and ran out of space, you can drag them onto a split button rather than have to rewrite all the XML. Mind you, some of the attributes may change or need to disappear so watch out. When ready to try the XML in your ribbon, you can copy the XML by clicking the CustomUI node in XML Notepad 2007 and then clicking on the copy icon. You can then paste the XML into your USysRibbons table. XML Notepad 2007 will inform you of most errors you can make, though I did manage to confuse it so much once that I had to go to a back up file of the XML. Having started off using only macros in my ribbon XML, I now only use callback functions. The best reference for all things ribbon that I have found is www.accessribbon.de, which is a non-Microsoft site. It includes the layout of all callback functions involved with the ribbon. Alternatively, you can wade through the Microsoft documentation or try using the Office 2007 Custom UI Editor as that will generate stubs for your callback functions from the ribbon XML, but in my opinion it is not as good otherwise as XML Notepad 2007. Unfortunately, XML Notepad 2007 will not create stubs for your callback functions, which is a real shame. You could also create your XML using one of the free Visual Studio Express products, but when I went to install one on my last PC the installation failed and I was unable to uninstall it. Stupid thing!
I’ve also had problems setting a global variable to hold a copy of the ribbon in case you want to change it dynamically. Like other global variables, it loses its value when your app has an error and then you have to start your app again. I’ve got round that by creating a class defined as type ribbon and set my global variable to that. So far, it has worked OK. If anyone is interested, I can post the code… It isn’t particularly earth-shattering and there may be better ways of doing it. It would be good to know whether Microsoft are going to supply a decent ribbon design tool at some point. If they are not, it would be worth someone creating one, but I would think that many people are put off by the fear of doing a lot of work only to find that Microsoft provide one and they then get no payback for their work. Clint, is there going to be anything from Microsoft, please?

Anonymous
June 10, 2007
The comment has been removed
Anonymous
June 11, 2007
>by M. David Matney >Albert, > But it was undocumented that you could call a modules function directly. No, that is not the case t all!! I don’t want to clutter up Clints blog, but the on-action always specified and stated that you can use the name of a function. I can’t ever remember reading anything other wise. If you hit help while in the on-action setting even in a2000, you get: <quote> Select the name of a maco or Visual Basic function procedure that run when you use the selected control. When you specify a Function procedure, you must use the syntax =functionname() </quote> The above is from a2000 help. Books, articles, examples, and even the help clearly states this. I have NO IDEA why you suggest that this is un-documented. I used this extensively since a97. I knew nothing about the product at the time, and from nearly day one I used Functions because that what the help and articles showed. I never gave this a 2nd thought. The help could not be more clear on this. > Access is a development tool (RAD) it doesn't need policing. That is not true. There are companies that scan their computers have found 45,000 mdb files. The fact that they are both a data store, and a program store is a HUGE issue your ignoring here. If a compay bans the use of mdb files because they can have code, then what do you suggest? That means no ms-access sales to that company. That means you can't use ms-acces any more. Further, there is a HUGE difference in security when comparing code and macros. I have TONS AND TONS of api code in my access applications. Macors don’t let you use the Windows api, or modify files outside of ms-access. Many companies have requested code free editions of mdb files etc because they don’t want malicious code to run when launching a mdb. You can have a macro run, but it Not going modify the registry, or files, or call api’s like vba code can. Anyway, I don’t want to clutter up clients s blog. However, what is nice here is that the on-action works the same in ribbons. So, you thus can and should have your menubars or ribbons call your custom vba code. You don’t need macros, and the help and documentation does not suggest otherwise. However, there are now some security considerations here, and in some environments, if you can use a few simple macros in place of code, there are some reasons to do this. By the way, articles and help for a97 also stated the same thing about using functions.. Albert D. Kallal Edmonton, Alberta Canada kallal@msn.com
Anonymous
June 11, 2007
No! Who thinks up these things?
Anonymous
June 11, 2007
Perhaps I've missed samples but I'd like to have control of the NP through code. Perhaps there is a way to prevent it from appearing in a user app (A2003 MDE) run from A2007 but it seems certain actions we perform make the NP visible to the user.
Anonymous
June 13, 2007
<ranting> No, I don't like it. It seems to suffer from the same problems as the rest of the UI changes. The bits I use have been taken away and either not replaced or replaced with something which always requires more clicks/keypresses than it used to do to get to doing something (especially keypresses, does Microsoft make more money selling keyboards than selling mice?). As a previous poster noted "who thinks these things up?" Previous changes have had an "organic" growth to them (like menus and Commandbars becoming more alike and items automatically being tucked away when not used and so on.) This 2007 stuff tastes like some design guys have been let loose without either technical or marketing being involved. As a previous poster noted "who thinks these things up?" As most Notebook displays are all going "wide" but not-so-tall why does anyone think it's a good idea to make a toolbar replacement which is taller with less items on it? This is not simply a case of things have moved and you have to find them again (which is acceptable when the benefits are tangible.) Then there's the fact that the whole office suite is riddled with inconsistent Look-and-feel, something which previous office generations have cut down on from generation to generation. Outlook has the old style Menus and toolbars but the message editing windows have the "ribbons". OneNote has Menus and Toolbars. So far all my users and contacts (across the board in computer ability) are saying similar things, paraphrasing "sure it looks pretty but I don't want to be married to it". So far this is all negative though, what do I want put back into the navigation pane? I want to be able to put it where it's in the right place for me while I'm working (my users don't get to see the old Database Window and won't get to see whatever follows it.) OK, the old one didn't exactly stay where you put it but that was because I had Popup forms placing themselves in places which forced Access to recalculate top and left. Fixing that would have been good. I want to be able to switch between ever changing items with a simple click and, if necessary, quick scroll (as opposed to click, click, scroll, scroll, scroll, and/or type, type, type.) <ranting> time to take the medication again...
Anonymous
June 13, 2007
Hi John, I hear you about the re-appearing bug. However, here are some methods of the DoCmd object that you might find useful in manipulating the nav pane through code: SetDisplayedCategories http://msdn2.microsoft.com/en-us/library/bb242883.aspx NavigateTo http://msdn2.microsoft.com/en-us/library/bb238943.aspx LockNavigationPane http://msdn2.microsoft.com/en-us/library/bb242880.aspx HTH Good luck
Anonymous
June 13, 2007
The new Nav Pane is slowing down by 85% my ability to find my queries, even given the search feature. I used to rely heavily on the 'date modified sort' feature of the multi-columned detail view. I can't believe this feature was removed because it provided obvious functionality. There's no reason... The search feature is a great enhancement to have, but I'm not always 100% confident of what I'm looking for in terms of how to spell it. When you have dozens and dozens of related queries it's easy to not know for sure. So while the search feature is welcome addition, it's not a substitute for a quick browse. I don't use a mouse while using Access, so making everything easily keyboard browsable as possible. I loved the tab-to-tab browsing in the old navigation system using ctrl-tab. As for the grouping of queries by type, I would find that to be a nice OPTION to have, but to do it by default totally corrupts a nice speedy tool I have of keeping like-related queries together regardless of type. I feel that query type (cross-tab, select, make-table) is subordinate to query name in the hierarchy of sortation preference. I used to love the ctrl-tab move, alt-left arrow-up arrow-enter move (to close queries), the alt-d move to design an object, and I find the F6 key to be too far out of the way for easy reach for moving around the panes. So overall, I'm not pleased with any of the keyboard shortcut modifications. In sum, for a daily user (non-developer) like me, the productivity decrease resulting from the nav pane and keyboard modifications alone offers a compelling reason to go back to office 2003 or not upgrade to 2007 in the first place. The heavy modification, feature elimination, and lack of noticeable improvement all leave me wondering 'what were they even thinking?' Does not compute. My 2 cents. Thanks for asking.
Anonymous
June 13, 2007
I dislike the Nav pain, along with what appears to be a majority. I am not too fond of the Ribbon Either for that matter. Just taking the operational point of view out of the picture ... between the Ribbon and the Nav Pane there is nothing left! Ultimately I don't think I can add any insight that has not already been spoken. But I am still going to ramble because this is a BLOG ... so if my comment is duplicate, that means I "second" the motion ... if its unique ... well then I bring the motion to the table! ...

The prior versions offered MUCH quicker navigation... in the Nav pan, all I do is click many times and scroll forever ... The search is nice but IMHO is should HILITE matchs ... That functionality could have easily been added to the prior version of the db window
I miss the columns of info (detail view) ... the 4-lines per object thing is terrible ... people think and work in grids and sheets ... not reports with groupings
Adding to the Ribbon mix (I know you didn't ask..) but here you remove TONS from our site force us to look "horizontal" for commands (a real pane), then toss us into "vertical mode" with the Nav pane and Office Button ... IMHO, you should have remained consistent and ditched the office button and created another tab named "Document", then we could at least our mode (vertical/horizontal searching) for the scope (ribbons and nav pane) would be consistent.
Ribbons (again) ... Do seem to work well in the Word/Excel environment (still don't like them their either) .. but in Word/Excel .. you basically have ONE goal, to create a printable document. You are working with sheets of paper and text and formatting that text to look a certain way. I do not say that in a derrogatory way, that just the typical goal. In Access, its a different animal! ... and not as well suited to the Ribbon method.
Nav pane, if it remains, should be dockable, have a TreeView option, and and Auto Hide/Show options
May have more to add later ... but now #5 is crying .... and I have to comfort him ... (he must have just saw the Nav pain and Ribbon :) ... LOL ) Regards, Brent datAdrenline

Anonymous
June 13, 2007
The comment has been removed
Anonymous
August 20, 2007
I learned a new trick today from Michael the PM for the navigation pane. We have heard a few of you have

Share via

Do you like the new navigation pane?

Comments

Additional resources