Microsoft Access Team Blog

(In connection with Ribbon) I can't agree with the following:

"If you are just beginning, VBA is a great place to start."

I'm missing Ribbon object in VBA that's why I wouldn't recommend VBA as a "great place to start". VBA is the worst place to start with Ribbon.

VBA in access is a great way to manage the ribbon. Vladimir see my article that was posted on this blog a few months ago in which I provide some VBA to manage the ribbon

Simplifying Ribbon Modification at Runtime

http://blogs.msdn.com/access/archive/2009/04/27/simplifying-ribbon-modification-at-runtime.aspx

In the above I provide an VBA class that allows you with ease to enable, hide buttons or change pictures in the ribbon using VBA.

Also, for office (and access) 2010 we can now make any tab in the ribbon active using VBA (this feature was missing in access 2007). So there is new enhancements for the ribbon that are available from VBA.

Glad to hear that.  VBA is integral to my Access aps.  I'm excited about 2010 and the new features.  I was not about 2007.  

John's article is less than forthright:

1. Macros in Access are NOT written in VBA.

2. The talk of VBA is condescending and pitched at the power user level with talk of making "little buttons" etc...

3. The segue onto .NET is jarring, with the pitch now aimed at object-oriented coders, selling the virtues of strongly typed objects and security.  (This after Access security was dumped in Access 2007!)

4. No mention of the appalling implementation of the Ribbon object with zero native VBA methods for building or customisation, or for handling pop-up menus which still use the CommandBar object.

>Macros in Access are NOT written in VBA.

Yes, it good to point this out. It been a simple observation and fact for many years that access developers quickly learn that macros mean something different in access. So, sure, it is good of you to point out that Access macros are differnt (and in 2010, even more so with the new engine level table triggers!).

>Ribbon object with zero native VBA methods

I don’t understand the above problem? I been supporting and answering questions in the newsgroups for about 10+ years now, and in fact there’s not really any native VBA support for DAO reocrdsets, and yet we use DAO all the time in our code! We do this by having a reference set to the DAO object model.

The same goes for the ribbon, and it easy to work with the ribbon using VBA.

At the end of the day you can still use VBA to manipulate the command bar objects

>or for handling pop-up menus

There is new features for creating right click context menus on forms in 2007 without having to use the command or object at all. See this article:

http://office.microsoft.com/en-us/access/HA102825091033.aspx?pid=CH100621911033

