Why VBA still makes sense

Albert: I'm affraid that msoBarPopup is a part of MS Office which is NOT REDISTRIBUTABLE, ie. may not be present on the end user's machine. I can remember that I could not create a setup with ODE97 when I had references to the "mso" library.

Albert:

I'd love if Access Developer Team could listen what we're asking for. If you go back to past you'll see many posts asking to make classic menus & database window available. Are classic menus & database window back in Access (A2010)? There are too many posts on other issues, eg. deployment tool. Do we have professional deployment tool in Access? I do believe that Access team is trying to do their best. But they are not doing what WE NEED, they do what they THINK WE NEED.

See other forums, too.

Vladimir :You don’t need to do that anymore. All that works just fine in the runtime now. I tested the above code before I posted it. So, that issue been long time fixed (likely due to our developer requests). So, I stand by that the code as posted works just fine with the 2007 runtime. I suppose you could use late binding for the command bars, but it not really needed and you can deploy *WITH* a reference to the office 12 object library and it is included.

Albert: Does that really mean that there must not be MS Office but MS Access Runtime on the end user's machine? It is very difficult to test with A2007 deployment tools since it doesn't handle references at all. I'll try to make some testing tomorrow.

Firstly, why does the Access Team choose NOT to engage with posters on their own blog? why leave it to a hapless MVP? Albert, MS implemented the Ribbon and dumped CommandBars in Access 2007 WITHOUT consultation with the wider body of developers. DAO is not comparable to the Ribbon. There is no Ribbon library for Access, just a few methods to manipulate at a high-level. The only way to use custom ribbons without having to build at run-time is to use the USysRibbon table paradigm, and there are ZERO native Access tools to build or test the required XML. What parses in XML Notepad breaks in Access, and debugging is a nightmare. The CommandBar object model allowed easy creation of custom commandbars in VBA and VERY IMPORTANTLY through the user-interface. The article on popup menubars you cite uses macros. Any serious Access app does NOT use macros.

> Access Runtime on the end user's machine? Actually, it does not matter if office is installed or not. The office 12 object library is installed (included) with the 2007 runtime. So, it really does not matter either way. If you already have office 12 (2007) installed (but without access), then again no problem and no need to install the office library. Installing 2007 runtime will thus not install office 12 object lib. If you don’t have the office 12 object library, then the 2007 runtime will install the office 12 object library for you. So, either way, you good to go here.

Ditto what Tony says. I hope his concerns have been addressed in Access 2010.

> MS implemented the Ribbon and dumped CommandBars in Access 2007 WITHOUT consultation with the wider body of developers. Actually, I don’t think it nearly that simple. Office adopted the ribbon, and all product groups had to follow suite. The ribbon is here to stay, and it is a done deal (there not much of a choice here). There not going to be a change in this regards no more so then users wanting a DOS version of FoxPro after the windows version came out. We moved on, and you not going to see a DOS version of access either. I so remember the old timers saying what a joke the mouse is and REAL people ONLY use the command line prompt. Those command prompt people are still saying that no one is listening to them! Some don't like this change, but it just the way it is. >DAO is not comparable to the Ribbon. I disagree. DAO been what 18+ years as a staple food for access, but it still an external library. So, there not a native VBA support for it but it sure as the heck been used for a long time. >What parses in XML Notepad breaks in Access, and debugging is a nightmare. Have you tried turning on the option called “Show add-in user Interface errors?” It gives a rather decent error message. It also gives you the line number where the error is. Often people in the newsgroups ask me where the heck an I getting those error messages for THEIR sample xml posted. So, this option will help you. >The article on popup menubars you cite uses macros

correct. You not too scared to use a wizard are you? I was simply pointing out that it still VERY easy to create right click pop up menus. So on the one hand you talking about things being too hard and THEN talking about ONLY wanting an easy to use GUI mouse. Then now macros are too easy for developers now and you can’t use them? Or are they too hard now? (exactly which way you going with this???). I not suggesting you use macros for you whole application but they are handy for creating right menus even in VBA applications. If your cutting your teeth as a developer then why are you trying to use the GUI to create custom menus anyway? A good 50% or MORE of the examples for menu bar code (even on MSDN) uses VBA code. So, if you really are that hard core coder then why you talking about lack of an GUI here? Keep in mind that access 2010 does have a ribbon customer built in. You can add groups, buttons etc and even hide buttons. (all with the GUI). It certainly more of a power user tool then it is a xml developer tool. I not sure anymore if you just a power user since you state you only want to use mouse for creating your menus, but then state you must use VBA?. You hanging on both sides of this fence. To be really fair here, serious developers find xml for the ribbon a dream! I don’t write ribbons XML anymore. I made a few and I been copy + pasting them ever since. This copy practice of mine has become so common that I now am forgetting most of my xml ribbon skills. All you have to do here is build a few ribbons and you should be good for the next few years just raiding them for new applications. Ribbons are ZILLLION times better to move parts and bits between applications. Have you ever tried to move ONE button from an menu bar between applications? The pain of a developer trying to move ONE menu button between applications is horrible! I don’t buy the case that the old menu system is easier then the new system for experienced developers to build menu (or ribbons). In fact, it just the opposite.

