|HCS Consulting Group.|
|We make Complex Systems simple|
Picture by Albert D. Kallal
August 14, 2012
Tips to be even more productive with the navigation pane in 2010.
I will say that for the vast majority of my access work has been with Access 97, and then 2003.
I can well say that these two versions are great and classic releases of access. I did use 2.0, but not a lot. And I also worked with Access 2000. So I not had to think about how I use Access for a VERY long time.
When faced with this new navigation pane system, I had to either figure out a new way to work or I was going to suffer. At the end of a day as a developer or even just a user the trick here is to be flexible. Changing how I worked with the nav pane resulted in major gains that I now miss dearly when going back to older versions of Access. If I total up the gains and improvements with the nav pane and then subtract the losses, then I feel I have come out ahead in terms of productivity.
Before I share my tips, I think there is a really great lesson to be learned from the above. If you do not change HOW you work, then you lose things you had before and you will not realize any gains in the speed of your work unless you adopt new features that can help you! In other words if you don't change how you work, then this will be all downhill for you! You will not like the nav pane.
You don't change in how you move around and select objects from previous versions then you going to suffer a drop in productively.
You have to think of this like two boxes you place features into. You taking features out of one box that you used for a long time. You are then adding some features to the other box that improves things. So the give and take is not the same task or feature here.
In other words, without a change in how you work you will lose abilities you had before. And thus without a change in how you work you will gain nothing new when using the Nav pane.
Over time, I now become comfortable and taking a liking to the new Nav system. In most circumstances I prefer Nav pane and long for that Nav pane when using Access 2003. Realization of this advantage only occurred AFTER I changed the way I work.
Not all is sugar coating as I certainly miss things from the old system in regards to selecting Access objects.
The only real squabble here is why should we learn something new to improve the speed of our work? Well at least in my case, the day I stop trying to improve and learn things is the day I am quite much done in the IT business!
Perhaps my liking of the Nav pane is due to me being a keyboard junkie. I have higher then average typing speed. I spent large parts of my career on serious mainframe and command line driven systems. Even FoxPro (DOS text version) was much a keyboard centric type of development environment that I loved and used for a number of years. So past history with keyboarding systems likely helps my adoption of more typing and searching in Access 2010 in place of visually selecting things with the mouse.
As always one's mileage will vary on these issues. The best I can do here is share what changes I made that works well for me when using Access 2010. What works for me may not be the cup of tea for you!
However, my points are view are coming from a developer centric point of view and that should be encouraging to Access developers.
Ok, so lets get this show on the road.
First thing is to setup the NAV pane to show all objects, and show by group. You also want to ensure that the search bar is enabled and displayed. I have sat down on a few people's computers in which they said they didn't like the NAV pane, and I was in shock and horror that they did not have the search bar displayed. They ALSO had not turned on the group by object type. At that point it was little wonder they did not like this setup since you can't get any work done with that default setup! In this example am going to use a database with well over 500 objects, it is quite large, with an excess of 160 forms alone. So if you have NAV pane setup as I suggest, then you should see the following:
If you look at the above, that's a pretty nice clean layout for a database that has over 500 objects. I stress and strive to keep my desk clean, and I like the above un cluttered look.
First tip: Remember that control-F is your friend here. In fact I use control-F a lot even when I'm NOT going to search something. Control-F means that your cursor does jump up to the topmost of the NAV pane and is placed inside of the search bar box. So Control-F becomes not only a find key, but also shortcut to get your cursor up to the very top of the NAV pane. (home key also works, but more on that later). Once ctrl-f puts cursor in search box, then I can now tap down arrow one time to drop down into the nav pane. In fact, you have to hit down arrow a second time if you want the first group (tables) to highlight. You can then hit right arrow key to expand that group.
You should now see this:
In fact the keys you use really are the same shortcut keys you would use when traversing a tree view in windows explore or even the treeview we see in the VBA code editor (you folks do display that treeview in the VBA editor to jump to any code module, right?).
So, at this point I could hit the right arrow to expand the first group called tables. (and also quite important here is that hitting the left arrow key will collapse this group). And the tip here is to work with ALL groups collapsed.
Now that you perhaps expanded and collapsed the tables view for some fun, let's now assume I want to work on some code modules. If your cursors still in the group "tables", but collapsed, then simply just tap the end key, and then the right arrow key. You should see something like this:
So the home key and the end key will jump to top and bottom of the nav pane. And a right arrow key will expand it. So from the top going down, or the bottom going up after doing that choice then you are quite much only two keystroke taps away from jumping to any group (forms, reports, modules) you have. And for those that don't have any macros, you'll find that the macro group does not even appear so you'll even have less arrow keys or movement to jump from group to group here.
Now you've expanded the group, you can now use the down arrow to work your way through this list. However let's assume that we want to work on the code module called CRide in the above list (it just happens to be a class module). I on purpose chose something far down the list in 18 place.
(I hate those fake easy examples in which someone has 1 code module and supposed they going to break out in sweat for getting to the one module!).
Now I do not want to hit down arrow 18 times, so I hit ctrl-f, and type in cr and then in fact can hit the enter key. That was only 3 keystrokes.
So, we see this:
And then of course you hit enter key (in fact I stress you want to use ctrl-enter key to open up these objects in design mode. So we now get:
note the above treeview on the left side – this in 2003 or 2010 is another handy way to jump to additional code modules if need be).
So, the above was FEW key strokes, and not really any scrolling around.
Now how about the same in 2003? Well, first we have to select the code module tab. (or shift tab to cycle over to modules). And then I would have to hit the c key. However, hitting the c key ONLY gets me to the first module. I thus have this in 2003:
I can now hit C key SEVEN more times, or hit the down arrow key SEVEN more times. (and you CAN hit a quick CR to jump right to CRides just in case some did not realize this).
So, in some cases I am sure 2003 might be fewer keys, but in this case, we really close, and I would say we about even, or perhaps a few less keys in 2010.
Now of course CRide worked well for the search since no object in that group had CR. However, even in those cases where a few matches occur, there not much arrow key need, so for example to work on 19th object of "groupscode", ctrl-f and then I type in gr, I get this:
So in above I do have to hit down arrow key one time.
The other tip is to CLOSE the group when done.
Another tip is to use shift tab to jump to the TOP of the group to close it.
Then a left arrow to close the group. So, when you have multiple groups open, then tab will jump to next group, and shift tab will jump up. So, a shift tab, and then left arrow to close the module group.
As you can see in the above comparisons, the amount of keyboarding and key strokes I have to use to get around is really not much different to 2003.
One really nice features of nav is not only do we have searching, but you can display objects from all different groups at the same time on your screen. This means during the development process you eliminate having to switch to different object groups.
And since the searching occurs anywhere in the text of the object name, not just the start, then it's pretty flexible this way even for those applications that you have not written, or don't even have that great of a naming convention.
For example, let's assume that I need to work on the invoicing part of this application, I simply go ctrl-f. And then type in invo (short for invoice).
I then hit down arrow, then tab, then right arrow, then tab tab, then right arrow (I am jumping teach group and expanding it).
We now see this:
Now you could say that I wasted up some keystrokes in the above to open up everything with tabs, but if you look at the above I can now work on any object with a single right mouse click and choose the particular object in question. In 2003 I WILL have to jump to each separate object and use up keystrokes at that point in time.
In other words I'll eventually have to use some clicks and keystrokes to move around in 2003, but in this case I simply queued up and got all my keystroke and stuff out of the way by expanding the groups - I'm now free to work on the set of objects.
In the above I now have one nice little pane list of just a few objects I'm working on. As noted, I am working in an application with well over 500 objects. The above cute little list is tidy and clean. In fact this makes what is a very large application seem quite small and delightfully easy to work with. And even better is I don't have such a great memory, so as I'm typing in something into the query builder, I can often glance at the left pane and view a table name, or even perhaps a forms name I'm referencing.
And looking close at above, note again how there not even a need to see or use the scroll bar here, as the list of objects fits on the screen.
Thus virtually all of the objects related to invoicing in this application are now in plain view and I find this not only is handy, but also reduces the mental workload to remember what objects I need to view and work one. And I get to deal with all objects in view as a group which often triggers my memory that some other task is needed to complete.
And often I can't remember the name, but I know it is invoice or some such. In 2010 I just type in a few characters and I almost always have the object right there at my fingertips.
At the end of the day you can see that just a slight modification of my development approach here and my productivity was not really hurt at all, and in fact in a good number of cases, as the above shows I actually become a bit more productive in some scenarios.
One feature in 2003 that I loved and miss is when you switch between two different groups; access would always remember the last object that you are working on. I certainly do miss that feature, but my point being here is this is one of those give some and take some here.
This bit of give and take means some things are harder in one area, but are thus superior in another area.
At the end of the day I figure I come out slightly ahead. I think adopting the above most will find themselves certainly in the range of productivity one had before the nav pane.
And oh - one more key stroke: if you are in the middle of a form in design mode, then ctrl+alt-f will JUMP the cursor right into the search box.
Albert D. Kallal
Edmonton, Alberta Canada