Have you ever had a form on which data-aware controls did not have any items in the DataSource combo box? Tom Cummings, a good friend (and co-worker) and I recently came across this problem and all of the obvious answers to solve it didn’t work. Well, last night, Tom got fed up and finally figured out what we were missing. Let me describe the scenario a little detail.
A form contains numerous data-aware controls. These controls need to point to a DataSource located in a Data Module. As expected, the form uses the DataModule. Everything up to this point looks fine. Unfortunately, every DataSource combo box does not see anything within the DataModule. The DataModule is open at design-time. Hmm. Weird. Another interesting fact is that typing in a valid, fully qualified target for the DataSource property works! Running the application works as expected as well. Sound weird? Ready for the solution?
Close the form
Add the unit name to the Project’s .dpr file! (e.g. MyForm in ‘MyForm.pas’)
Open the form
Simple, eh?
Normally, when you add a new form to a project, the reference is automatically put in the .dpr file. But if an existing form is referenced, you need to add the reference in the uses clause.
Update (3/25/2004): I thought of a better way to do this early this morning. The better way of adding an existing form to a project is to use “Add file to project” icon or menu item. This will add the reference automatically for you.
Kudos to Tom Cummings for figuring this frustrating situation out!
The Need For Speed vs. The Need For A Clean Design
Lately, it seems, I’ve had a case of coder’s block, not exactly know how to start writing a specific piece of code. I understand what needs to happen, yet, I’m hesitant to start. My brain is trying to refactor code that I haven’t even written yet. In addition, there are too many options to choose from. Since deadline pressures won’t wait for the ultimate architecture or design, I start coding prematurely. As a consultant, the last thing I want to do is to leave a maintenance nightmare for the next person.
So I reluctantly start to code. My fingers pound at the keyboard producing a working chunk of code. Write. Compile. Test. Debug. Many iterations later, I have written a non-optimal partially complete solution. More coding ensues. I start noticing similarities with code I just wrote. I start to copy an existing section of code, but instinctively, my gut screams at me “Don’t do it! Refactor!”.
At this point, I have two choices. The “just get it done” mentality wants to finish the code, without refactoring. On the other hand, the “perfectionist” mentality wants a cleaner design by either refactoring the existing code or rewriting everything. Depending on the situation, each option might be valid, depending on the specific circumstances.
However taking either of the two choices to an extreme is not the way to write software. I may look like a hero in the short term if I choose to just bang the code out. But when the next person comes in to either fix bugs or enhance the system, they will likely look at the code and wonder what the heck I was thinking. In sharp contrast, if I choose to refactor to the nth degree until I have achieved some level of perfection, I will likely miss my deadlines. Maintenance programmers, however, will love to work on the code I wrote.
Balancing the need for speed and the need for a clean design is not trivial. It is a task that must be learned with hard work, trial and error, lots of mistakes and experience. This learning process can be sped up by reading books/articles/papers written by gurus, having a mentor comment on your code or by pair programming with somebody who has plenty of experience.
In an ideal world, refactoring until the perfect solution is discovered would be the way to write software. Until that time comes, learn to write software that balances between the extremes.