Tony: "Any serious Access app does NOT use macros." Two problems with that statement. Now, granted, there was a good reason for saying macros didn't work, but it would not be forthright to note that AutoKeys and AutoExecs were used, and macros made sense when we just want a quick'n'dirty job. 1) It should be noted that macro interface has been changed and in fact is closer to VBA but much faster. Want to loop over records? Type "F", tab, name of the table, tab, the condition to filter the records, tab two more times and the loop's all set up! Want to requery? "Req" and tab, that's 3 keystroke less than VBA's "Me.Req" + tab. Close the windows? "C" and tab. Copy the macros to share with others? It's emitted as XML so anyone can pass it around. We also don't have to worry about remembering to clean up our code or use right variables; it's all done for us, and the whole point of Access is to... rapidly develop the applications. For further consideration, take look at the older blog post linking a .NET developer & Sharepoint MVP's take on Access 2010. 2) If you can't find the idea of using magnetized needle and steady hand absurd then there's nothing we can say. http://xkcd.com/378/ When does it end? That's a serious question.

Albert: Just to be clear, I did not imply that I wanted my custom right-click actions to be transferred to a customer application. 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 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. But carrying on like a glazed-eyed zealot and patronizing everyone else who dares express frustration, garners no respect for you at all. Some stuff in 2007 was really good, some of it was a raw deal. 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 personally find the actual MS staff like Clint and others quite decent people. Naturally, I would expect them to downplay the negatives, since that is their job and MS culture dictates they have to behave in that way. But for someone who claims to be 'independent', I find your behavior appalling. Cmon man, lift your game, you're better than that.

Tony:

"The article on popup menubars you cite uses macros. Any serious Access app does NOT use macros."

You are right. I never use macros and I command my colleagues not to use them either. Our apps are "macroless".

Anyway I will give it a try.

Vladimir my friend: Where is the A2010 Runtime in the Technical Preview released? none at all? (So how can we test/ try this to real life distribution/Situation?) Thanks my Friend

Best Regards ERwin

Can somebody advise me, which technology can we use to make the same reports in Visual Studio Express (VB.NET or C#.NET) as in Access?

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 Also see:

blogs.msdn.com/.../demo-of-access-2010-room-bookings-database.aspx

blogs.msdn.com/.../demo-of-access-2010-room-bookings-database.aspx

CyrusB: I just trying to bring some balance here. I don’t normally spend much time here, but I do think some of the things said here left un-challenged leaves the wrong impression. It just unfair for people to state there nothing new for developers. If you look at my web demo posted above you can see the new the nav control, the new data macros, the picture control, the new web control are all GREAT features that you can use in your VBA applications. I think it is important to point out that we do see a nice new set of features and I would be most unfair of me to not counter some people stating there is nothing new. I TOTALLY accept complaints about the ribbon. It certainly by far the most controversial feature in office. I also however understand that it is not the access team that made the decision about the ribbon either. They don’t own that ribbon code and it not under their control. Access is part of office (this is good because it gets $$ development dollars, but it is bad because it must be part of office). Access being married to office has often helped, but also often frustrated long time developers like me. In a sense People are barking at the wrong house (the access team) about the ribbon. I do respect that people STILL should voice their complaints. If one is looking for a REAL change in regards to the menus vs ribbons, then you have to hang out in some place like the ribbonX groups and voice feedback to the team(s) that own the ribbon system. I taken time to understand that the ribbon thing was really never the access teams decision. And, it not practical to maintain two sets of learning materials + code examples for menus and ribbons at the same time. We been dealt this deck of cards and we HAVE to live with it. This is simply how it is. It not a case of me liking it or not. It is NOT a case of me being a fan boy. I have to now make an effort to see if I really can work with the ribbon (I don’t have choice here). On the other hand, I can and do live just fine with the ribbon. In fact, I grown to like it quite a bit. So, I can make it work for me..and I then move on to the next dragon to slay so to speak. It is important to take time to understand WHAT they can change and what they own. For example very little if anything been done with JET for year after year. Most requests for changes to JET fell on deaf ears. Guess what? The access team now owns JET. It only been since access 2007 that the access team owned this JET database thing. (1 release). The changes for 2010 in regards to JET/ACE are HUGE. The access team knocked the ball out of park with regards to changes for ACE for 2010. So just like the big boys (Oracle, sql-server, MySql etc.) we now have table level procedures. I think this change to JET speaks volumes about the access team WHEN they have control of their code. When it their horse…they really do kick butt. What other desktop non server based data engine has table triggers and procedure code like ACE does now? There is not many! And, this trigger feature is great for desktop only applications.