Nice examples there Glenn, start for you!
And thanks for assisting me in this long thread!
One remark though :
Keep your UI code clean.
Now you may think why on on earth would I do that, Delphi is known for RAD development; drop a few components on the form, attach a few event handlers to it and it works! Yes this is true, but this will work only with very small projects.
I will tell you a story from my own personal experience.
I started up my own company with my day work buddy in '95.
We needed a program that could make invoices. I made the database and it's fronted in ms access. We used that interface for about 5 years. As our company growed, we hired some people to do the dirty work

Soon it became clear that the access frontend was lacking some features and it also became slow. I suggested to rewrite the frontend in Delphi. As I didn't have the time to do this, we asked my buddy's brother (a COBOL programmer with Delphi experience) to do the job. And he did a fantastic job, the program did everything we wanted! As our ms access database became bigger in size, it began to crash (we had 5 simultaneous users working at that time). After numerous data corruptions I was fed up with access, I decided we needed a new db infrastructure. Since we didn't have the $$$ to buy ms SQL, there was that nice open source alternative called MySQL. We asked my buddy's brother to port the program to MySQL (which wasn't very difficult because we used ADO components in the program, only a few queries needed to be rewritten due to differences between access and MySQL) and everything went smooth again. Over the years we hired more and more employees (we have 10 in total now) and the due to changes in our business, some parts of the program were no longer needed and other parts needed to change. Due to a high workload, my buddy's brother didn't have much time to work on the program, and that's when I decided to take over his task. And this is where my nightmare begins. Imagine an application with more than 40 different forms (each having their own unit). The problem that I have today, if I want to change a part of the program, let's say one form, I spend a few days trying to figure out what each event was doing/ following the business logic. for example, on that particular form, there is a 'Save' button. the business logic is written in the eventhandler of that button. problem is, that this procedure is about 3 pages long, dealing with 10+ queries and interacts with UI elements on the form. I spend for about a week refactoring the form's code, the unit has now half the code size, but the business logic is still in the event handlers. In a second phase I will need to create a separate class that deals with the business logic (queries and calculations) so I can isolate the presentation layer (= User Interface) from the Bussiness Layer. Why is this so important?
- Unit tests, I can test my bussiness logic without any problem
- What if tommorow I want to have the UI as a web page? If things are isolated, I can keep the bussiness logic and I only need to write a new presentation layer.
This is my point that I made at the top of this thread: My TThread implementation may seem like overkill, but it is one single class containing all the logic.
Something about myself:
I dont have a degree in informatics. I learned everything I know from books and self-learning. I still have a day job (Telecom), where I am a full time delphi programmer at this moment, but more and more customers are asking for .NET skills. This means I also need to work on some C# projects. Luckily I have some collegues that are very skilled in that area, and they learned me how to use code patterns. (look here for more info :
I am applying the same principles to my delphi projects and they do save me a lot of time
I you guys are still reading this, then I hope it wasn't a boring read (and I need to level up up my english writing skills (it's not my native language
![[spin] [spin] [spin]](/data/assets/smilies/spin.gif)
))
Now I need a drink!
Cheers,
/Daddy
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!