Why VBA still makes sense

CyrusB:

>I did not imply that I wanted my custom right-click actions to be transferred to a customer application. Understood, but others jumped in and muddled up this issue and on went the challenge me about creating right click menus in the runtime (which you can do!). So, not trying to dish this issue, but it was sidetracked though no fault of your own (I am sorry about this). >However, since, the VBA IDE has changed so little in almost a decade (and not really that much since at least Access 97), it was a very handy thing to be able to make some basic productivity enhancements myself. So that it is clear: THAT WAS REMOVED IN 2007 I 100% agree with the above. Again no sugar coat here. However, you can still use the right-click customize feature in the 2007 VB IDE to create new tool/menu bars in the code editor. So, the menu customize option in the VBA IDE works the same as it did in pre ribbon versions. The menu customizing NOT been removed for the code side editor. The ability to add new buttons etc. in the IDE works JUST like it did before. However, for the UI side for forms etc? Well, the feature is still there, but you don’t have a right click customize option any more. You can still use the commandbars object + VBA code to add your own custom right click menus. I am not saying this is a great workaround (it is not!). However, it is STILL possible to add options to the context menus in the UI design side of things this way. Again, this loss is more of ribbon thing then someone sitting down and saying we don’t need that option anymore. but, it still fair to point out you don't have a easy customize option anymore (I not disagreeing with you). >Oh and your rant about DAO is really inane. Sure, it's a library, but to all intents and purposes, it IS part of the language. I stand by the fact that it an external library. I not here to argue with you. So what is the real issue here then? The point is that the ribbon object should be BETTER exposed with MORE methods we can use from VBA. The methods exposed are really lacking. See, so we both 100% agree on this issue (at least I am a betting man we agree). The issue here is not that DAO or the ribbon object is part of VBA (or not part of). The REAL problem is that we lack a decent object model and methods being exposed for that ribbon. This is a true short coming. And, guess what? I made the above known to the access team. Based on complaints we DID receive the ability in code (VBA) to now activate a tab of our choice (could not do this before). I would also like to see a built in method to minimize the ribbon (I now modify the registry + sendkeys to accomplish this). There is a new minimize button on the ribbon now, and I do recall reading something about being able to execute that button from code (but I not looked into this yet). However, as mentioned, it really is the office ribbon group that owns that ribbon. So, most changes to the ribbon are by nature going to apply to ALL OF office + VBA, not just access. We have to keep that in mind. Like any developer to deal with the above issues I built an ribbon class object to “tame” the ribbon and it now easy for me to manage the ribbon the way I want (with nice VBA methods and intel-sense when I code). The article and download appeared on this blog some time ago. So, I solved this problem for me, and is was easy! However, just because I can crank out code to fix this stuff in my sleep still does NOT sugar coat that we need BETTER exposure to the ribbon. I for example really want the collection of ribbons loaded exposed to VBA. This would really help things and mean I don’t have to use my own collection to “manage” the ribbon as I do now. I take exception you calling me a blind fan boy, as I am not. As I stated here I will go to bat and even use my good influence in the access community for ANY good feature request that access can use. I will even go to bat for you! CyrusB, you have a great day...I am running out a coffie and have to get back to work!

Vladimir;

ERwin: Not sure if there's RT in the tech-preview. I don't even have the tech-preview. I think you could test runtime environment if you'll run MS Access (in command promp) with your application as a parameter & a parameter for runtime, like this: "D:\MSOfficeTechPreview\Office\msaccess.exe" "c:\AccessApps\YourApp.accdb" /runtime Vladimir my friend I just want to test the A2010 runtime to a machine which have A2k3 and A2k7 pre installed to verify if it will not go crazy (conflicts Like a buggy A2007). Thanks for the reply ERwin

Folks,

Lively conversation... Lets just try to keep everything open and respectful. As I have said before--there are lots of highend features that would be great to do. VBA OM for the ribbon is just one of the many opportunities that could help developers build better applications. It pains me that we haven't improved the navigation pane or SQL editor. I understand that these requests have been raised in the blog for a while. Unfortunately, when we prioritized the work it fell below the line. The team didn't think we could ship another release without the ability to create browser applications. We have had too many requests from a broad spectrum of customers (including readers on this blog) for improved deployment and manageability. We looked at ways to scale back the web investment but didn't think the offering would have critical mass... In the end, we had to make tough decisions. In the end, the improved manageability and deployment that web apps gives us became the high order bit for this release.

Thanks Albert. It was nice of you to respond as you did. The fan boy stuff was borne out of frustration, as you graciously seemed to be aware. :) W.r.t the custom right menus in the VBA IDE, yes, you can right-click and select 'Customize...', but the thing is, you can not actually add new commands to it anymore. You can only re-arrange/hide/show existing inbuilt commands. In previous versions, once you right-clicked the IDE's toolbar and clicked 'Customize...', you could then select the 'Custom' command and drag it to an existing or newly created toolbar. You could then right-click the new command and set its properties, such as the 'On Action' property that could be used to run code. This can no longer be done in 2007. So not only has the IDE not been updated, it has also now been crippled. Why? *Bangs head against wall*

