 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
MS Access Forum / General 1 / June 2006Access 2007 Custom Menu Bars
I've been clicking around Access 2007 Beta 2 and can't see the custom menu bar designer. Is it in the beta? Maybe I'm blind. The question that comes to mind is: Will custom menu bars be the same height as they were in previous versions or will they be the "ribbon" style that takes up a huge portion of the screen? Also when I use Access 2007 to open an Access 2003 database that has custom menu bars they display as they did in Access 2003. If I convert this same database to the Access 2007 format the custom menu bars seem to be lost and don't display. Given that the final version would hopefully be able to convert the custom menu bars of earlier versions, if they are the ribbon style, this will spell trouble for any forms designed for full or near full screen display ie. they won't fit the screen with the ribbon style menu bar taking up the space that it does. Hi, Wayne. > I've been clicking around Access 2007 Beta 2 and can't see the custom > menu bar designer. Is it in the beta? Kinda. One can customize the Quick Access Toolbar by adding built-in commands, but no custom commands. Select the Office button in the top left corner of the screen, then select the "Access Options" button on the bottom right of the pop-up window to open the Access Options dialog window. Select the "Customization" navigation menu item on the left, then select the "Choose commands from" combo box and select from the menus or sections that contain the functions you want. Select an item in the list, then select the "Add > >" button to add it to the toolbar. When you're done adding the buttons you'd like, select the "OK" button to close the window. You also have the option of placing the Quick Access Toolbar above or below the UI ribbon. > Will custom menu bars be the same height as they > were in previous versions The Quick Access Toolbar appears to me to be the same height, but one cannot create custom menu bars (CommandBars) in Access 2007 database format. > or will they be the "ribbon" style that takes > up a huge portion of the screen? One can build custom UI ribbons for the Office 2007 applications by writing code. XML code. Really. > If I convert > this same database to the Access 2007 format the custom menu bars seem > to be lost and don't display. Access 2007 database format doesn't support CommandBars. CommandBars have been replaced throughout the Office 2007 applications with the UI ribbon. > Given that the final version would hopefully be able to convert the > custom menu bars of earlier versions The final version isn't going to make this easier. If you want to "convert" your custom CommandBars from the earlier versions, you'll either have to manually add the buttons to the Quick Access Toolbar, or you'll have to write the XML code for your own custom UI ribbons. > they won't fit the screen with the ribbon style menu > bar taking up the space that it does. Oh, that. See the tabs at the top of the UI ribbon? Home, Create, External Data, Database Tools, et cetera? Double-click on any one of the tabs. Squeeze. Double-click on one of the tabs again. Expand. Convenient, huh? That makes up for Microsoft's claims that Access 2007 is designed to be easier for Access developers, doesn't it? ;-) HTH. Gunny See http://www.QBuilt.com for all your database needs. See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials. http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info. > I've been clicking around Access 2007 Beta 2 and can't see the custom > menu bar designer. Is it in the beta? Maybe I'm blind. The question [quoted text clipped - 12 lines] > screen display ie. they won't fit the screen with the ribbon style menu > bar taking up the space that it does. As pointed out, if you want old style menus, you have to keep your database in 2003 (or earlier) format. The new system allows you to build ribbons, but menus are gone. I plan on writing a converter, but my "to do" list is rather large right now.......  SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal Thanks for the feedback. I find it frustrating that custom menu bars will no longer be an option. I use them extensively in my applications. As for being able to design custom ribbons, unless I misunderstand, I'll be forced to sacrifice a huge amount of screen real estate to a ribbon that may only contain a couple of items. I'm assuming that the ribbon will remain at the standard height irrespective of how many "menu items" it contains. >I'm assuming that the ribbon will remain at > the standard height irrespective of how many "menu items" it contains. I just don't know the above yet......... If I can shrink it down in size, then I certainly use the feature more. For my existing applications, likely they will stay in a2003. However, if the ribbon can be sized down a bit, then I will certainly use them, and move my menus to it.... I *often* wanted something larger then tool bars...but, not quite as large as the ribbon is now! SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal > I *often* wanted something larger then tool bars...but, not quite > as large as the ribbon is now! I think that this is the kind of discussion that ought to be on the Access blog in comments on posts that cover the relevant UI components. There needs to be a way for the Access team to get this kind of feedback from developers, and that looks like an obvious place for it. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi, Wayne. > I find it frustrating that custom menu bars will no longer be an > option. If it's a built-in function, then you can always add it to the Quick Access Toolbar, but if you have custom functions, then you'll have to write XML code. > As for being able > to design custom ribbons, unless I misunderstand, I'll be forced to > sacrifice a huge amount of screen real estate to a ribbon that may only > contain a couple of items. Well, if they're built-in functions, then place those buttons on the Quick Access Toolbar and squeeze the UI ribbon to minimum height. > I'm assuming that the ribbon will remain at > the standard height irrespective of how many "menu items" it contains. I suspect you're right. Standardization and all that. HTH. Gunny See http://www.QBuilt.com for all your database needs. See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials. http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info. > Thanks for the feedback. > [quoted text clipped - 4 lines] > contain a couple of items. I'm assuming that the ribbon will remain at > the standard height irrespective of how many "menu items" it contains. >> I'm assuming that the ribbon will remain at >> the standard height irrespective of how many >> "menu items" it contains. > > I suspect you're right. Standardization and all that. "But," said the UI person at Microsoft, "they are _only_ the height of three toolbars." Of course, not a single one of the Access applications I created since 1993 have created that used even two toolbars. <SIGH! Why do I have this nagging suspicion that those 'Softies are provided with 23" screens? > But, of course, I guess it was important that they have room for their larger icons that to me are just as cryptic as the smaller ones have been. Larry Linson_ > >> I'm assuming that the ribbon will remain at > >> the standard height irrespective of how many [quoted text clipped - 7 lines] > even two toolbars. <SIGH! Why do I have this nagging suspicion > that those 'Softies are provided with 23" screens? Hold on, there. Keep in mind that a menu and a toolbar are the same thing, is it not the case that one menu plus one toolbar is two toolbars? SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ The "tabs" take the space that the main menu line would take. The ribbon is below the tabs, and Gunny has pointed out other apparent anomalies to the "just three toolbars" statement. Larry >> >> I'm assuming that the ribbon will remain at >> >> the standard height irrespective of how many [quoted text clipped - 11 lines] > thing, is it not the case that one menu plus one toolbar is two > toolbars? Hi, Larry. > "But," said the UI person at Microsoft, "they are _only_ the height of > three toolbars." He's full of it. Measure the UI ribbon next to the menu bars and toolbars from an earlier version of Access. The title bar and UI ribbon are equivalent to the title bar, built-in menu bar, and four toolbars in height. Subtract the height of the title bar, and that leaves the height of five CommandBars total for that UI ribbon. Hardly three toolbars. It's really noticeable for those of us who generally only have the built-in menu bar and one toolbar showing. From the top of my screen to the bottom of the UI ribbon, it's now 1/4 of my screen real estate unavailable as working space unless I can collapse the UI ribbon. When a table is open in Design View, almost four rows are available for adding field names. A bit of a squeeze. Can I just maximize the table? No. Got no maximize button to press. I've got to collapse the UI ribbon, and then shove the navigation pane all the way to the left to get most of the screen for my table. > <SIGH! Why do I have this nagging suspicion that those 'Softies are > provided with 23" screens? > That and given the fact that they've got good enough eyesight to use high resolutions, and their screen real estate sacrificed to the UI ribbon isn't much. HTH. Gunny See http://www.QBuilt.com for all your database needs. See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials. http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info. > >> I'm assuming that the ribbon will remain at > >> the standard height irrespective of how many [quoted text clipped - 12 lines] > > Larry Linson_ Can one still create custom shortcut menus? Can one turn the ribbons off entirely? If both are yes, then I would just start building menus that are accessed via a clickable menu label on each form and stop using command bars in the main window entirely. I struggle to get some of my forms to fit on some user's screens with just one menu bar and one toolbar. That ribbon would force half my user-base to buy new displays. It's also possible to create a wide, short, borderless form that looks and acts (pretty much) like a command bar. Big problem with those is that they are not "dockable". SignatureRick Brandt, Microsoft Access MVP Email (as appropriate) to... RBrandt at Hunter dot com > Can one still create custom shortcut menus? Yes. So far I have found that one can do this in code and in Customization by using Macros or Built-in Commands. (For the beginner etc, I can point out that one can run code, or do just about anything from a Macro.) > Can one turn the ribbons off entirely? Yes in a application developed in a previous version. Not yet and perhaps not ever in a pure Access 2007 application. I have a Northwind with just the Northwind Custom Toolbar showing in Access 2007. I can accomplish this in the Customization dialogs. Please, don't infer I like or support this. I'm just exploring. BTW, this is a VERY Beta. When I mess with the Access 2007 Ribbon it sometimes opens a second instance of Access which takes and will not relinquish 99% of CPU usage; also sometimes memory seems to leak into the video sphere as bank rectangles appear on my screnn and the window for other applications become blank. Those without a high tolerance for rebooting may wish to take this into consideration. After reading the two parts of http://msdn2.microsoft.com/en-us/ms406046(office.12).aspx and experimenting with same I think we will become easily familiar with customizing the Ribbon over time and find it to be useful. > I find it frustrating that custom menu bars will no longer be an > option. If your appcation has code that creates menu bars and options, they *will* appear. In other words, the command bars object is still avaling, and is done so for compatibliry. the downpart is that they will appear in the ribbon. >I'll be forced to > sacrifice a huge amount of screen real estate to a ribbon that may only > contain a couple of items. I'm assuming that the ribbon will remain at > the standard height irrespective of how many "menu items" it contains. If look at the ribbon, it is broken into tabs. If you double click on a ribbon tab, then the ribbon hides. So, you can well easily hide the ribbon. I don't know about changing the "height" of the ribbon just yet.... SignatureAlbert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.members.shaw.ca/AlbertKallal > If look at the ribbon, it is broken into tabs. > If you double click on a ribbon tab, then > the ribbon hides. So, you can well easily > hide the ribbon. You can hide most things, one way or another, but I don't _have_ to take that extra step (those extra steps?), now. > I don't know about changing the "height" of the ribbon just yet.... Yes, I don't know about that, either. Larry I use custom menubars or commandbars or whatever the correct terminology is extensively. I've just opened an Access 2003 database in Access 2007 that uses a custom menubar in the reports. Now, instead of having a neat space-efficient menubar with 4 items on it ie. Close Report, Send As Email Attachment, Save As Snapshot and Print, I have the ribbon with these 4 items at the top and a heap of wasted screen real estate below. This just doesn't seem to make any sense. I can see advantages with the ribbon in general, but why have they taken away the ability to easily create custom menu bars. Do we really want to be forced to write XML code to create a custom menubar? Is this making things easier for the end user? Hardly. Another question that comes to mind is this: If the new ribbon is the be all and end all of a better user interface, why haven't they used it in Outlook? There seems to be no consistency here. Hi, Wayne. > why have they taken away the ability to > easily create custom menu bars. As Lyle corrected me elsethread, one may add custom CommandBars in Access 2007 via VBA code. They show up on the Add-ins UI ribbon. > Do we really want to be forced to > write XML code to create a custom menubar? We'll have to write XML code to customize UI ribbons, but we can write VBA code that we're all familiar with for custom CommandBars on the Add-ins UI ribbon. The problem with that is it takes longer to write, test, and maintain the code for this than it did by just dragging and dropping the "Custom" button on a CommandBar and modifying that in the GUI. > Is this making things > easier for the end user? In Microsoft's eyes, yes. The Access usability tests with beginning- and intermediate- level Excel users pinpointed the things they struggled with, so the UI ribbon has been designed with them in mind. The Lead Program Manager on the Access team stated that as they added things for the end users, the developers got excited about them, too. Basically, what's good for Excel users is good for Access developers, too. The more I explore Access 2007 and the more I read on Microsoft's site, the more I suspect that Microsoft believes that an Access developer is an Excel user who needs Access as a go-between for the "real" data source and Excel, and just wants to do a few point-and-clicks and to just start typing -- without any understanding of how to normalize the tables, let alone how to build a database application. > Another question that comes to mind is this: If the new ribbon is the > be all and end all of a better user interface, why haven't they used it > in Outlook? Sometimes they run out of time during development and have to move some features into the next release. HTH. Gunny See http://www.QBuilt.com for all your database needs. See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials. http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info. >I use custom menubars or commandbars or whatever the correct > terminology is extensively. I've just opened an Access 2003 database [quoted text clipped - 14 lines] > be all and end all of a better user interface, why haven't they used it > in Outlook? There seems to be no consistency here. > The more I explore Access 2007 and the more I read on Microsoft's > site, the more I suspect that Microsoft believes that an Access [quoted text clipped - 3 lines] > understanding of how to normalize the tables, let alone how to > build a database application. Then it seems to me that it's important that the people in this discussion in this newsgroup weigh in on this subject in the comments on the Access blog to make sure that somebody has a chance of getting the message that the Excel approach is badly mistaken for a large population of Access developers. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ >Sometimes they run out of time during development and have to move some >features into the next release. This is probably true, but if they don't have time to standardize the interface of what is being touted as a major upgrade to Office, what hope is there of an Office suite that isn't full of bugs? It's not as if the software is exactly cheap. Roll on the endless service releases! Hi, Wayne. > if they don't have time to standardize the > interface of what is being touted as a major upgrade to Office, what > hope is there of an Office suite that isn't full of bugs? The standardization of the interface wasn't as important as making sure that key features worked, so while we can expect bugs after it's released, it won't be as buggy as it would have been if they'd spent the time on the interface instead of fixing bugs. HTH. Gunny See http://www.QBuilt.com for all your database needs. See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials. http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info. > >Sometimes they run out of time during development and have to move some >>features into the next release. [quoted text clipped - 3 lines] > hope is there of an Office suite that isn't full of bugs? It's not as > if the software is exactly cheap. Roll on the endless service releases! Hi '69 Camaro. > The standardization of the interface wasn't as important as making sure that > key features worked, so while we can expect bugs after it's released, it > won't be as buggy as it would have been if they'd spent the time on the > interface instead of fixing bugs. I understand what you're saying, but isn't it a bit like if General Motors released a new model and because they had to spend lots of time ironing out bugs with the engine they were unable to update the frontend of the body, so the new model is released with an all new body except that the grille, headlights etc are the same as the previous model. This sticks out like a sore thumb but they figure the buying public will understand that in their rush to get the new model on to the streets they didn't have time to finish the new body work. The motoring buying public wouldn't accept it. The reason they wouldn't accept it is because in the auto industry there is such a thing as competition. As we know it's a Microsoft world and, although some may disagree, Office has no real competition in the business world. Hence they can release something that obviously isn't finished and not only get away with it, but have people justify their position. ;-) As far as the number of bugs we can expect, let's hope they have it sorted out by service pack 3. >>Sometimes they run out of time during development and have to move >>some features into the next release. [quoted text clipped - 4 lines] > bugs? It's not as if the software is exactly cheap. Roll on the > endless service releases! Uh, why did you paste that quotation into a followup to a message by me that didn't have that text in it? SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ Hi, David. > Then it seems to me that it's important that the people in this > discussion in this newsgroup weigh in on this subject in the > comments on the Access blog I plan to. I'm making my list. I'm focusing first on things that reduce developers' productivity, but I'm including the things I like as well, because there _are_ some nifty things about Access 2007 -- but so far I haven't found anything quite nifty enough to compel me to purchase Office 2007 Pro at $500 for each computer in my office. HTH. Gunny See http://www.QBuilt.com for all your database needs. See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials. http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info. >> The more I explore Access 2007 and the more I read on Microsoft's >> site, the more I suspect that Microsoft believes that an Access [quoted text clipped - 9 lines] > of getting the message that the Excel approach is badly mistaken for > a large population of Access developers. >> Then it seems to me that it's important that the people in this >> discussion in this newsgroup weigh in on this subject in the >> comments on the Access blog > > I plan to. I'm making my list. . . . Er, the Access blog is up and running and there are posts there about the topics that people have been discussing here. I reviewed all the comments and nobody has criticized the aspects of the ribbon that have been criticized here. There's also a fundamental lack of understanding among the comment thread participants of the downside of ADPs and the issues regarding Jet and linked tables in MDBs. What is *very* clear is that ADPs are dead -- the Access team no longer recommends using them with SQL Server. But there are still people who are scared of Jet, believing it can't do the job. I don't know why these people prefer the incorrect guesses about what data you want that ADO makes to the incorrect guesses that Jet sometimes makes, but they seem to prefer them. I think it's probably due to irrational dislike of Jet, but I have no proof of that. SignatureDavid W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ > This just doesn't seem to make any sense. I can see advantages with > the ribbon in general, but why have they taken away the ability to > easily create custom menu bars. I don't know if this is easy but the Quick Access Toolbar seems to be responsive to Macros . In Customization we can add macros to the Quick Access ToolBar. > I've been clicking around Access 2007 Beta 2 and can't see the custom > menu bar designer. Is it in the beta? Maybe I'm blind. The question [quoted text clipped - 12 lines] > screen display ie. they won't fit the screen with the ribbon style menu > bar taking up the space that it does. I think one can create custom menu bars and dropdowns in code. I haven't been able to find any ui provision for this. And my efforts are still very clumsy. Regardless this adds a menu-command visible by selecting add-ins which pops up the message "loop". The whole thing requires mucho imnprovement: (I haven't read all the thread and if someone has already pointed this out, or a better way, then I'm sorry I wasted your time.) Sub temp3() Set myMenuBar = CommandBars.ActiveMenuBar Set newMenu = myMenuBar.Controls.Add(Type:=msoControlPopup, Temporary:=True) newMenu.Caption = "Custom2" Set ctrl1 = newMenu.CommandBar.Controls _ .Add(Type:=msoControlButton, Id:=1) With ctrl1 .OnAction = "= tempfunction()" .Caption = "Test" .TooltipText = "Just a Test" .Style = msoButtonCaption End With End Sub Public Function tempfunction() MsgBox "loop" End Function Oh, I think we need to set a reference to the Office 12 library. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.