Navigation:  Articles > Apr-1999 >

We'll All Hang Together

Previous pageReturn to chapter overviewNext page

Peter Vogel          
This month, we have an interesting group of articles that all end up tying into each other. These different articles reflect some of the difficult problems that developers face when creating applications and the very creative solutions that they develop. In this issue, we look at buying pre-packaged components vs. building your own tools, creating customizable tools for the developer and user, and how to handle a variety of user interface (UI) design issues.
Russell Sinclair is back this issue with a review of EZ Report Manager from Database Creations, Inc. EZ Report Manager provides developers with a snap-in component that allows users to manage their own reports from a single interface. Two new Smart Access contributors, Tom Heisler and Dennis Hollenbeck, have contributed an article about their own home-grown report manager that duplicates some of the functionality of EZ Report Manager. Should you buy EZ Report Manager or be satisfied with Tom and Dennis's utility, which you can get for free? Well, while EZ Report Manager does cost more, it also offers functionality that Tom and Dennis's utility does not. EZ Report Manager also comes with support from Database Creations. On the other hand, Tom and Dennis's routine does some things that EZ Report Manager doesn't do, either.
This isn't an unusual situation. As an Access developer, you always have a choice between buying that nifty packaged, supported solution or building your own tool. By the time you figure in the cost of your own time, it's always cheaper to have bought the tool from a third-party vendor. Tom and Dennis's utility takes that benefit to the extreme by being free. On the other hand, if you build your own tool, you get something that works exactly the way you want. Then again, the freeware tool gives you a head start on building your own utility.
Which brings me to Helen Feddema's article. Helen has another add-in for us this month: a snap-in menu manager that provides users with a single UI for accessing all of the components of your application. The add-in not only lets the developer set up a menuing system quickly and easily but also allows the end-user to customize the menu after the application is delivered.
Helen's article on creating a reusable UI leads me to Jeff Ruffner's article on using combo boxes . In the November 1998 issue (see "An Access Nightmare"), we informed you of the bug in Access that crippled the Access combo box wizard. We also provided a number of solutions to the problem. Jeff points out that, even with the bug taken care of, there are a number of user interface issues that crop up when you use combo boxes to select records. Jeff provides solutions to those problems and shows how to build a powerful UI using combo boxes. In fact, UI issues crop up in Russell's review of EZ Report Manager.
Which brings me to my article on creating excellent user interfaces in Access. In this month's issue, I outline the issues surrounding UI design and share a process that I've been using with Access to create successful UIs.
This relationship between the different things that developers do is something that we're all learning to live with. Working with Access means understanding a wealth of topics: UI design, database design, SQL, coding, and -- most importantly -- deciding on what's the best use of your time when choosing between building, buying, and re-using components.
Given all the relationships among these articles, I wanted to present them to you in one package. However, this has meant that "Access Answers" and the next installment of David Irvine's series on creating Access applications had to be pushed to next month. In the meantime, this month's issue will provide you with solutions to some tough, but related, problems.


See all the Editorials   or ALL THE ONLINE ARTICLES