So, you can still use VBA to create and manipulate those context menus, we also now have the addition of a new macro feature that allows the creation context menus also. (it not like this issue was not dealt with and it not like somehow VBA can't use the commandbars object..you are still free to do this)

>after Access security was dumped in Access 2007

That is a completely wrong and a totally false statement. User level security is completely supported if you use mdb files.  

On the other hand if it’s important for you to point out the difference between little details like macros being different for longtime access developer’s here, then I would expect you to give the same courtesy to everyone else here when you accidentally leave out BIG FACTS like you can use user level security in access 2007 with mdb files.

So Albert, are you saying that you can, in Access 2007, create a custom right click menu option, say for an object in the database window (navigation pane), that can execute arbitrary code?

I could do this in MS Access 97-2003 to do things like copy the name of a table by right-clicking a table in the database window and then selecting my new context menu option.  The new option would call code to copy the name of the selected object to the clipboard.  I also had other really handy stuff as well, like being able to generate a SELECT SQL or CREATE TABLE statement from the currently selected table.

I REALLY hope I have missed something, but I'm blowed if I could figure out how to do it in 2007.  

Albert,

I think the point Tony was making is that Access security was removed for the new file format, i.e. .accdb files. Old .mdb format is not being developed like the new .accdb format.

I have to say though that I think Access 2010 is brilliant. It took a long while to convince me that Access 2007 was good (apart from the lack of security), but on trying out Access 2010 it is clear that a huge effort has gone into it and the web stuff is really exciting (still no Access security for .accdb files run in non-web mode though). I'm actually posting this comment from inside Access 2010 via a web browser control whose control source is linked to a field in one of my tables.

How about putting a link to your video on this blog to demo a web database?

Alan

CyrusB: I bet Albert is not able to do it!

Vladimir my Friend: MS ACCESS 2007 is the worst release ever..hows that? The scenario: I have installed the A2k7-SP2 runtime to my client machine with pre-installed MSOffice 2k3, so far its fine.But when some of the apprentice installed MSOFFICE 2k7 it started to go crazy by running the long-setup wizard which means again..CONFLICT!..do you have a remedy on this situation my friend aside from using SAGEKEY? Thinstall is unusable on this situation (A2k7-only)..very sad!

Thanks

ERwin

>So Albert, are you saying that you can, in Access 2007, create a custom right click menu option, say for an object in the database window (navigation pane), that can execute arbitrary code?

I was talking about context menus that you build for your custom applications (for forms and reports). Since the old menu bar customizing is gone, then to build right click menus for your applications you can continue to use the commandbars object + VBA (that is what many people used). However, you can NOW ALSO now the NEW macro approach to create that right click custom context menu.

In your case, you are talking about the built in menus and those to my knowledge those menus NEVER EVER did travel with your applications you deploy to your customers. So, you talking about a very different issue.

I not tried to modify the built-in context menus with the commbars object.

So, to be clear here I was talking about the right click context menu(s) that you specify in the “other” tab of a form (or report). This is generally how custom context menus are created for customer applications.

When you use macros (or VBA, or in the past the menu customize feature), your result was a short cut menu that you would specify in the “other” tab of the form in design mode.

So, we were talking about context menus you develop for your customer applications.

Changing the built in ones as you are suggesting NEVER EVER did travel with the application. So the issue was in light of developing applications that you deploy to customers. I would strongly recommend that you don't mess with the customers built-in menus as they will change EVERY application on that customers desktop and that will get you in heaps of trouble real fast.

Albert: "...you can continue to use the commandbars object + VBA..."

Is it possible with Access 2007 Runtime without MS Office 2007 on a target machine? I think, it's a "mission impossible".

To me, creating menus via macros seems too much complicated, though I have not tried it, yet.

Erwin:

"MS ACCESS 2007 is the worst release ever":

True

Deployment & cross-version incompatibilities (bugs):

MS is not willing to create a professional developers' tool for deployment. It's always been a problem in Access. You can find more deployment issues & bugs in my "bug database": www.alis.cz/relax/download/access/Access2007_bugs.rar

See the following IDs: 11, 68, 70, 71, 82, 83, 85, 88, 90 (!!!).

More than a year ago we talked to people from MS CZ. They told us that one of the reasons not to develop a professional deployment tool was that they can't "cut down" other companies, like Sagekey. IMHO, it's not true. How could then MS develop it's own anti-virus SW, firewall, and many others?

Vladimir:

"How could then MS develop it's own anti-virus SW, firewall, and many others?"

That didn't make sense... I suppose one could write firewall and anti virus using VBA but... that's reinventing the wheels. Normally when we talk about deployment, we talk about a package, of which Access may be a part of. Sometime company doesn't give a hoot about security because they will have the network manage the security. Other companies may just want to use terminal server and demand VPN. All of those software will work just fine with Access and can be had off the shelf.

WRT the original topic:

Having had programmed in C#, I have to agree that VBA is so *much* convenient and straightforward. A task in VBA that takes few lines, or even better yet, zero lines because it's a property setting for an Access object, would requires about 10 objects and many lines to accomplish the same task! Yes, C# and other languages has more power and flexibility but it's not always needed, and we must not forget that Access can consume COM components, which also mean it can consume .NET components using COM interop or ActiveX (issues not withstanding) so we can get a 90% solution out of the package, and put on 10% when we actually need it. Even using a hybrid solution would still be faster & cheaper than if we had to do it everything in Visual Studio.

That said, I do really, really hope MS will consider updating VBA just a bit. It's been long since it had any new constructs. For one example, error handling are, IMHO, long in tooth, and I would be so glad to have a Try/Catch which provides for more intuitive & flexible error handling as well enforcing code clean up at all time. Another example would be to provide convenient keywords for incrementing & returning values (e.g. i++ & return i for example) or handling complex logic in a Select Case (break, return or fall through). I think those little improvements will go a long way should MS have no plan to eventually migrate to VSTO for the entire Office.

>Albert: "...you can continue to use the commandbars object + VBA..."

>Is it possible with Access 2007 Runtime without MS Office 2007 on a target machine? I think, it's a "mission impossible".

Oh, such a lightweight you are!

Sure you can use VBA in the 2007 runtime to make a right click menu. Try this code in a forms on-load event…

  Dim cb      As CommandBar

  Dim mybut   As CommandBarButton

  Dim strMenu As String

  strMenu = "MyShortMenuTest"

  On Error Resume Next

  Set cb = CommandBars.Add(strMenu, msoBarPopup, False)

  If Err.Number = 0 Then

     Set mybut = cb.Controls.Add(1)

     With mybut

        .Caption = "test new1"

        .OnAction = "=Msgbox('hello')"

     End With

  End If

  Me.ShortcutMenuBar = strMenu

Was the above so hard for you?  Note that I used =MsgBox(), but you could replace that with the name of a VBA function (note that the VBA function you specify here can even be a code function in the CURRENT form’s code module! ).

So, right click menus to call VBA are totally supported in the 2007 runtime, and using VBA to create a menubar/command bar on the fly is also supported.

>To me, creating menus via macros seems too much complicated, though I have not tried it, yet.

That is Bad answer! So you can’t spend a few minutes to use a new feature, it is likely too difficult (macors are too hard for you!). Yet your standing here asking for new features? How you do think this makes you look as a developer? Lets step things up here a notch.

Look: We all here love access and some of you are making us developers look like clowns before the access team and community.

I think we need to put forth a really good professional front to the access people here else they not going to take us very serious.

I will support ANY developer here who wants to make a unified front and make a good impression so that the access team will really listen to our requests.

I want YOU on my side when we band together (or gang up) to suggest and ask the access Team to give us needed features we want for our lovable access.

Lets make sure what we present here makes a great impression on the access team.

I don’t mind some people here not knowing about as many features in access as I do (I am a true expert on this product and I here to share my knowledge with you). I do mind when that lack of knowledge is used to make unfair criticisms. This makes all of us here look bad.

Lets make sure what we present here makes a great impression on the access team.  And you can bet I will join anyone in complaints about something in access, but lets make sure we have some corresponding professionaisi here else we not be taken serous.

Banana: I'm affraid you didn't get the point. :-/

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:

http://blogs.msdn.com/access/archive/2009/11/03/demo-of-access-2010-room-bookings-database.aspx#9916927

http://blogs.msdn.com/access/archive/2009/11/03/demo-of-access-2010-room-bookings-database.aspx#9916957

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.

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

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?