> you could then select the 'Custom' command and drag it to an existing or newly created toolbar. You could then right-click the new command and set its properties, such as the 'On Action' property that could be used to run code. I am in 2003 right now, and you can’t do that in the VBA IDE (you never could unless you used code). I also just fired up access 2000 and it is the same. So while you can right click and choose customize in the VBA IDE, there is no add “new command” in the VBA editor list of commands. So this has not changed and it not changed for the VBA editor in 2007. >This can no longer be done in 2007. So not only has the IDE not been updated, it has also now been crippled. Why? *Bangs head against wall* The above is ONLY the case on the forms/reports UI desing side of things. As I said however, you CAN still use VBA to add right click context menus to EVEN those built in right click menus that you use during development on the UI side. I will admit having to use VBA it not the best answer, but it is still possible for you to add to those built in context menus if you really need to do this. So, to be clear, on the VBA editor, the 2007 customize option is the SAME as previous versions and you can use the customize option like you ALWAYS could. It has not changed. For the forms/UI side, yes, the customize option is gone, but you can if you must use VBA to add your own right click options to the built in right click menus. Albert Said:> I would also like to see a built in method to minimize the ribbon (I now modify the registry + sendkeys to accomplish this). Turns out we DO have this feature for access 2010, you can just go: CommandBars.ExecuteMso "MinimizeRibbon" So, even I am guilty of complaining about features that we have and I did not know about! So, to 100% hide ribbon and office button on startup we can go: DoCmd.ShowToolbar "Ribbon", acToolbarNo The above works in 2007 also. Now, in 2010, to minimize the ribbon we can go: CommandBars.ExecuteMso "MinimizeRibbon" And, as mentioned, for 2010 we can also activate a particular tab on the ribbon. This is nice so if you tab into a particular control (or sub form), you can then have the ribbon change what active tab group is being displayed. This is a very nice change to the ribbon. So, already, we see some good movement on VBA support for the ribbon….

Also, the functionality I'm talking about certainly exists in Access 97, which I checked before my last post. I'm almost 100% sure it also exists in 2003, but I just don't have a copy close on hand, at the moment. I will try and check shortly.

I'm interested in discussing the primary point of John's article. Access developers are in an increasingly difficult position professionally, to say the least. With each new project I start, I worry "Can I, should I, and should my client count on this technology?", primarily because Microsoft does not promote Access as an applications development platform. I'm always suprised when I learn there will be a new version released. In the 15 years I've been modeling and developing apps using Access I've watched it slide from the foxpro-killer to an Office 'information workers' toy. While I can ignore the fluff,wizards, macros and templates, I can't accept how SUPPORT from Microsoft steadily shrinks - from training to documentation to business benefits. Today's MSDN, Partner Program & certifications, MAPS required "assessments" and Training "compentencies" all exclude Access/VBA. New products like Azure, Silverlight - no mention of Access. Sharepoint and browser UIs? I'm skeptical. As a lowly Access developer, I haven't the clout to get a PR copy of Access 2010. So if it is Microsoft's position that Access/VBA developers are not really "developers", what are we?

I have to agree with the previous posting. I am often wondering where developers like us 'fit in' within the greater plan of things? Promises - excitement - optimistic anticipation - disheartened. Garry

Albert, I have checked in Access 2003 re adding custom right-click actions to the built-in toolbars for the database window/code window, etc. You used to do it by right-clicking the toolbar in the Access application (rather than the IDE toolbar). From the Access application toolbar, you could select 'Customize...' and also add Custom commands to the built-in toolbars (or your own toolbars). This could include calling a user-defined VBA function. This would also allow adding new right-click functionality to the code designer windows in the VBA IDE. Of course, since the ribbon replaced the Access application toolbar, this ability to add right-click actions to the database window/IDE has now gone. So, to be clear again, this HAS BEEN REMOVED from Access 2007, as I originally stated.

CyrusB stated

"Albert, which ever way you may try and sugar-coat it, not every change is for the better. You seem to embrace everything that comes forth from MS without question and proclaim it as the gospel! Not sure if that is a requirement of being an 'MVP'. Probably." This is absolutely not true. One of the sayings I've heard over the years is that "MVPs are the harshest critics and staunchest defenders." I've hardly used Access 2007 and I'm still around. Larry Linson is a lot harsher in his criticisms of some of the newest features and yet he has still been reawarded. Indeed MVPs generally get very irritated when described as "evangalists."

"MVPs are the harshest critics and staunchest defenders." - I have certainly found the last part true. If MVPs get irritated when described as evangalists, perhaps they should ask themselves why. Just curious, do you feel that the MVP who has been commenting here represents a good example of independence?