As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm wondering about some ideas which can improve process of designing solutions using Access and VBA programming language. Of course I'm not talking about best programming practices in general, but only these directly related to Access and VBA.
Everybody knows, that VBA has poor object-oriented programming support, there is no inheritance, polymorphism and so on. So how to ensure DRY and KISS at one time? There are some solutions how to implement common in other languages patterns and strategies in VBA, but frankly speaking, they are often overcomplicated. Which of those are worth to implement?
Before I start a new Access project (if any ;) ), I wish to gather collection of best practices, because from my experience I know that with VBA in Access (and with Access in itself) it's very challenging to avoid bad design concepts and to end with messy, unreadable and repeated multiple times code.
I'd like to add here some other questions and answers related in a way or another to the same issue. The pointers might lead to my own answer to these questions, but do not hesitate to browse other's answers!
MS Access as enterprise software
Best way to test an MS-Access application
Working with multiple programmers on MS-Access
Recommendations on using SQL server GUIDS from MS-Access
I must admit that one of the main constraints of Access is the limited object model. I was specifically annoyed by the lack of possibilities to add my own properties and methods to the Form object. I recently found an efficient turnaround to this problem by creating 2 extra objects:
the "AllMyForms" object,
which in fact maintain 2 object collections: one is the standard Access forms collection, the other one is a collection of all the instances of the "customForm" object. Both collections are indexed with the hwnd property of an opened form (or, to be more specific, the hwnd property of the instance of a form, allowing me to open multiple instances of the same form).
the "customForm" object,
which lists my custom properties and methods of a form's instance
In this way, I can refer to properties such as:
accessForms:referring to the standard properties and methods
AllMyForms.accessForm(hwnd).name
refers to the .name property of the access form through its .hwnd value
By the way, the following debug.print will then give me the same result:
? screen.ActiveForm.name
? AllMyForms.accessForm().name 'default value for hwnd is screen.activeForm.hwnd'
Custom forms:properties
AllMyForms.customForm(hwnd).selectClause
will refer to the SELECT clause used to create the underlying recordset of the form's instance
Custom forms:methods
The .agregate method, available for a customForm object, will calculate the sum/min/max/avg of a form "column" (ie sum of values for a control in a continuous form):
AllMyForms.customForm().agregate("lineAmount","sum")
Will give me the sum of all "lineAmount" values displayed on the current/active instance of a form.
The definitive source for best practices in Access programming is this book:
Access 2002 Desktop Developer's Handbook
http://www.amazon.com/Access-2002-Desktop-Developers-Handbook/dp/0782140092
You should get a copy if you're serious about programming in Access. These guys are the experts.
I realize the book seems dated, but all of the information in it still applies. I suppose it never got updated because this kind of development is a bit of a niche area. But Access has not changed all that much internally (it's one of the only remaining software development tools left that still uses what amounts to a dialect of VB6), and most of the information in the book is still good.
The companion book that focuses on Client/Server development is here:
Access 2002 Enterprise Developer's Handbook
http://www.amazon.com/Access-2002-Enterprise-Developers-Handbook/dp/0782140106
One thing i always had to do when I did Access programming was the use of a lot of hidden fields for binding reasons. I made sure that i made the field invisible and also changed the color of the field to foreground white and background red so that people knew this was a hidden field.
Another best practice I used was using modules for all of my shared code. Get into the habit of putting a lot of your reusable code in modules.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have to write a database in Access 2010 and i need to use VBA also (I have never used it). A thought that the times came to learn a little about VBA and VB. I would like to read through a VB tutorial also just to know a little bit about that too. But i found a lot of VB for example 6.0, 2005, 2008, 2010.
My question is: If I want to learn VBA in Access 2010 which VBA version should I study (link would be good), and which version of VB?
VBA and VB are not the same, particularly VB in the context of the .NET framework. If you want to be able to program within Access, then you need VBA, not VB. Get a book which covers Access VBA - if you don't like Banjoe's suggestion, there are plenty with fewer pages, and tons of material accessible via Google.
I've always found the WROX books to be fairly comprehensive and full of useful, real-world examples. For example: Access-2007-Programmers-Reference
In the beginning try to stick with bound forms/reports as much as possible. You can do a lot without VBA and once you start custom coding things it tends to snowball.
If you're new to database design make sure you read up on how to properly normalize your data. Designing your database properly will save you tons of time in the long run. See: here for one example.
I would suggest you are asking the wrong question. Access is a point-and-click development tool, not a programming language. So, what you need to learn is how to use Access to create applications. That means creating user interface objects interactively and then extending them with code.
However, one thing to keep in in mind is that A2010 has new powerful macros with branching and logic and error handling. These are quite robust because all the features of the new Access Web Databases (usable with Sharepoint using Access Services, and runnable in a web browser) are built on top of these macros.
So, I would suggest that you invest time in learning how to create web objects in addition to learning how to sprinkle in some VBA code to extend the behavior of your Access UI objects (and the VBA code won't run in a Web database, BTW).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I need to document a MS-Access application that was created, developed and maintained completely by a power-user over 10 years.
This is an interesting situation because what they want is a manual so that a future developer can come in without prior domain knowledge and make changes to the frontend or the backend in a timely manner.
There are a few questions on my mind for this little project:
What is a good manual design creating application? Microsoft Word doesn't quite cut it.
What kind of things would you, the developer, need to know in order to make changes to things like forms, reports, tables or other Access objects?
Anything else I missed? Any pitfalls?
You could start with generating some automatic code documentation using MZ-Tools add-in for VBA. The same add-in can help you clean unused variable declarations, generate line numbers, reorder procedures within a module, etc.
Documenting forms is more difficult. My proposal would be to keep a screen shot, alltogether with a .txt file obtained through the undocumented application.saveAstext method.
In my experience, Access and VB6- based programs are plagued by more code replication and technical debt than programs in mainstream languages. I'm not sure why. Maybe it's the nature of Access as a "prototype" or "toy" database (though it can be quite powerful when yielded correctly).
If I had to choose between expending time on documentation and expending time on reducing technical debt, for example by remodularizing, eliminating repeated code, splitting long functions, etc., I would choose the latter. The improvement to maintainability and readability would be greater.
I know this is closed for long, but I can't refrain adding my 2 cents:
In the case mentionned, I think the most usefull doc to produce is a FUNCTIONAL documentation (which should have existed before starting the development in an ideal world).
Second is within the code itself, and that includes the VBA but also the field descriptions which can be set in Access and SQL Server.
Third is a (or a set of) nice database diagram.
Once you have that, all the rest can be generated by the new developer using HIS favorite tools.
Speaking about tools, I particularly like and recommend:
MZ Tools: specially to easily find which routines call the one your looking at
Smart Indent: to properly indent code. Trying to read badly indented code makes me sick
SqlSpec: (not free) generates HTML doc of the database itself for most database engines
Have you tried the using the built in database documenter? It will print out all tables, indexes, forms, controls, each property of controls. Code, the sql used and just about any thing else. This results in huge, but just massive printouts. However, while it will kill a few trees in the process it sure is a great way to impress the boss.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Has using an acknowledged anti-pattern ever been proven to actually work in a certain specific case? Did you ever solve a problem or gain any kind of benefit in one of your projects by using an anti-pattern?
My understanding of the "anti-pattern" concept is that it encompasses solutions that have drawbacks that only reveal themselves over the long term. Indeed, the primary danger associated with a lot of them---like writing spaghetti code with loads of global variables and gotos every which way, or tossing exceptions into the black hole of an empty catch block---is that they're seductive because they provide an expedient solution to an immediate problem.
EDIT to add: Because of that, sometimes you do derive benefit from these anti-patterns. Sometimes your calculation that you're writing throwaway code that no one will touch again is dead wrong and you wind up with maintenance programmers slandering your heritage and sexual hygiene, but other times you're right and that crummy shell script that's held together with baling wire and spit does the job you intended it to do and is then blessedly forgotten, saving you the considerable time and effort of putting together something decent.
Anti-Patterns are still so widely around just because they solve a particular problem (while creating 10 new ones). Also known as workaround. But how do they say? Nothing lasts longer than a makeshift.
In fact I believe we'd all be jobless if things had been done right from the beginning.
The biggest problem that it has solved in my experience is launching a new application.
When the dev team has scoped the new application thouroughly, the timeline to implement the correct solution is usually too much for management to bear. Therefore, oftentimes, you code to meet the timeline, rather than "correctness" of the solution to get to the launch date, (but have others coding the "correct" solution for the next rev), making it essentially "throw-away" code.
One software anti-pattern is Softcoding, also defined at the daily WTF. Softcoding happens when programmers put material that "should be" inside code into external resources.
I'm working with software that some might say is suffering from softcoding. External files drive the software. Those external files are a micro-language: they must be compiled to XML before the software can use them. This micro-language has its own tools.
But softcoding is always in the mind of the beholder.
Having the material in a micro-language with its own parser has made my life easier. One data source can generate many different outputs: In addition to the version that the main program uses, I am able to extract information into HTML, .csv, and other formats that our customers want. Other programs can generate code in the micro-language, making automation easier.
In our case, softcoding has been a useful pattern, not an anti-pattern.
There is a reason for calling it a pattern rather than a law.
I would surmise that almost everyone has at least one example of a place in code where exactly the wrong thing was done, and it turned out better in the long term than the "right" thing would have.
And a far longer list of examples of anti-patterns causing trouble.
I have used magic pushbuttons a number of times, out of ignorance or laziness, and sometimes it actually worked out just fine, and it turned out that I did not need the extra abstraction of proper MVC.
Duff's Device utilizes the Loop-Switch Sequence (AKA For-Case Paradigm) anti-pattern.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
Duplicate:
Learning implementing design patterns for newbies
I have been a developer for years and have my way of developing and have always kept up with the latest techologies. I want to start using a design pattern in the hope it will improve my development speed but I need to find one to apply and I need to find a full open source sample that demonstrates it.
I use and have an application that uses LINQ to SQL and .net 3.5 I tried to apply the repository pattern but found the structure complex and having to hack my way through it.
Any advice for someone who wants to better their programming style?
Read blogs (RSS Feeds are prime). Read magazines. Read random MSDN entries. Write little trial applications. The only way to keep up is to discover it and practice it.
Patterns aren't really "tech" in the traditional sense. Using patterns means applying your specific knowledge of a domain to a problem keeping in mind the patterns which apply to that domain. They are useful to exactly the extent that you have a base of experience to put them in context.
The repository pattern, for example, is maybe not the best starting place for constructing a database architecture based on a pattern. Have you got a simpler pattern implemented such as Table Module or (in the specific case of data access) Active Record? If not then perhaps you should start there. These patterns focus on a fairly limited, basic way of organizing data and operations. Repository is more like a meta-pattern that then builds on top of these patterns, organizing a complex domain-data boundary into a simpler collection-like interface.
Two books that I would suggest reading are:
Refactoring: Improving the Design of Existing Code (ISBN: 0-201-48567-2)
and
Refactoring To Patterns (ISBN: 0-321-21335-1)
Both are great books that will help you, at a high level, understand the when's and why's to applying patterns to your code. In addition, they are great reference material for some of the most commonly used patterns out there.
To be clear, these books are by no means the "complete library" of design patterns.
My simple advice for bettering your programming style:
Pick a technology that you find productive and "fun" and keep with it to learn how to fully explore it's potential.
Don't try to learn all the new technologies all the time - just keep yourself oriented.
Seek advice and solutions where and when you actually need them - don't waste time learning solutions to problems you don't (yet) have.
Regarding design patterns... Well... I'll probably get shot for this, but I don't really like the idea of cramming them all into my head "just in case". They are really a cooking book of "good solutions" for common problems. My advice here is: Whenever you run into problems that you can't come up with an obvious/immediate solution for - use them as reference.
Learn from your mistakes (you'll make them).
Don't marry your code. Throw away and rewrite is an excellent way of bettering the style.
I would sincerely recommend dofactory.com
which also offers code examples in vb.net + c# for all the design patterns
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When you are learning a new language, what is there a particularly good/effective exercise to help get the hang of it? And why?
EDIT:
Preferably looking for things that are more complicated that 'Hello World'.
I usually do the following (in the order presented):
Print a pyramid with height provided by the user (checks basic I/O, conditionals and loops)
Write a class hierarchy with polymorphism etc... (checks OO concepts)
Convert decimals to roman numerals (checks enums and basic data structures)
Write a linkedlist implementation (checks memory allocation/deallocation)
Write clones of JUnit and JMock (checks refelction/metaprogramming)
Write a console based chat system (checks basic networking)
Modify (6) to support group chat via multicasting (checks advanced networking)
Write a GUI for (7) (checks GUI library)
After that its on to a real project...
other than hello world, I try to port one of the existing programs to the new languange. this will challenge me to learn some good old techniques in the new language and help me build a new library of classes or helpers..
Larry O'Brien had a great series of blogs titled '15 Exercises to know A programming Language' Part 1 Part 2 Part 3
See Larry's Blog for the details.
Part 1. Calculations
Write a program that takes as its first argument one of the words 'sum,' 'product,' 'mean,' or 'sqrt' and for further arguments a series of numbers. The program applies the appropriate function to the series.
Write a program that calculates a Haar wavelet on an array of numbers. .
Write a program that takes as its arguments a the name of a bitmapped image. Apply the Haar wavelet to the pixel values. Save the results to a file.
Using the outputs of the previous exercise file, write a GUI program that reconstitutes the original bitmap (N.B.: The Haar wavelet is lossless).
Write a GUI program that deals with bitmaps images
Part 2. Data Structures
Write a class (or module or what-have-you: please map OOP terminology into whatever paradigm appropriate) that only stores objects of the same type as the first object placed in it and raises an exception if a non-compatible type is added.
Using the language's idioms, implement a tree-based datastructure (splay, AVL, or red-black).
Create a new type that uses a custom comparator (i.e., overrides "Equals"). Place more of these objects than can fit in memory into the datastructure created above as well as into standard libraries, put more objects into it than can fit in memory. Compare performance of the standard libraries with your own implementation.
Implement an iterator for your datastructure. Consider multithreading issues.
Write a multithreaded application that uses your data structure, comparable types, and iterators to implement the type-specific storage functionality as described in Exercise 6. How do you deal with concurrent inserts and traversals?
Part 3. Libraries
Write a program that outputs the current date and time to a Web page as a reversed ISO 8601-formatted value (i.e.: "2006-06-16T13:15:30Z" becomes "Z03:51:31T61-60-6002"). Create an XML interface (either POX or WS-*) to the same.
Write a client-side program that can both scrape the above Web page and the XML return and redisplays the date in a different format.
Write a daemon program that monitors an email account. When a strongly-encoded email arrives that decrypts to a valid ISO 8601 time, the program sets the system time to that value.
Write a program that connects to your mail client, performs a statistical analysis of its contents (see A Plan for Spam ) and stores the results in a database.
Using previous Exercise, write a spam filter, including moving messages within your mail client
If you can do all these things in 2 languages, I'm sure google has a job for you
'hello world!'
I really do think this a good place to start. Its basic and only takes a few seconds but you make sure your compiler is running and you have everything in place. Once you have that done you can keep going. Add a variable, print to database, print to file. Make sure you know how to leave comments. This could all take a mater of 5 minutes. But its important stuff.
Connect to data somehow, whether it be a database, file or other...
Red-Black tree.
I usually don't do very well with it unless I have a "real" project to apply it to. Even made up ones get boring fast. In fact, I find it helpful to throw yourself in the middle of a bigger project and make small changes to something that already works.
YMMV
My equivalent of a hello world is to do the following:
Retrieve multiple inputs (ie, parms from command line, text boxes on a gui)
Manipulate that input (ie, do math on numbers and manipulate text)
On a gui use a list box.
read and write files.
I feel after doing the above I get a good feel for the language and a good introduction to the IDE and how easy (or really how difficult) it is to work with the language and the environment it runs in.
After that if I want to go further I will use the language in a real project that I need to do (probably a utility of some kind).
Personally I like to make a simple echo server and client to get the hang of network programming with that language.
Ray tracer.
I like to learn a new language by doing a "real" task (for "personal" use)
My first java program was a client for an online multiplayer game (that I then released into public domain)
My first vb.net program was a front-end for my digital video recorder
My first VHDL "program" was a 64x32 led array controller
Often I'll implement the k-means clustering algorithm.
Drag-and-drop image gallery.
When I was cutting my teeth on Win32 and MFC, this was one of my first projects. Pretty quickly I ported all my code into ActiveX controls. Then I rewrote the thing in Java. For kicks, I rewrote it again in pure Javascript. When I broke into .Net, I rewrote the thing again in C#. Last but not least, I used it as an exercise for learning Objective-C and UIKit.
Why? It's a visually appealing toy, for one thing. It's nice to get instant gratification from your code, I think, and working with images is one of the most gratifying things I can think of.
Console based Tetris
I like games for learning programming because the business rules are carefully delineated. The first three programs I write in a new language are Ro-Sham-Bo, Blackjack, and Video Poker.
Pick a task(s) that you already understand. That way you limit the amount of "new stuff" you need to assimilate.
I think, for me, learning by porting existing code (for example, from another platform) is always a challenge and fun. just simple demos, boardgames, etc.
Mandelbrot set.