This is the second part of a three part series on the Access IDE. Part I can be found here and Part III here.
10. Colored Command Buttons
Call me a fashionista, but I’d love to have colored command buttons!
9. Collapsible Procedures
Would love to have a “+” next to each procedure header to collapse or expand it.
8. Copy Objects with Code
Wouldn’t it be great if when a button is copied from one form to another the code also got copied over? Currently we need to copy/paste the code. Macros attached to buttons already do this.
7. System Imports
Using Windows APIs is almost a given in everything I do, but having a System.Import functionality, (similar to Visual Studio), would go a long way.
6. Connections
Here’s another feature I’d like to borrow from VSS: a general connection object we can just set once in the project and use it through all of our code. I replicate the functionality using a module level connection object, but I’d like to see this implemented.
5. SQL Builder
One of the reasons I LOVE SQL Server Management Studio, (SSMS), is the wonderful intellisense when building SQL Statements. It makes it almost fool proof to pick the right tables and fields in your database when building long SQL Strings. Adding a SQL Builder that will automatically recognize both native and linked tables would be a real boon for productivity.
4. Native Support for SQL Server
Currently we need to use ADODB and SQLOLEDB to connect with SQL Server in our code, would be nice if there was native support for connections to SQL.
3. Silverlight Integration
The recent articles at the official Access blog on Silverlight Integration were a real eye opener for me, would love to see Silverlight better integrated into Access going forward.
2. Spell Checker
Who’s never misspelled a dialog box prompt? Point made.
And the #1 feature I wished I had in the Access IDE:
1. Create a new top level Office object model
I get why we need to use references to other office applications, but it would be nice to see a General IDE across all office Apps that can natively talk to each other. The current state is mostly due to having individual Microsoft programming teams for each office program. But what if Microsoft baked the references into all the Office IDEs, creating a top level office object above all of the existing office object models? We would get native intellisense that spanned the entire infrastructure, provide us with a universal object browser and who knows what other great benefits.
A move towards Macros?
The new macro editor in 2010 is a wonderful editor for both newbies and developers alike. I’m glad the Access team took the time and effort to revamp the interface, but I also hope it also means the next version of Access brings something new to the IDE and not a general move towards more Macros in the future.
So why not just use Visual Studio instead of the native Access IDE?
I see Microsoft adding more Office programming to Visual Studio with every release, so maybe this is the ultimate goal. What I love about this process is that it preservers the old IDE and would provide us an upgrade path to Visual Studio.
We need a new Renascence in the Access IDE
A lot of this wishlist is borrowed from the Visual Studio environment. What I’m asking the Access developers at Microsoft to do is not so much provide us an IDE similar to .Net but to leapfrog them altogether with a totally revamped IDE. Don’t just replicate what they have, improve and innovate over what Visual Studio is doing, in other words, it’s time for an Access IDE Renascence!
What new features would you like to see in the Access IDE for Access 2014? Leave a comment below and you will be entered into a contest for a Amazon $25 gift card when I finish taking comments for the third article in this series.
re 5: A SQL Builder would be great, but I would settle for modifying the existing SQL View with the following: Syntax highlighting, the ability to open queries by default in SQL View, and being able to change the font.
Zev
You can get syntax highlighting now, take a look at item #1 at this post:
http://accessexperts.net/blog/2011/04/27/10-things-i-love-about-the-access-ide/
Thanks for commenting!
Juan
I don’t know if I would favor some native support for SQL Server, if that involved using the same programmers that developed the JET engine.
I don’t know if a move towards macro is a good thing or bad, I never use them myself, and anytime I take over a project that does, I try to delete the macro and utilize VBA instead, when I can.
I think Silverlight integration would be great, though I haven’t done anything with Silverlight as of yet, except I have just started “playing” with it.
I have to disagree with the comment about differrent SKU’s being the (or a) reason behind there being no top-level Office object. If an application is designed using this top-level object and the end-user’s system has a different version than the developer(s) (a problem that likely happens more often than not), then I imagine it would be much similar to having erroneous references as is the case for something written for 2007, but ran in 2010 or visa verse.
Thanks for your comment Robert!
Great comments.
Colored Command Buttons:
I’m wondering if you mean something other than Access 2010 currently offers? In 2010 (don’t know how much of this is 2007 or 2010) already allow much more flexibility in customizing the button and it’s not limited to just colors but also how the button would be presented (as a square, as a oval, as a rounded square, whatever, and whether it’d have glow or not, different hover color, etc). But since this is about IDE and not forms, I feel I’m missing something obvious?
SQL Builder
I’m tempted to want to go further and suggest that we have ability to embed SQL. I’m not sure if I want something like LINQ, embedded SQL or simply just heredoc string; if it means dispensing away with all those messy string handling we have to cope with, that’d be awesome. Sometimes I find myself writing for what I clumsily term “interface” to common SQL procedures so I can get a recordset but without cluttering code with SQL strings everywhere but make it easier to break & update my code when I change the requirement.
Native Support for SQL Server
I can’t speak to ADODB & SQLOLEDB, but I’m led to believe that any protocols we use with SQL Server is already “native”; at least that definitely is the case with ODBC. IOW, ODBC commands are sent to TDS stream directly as if it was a native SQL Server client library. I expect it to be the same case with ADO & ADO.NET. A better case, though, could be made that we need access to all functionality that SQL Server could support, of which there are some variances between various protocols.
Create a new top level Office object model
While that would be nice, I suspect the reason this doesn’t happen is because we have different SKUs of Office allowing different combinations so there’s no guarantee that one part of Office will be always available. This is why I think we have the current model of where we use Office reference for shared components (e.g. Ribbons & CommandBars and some stuff) but dedicated Object Libraries for each applications in the Office.
We need a new Renascence in the Access IDE
This, I definitely & totally agree. The my inner geek wishes that we could just use Visual Studio and therefore ride on their coattails as they introduce new features instead of splitting Access (VBA?) team’s budget over such features. That may not mesh too well with Access’ stated intent of being accessible to non-developers (who are basically our marketeers 😉 ). I may be also in the minority but I think Access going .NET is fairly overdue and believe it was and still would be the biggest benefactor to be .NETized. Oh, well.
Thanks Banana!
On Colors:
I love the transparent button effect, take a look at Luke’s post on “Enhance Command Buttons”:
http://www.fmsinc.com/tpapers/access/Forms/Access2007FormTips.html
On SQL Code:
Currently I jump to the front end, build my query using the QBE, (Query By Example), change to SQL view, copy, past into my code and finally format it. What a waste of time! Would love to have a way to build the SQL in the IDE and have it pasted nicely for me…dreaming I know…
Office Object:
I know what you mean, but 99% of the time the user is going to have the same office suite on the PC, can’t they just build it to auto-recognize the methods, objects and events I’m using in the code?
I wouldn’t mind going the .Net route, since it would force us all to learn it and apply to other projects as well, I’ve tried to pick it up but my clients won’t let me…http://accessexperts.net/blog/2010/11/30/why-i-cant-learn-net/
Thanks for posting!
Regarding points 4 and 6: I’ve been developing with SQL Server and use ADPs and CurrentProject.AccessConnection works fine for a native connection to SQL Server.
Thanks Greg,
ADPs are THE best way to connect with SQL Server. When I first started using them I found the initial login box not worthy, so I developed a technique that would sub it out for my own . I’d love to get your feedback on it.
I would like to see the ListBox control be updated to allow formatting and auto-column width like a DataSheet. I would also like to see the DataSheet get multi-select and a way to loop through the selected records like a ListBox control.
Great choices! Thanks Jack