...
It was time to revisit John's changes. As usual, one thing led to about five others.
An all-source ClarionTest
A while back I took the radical step of converting ClarionTest from an APP file to an all-source project. I wasn't entirely sure at the time why I was doing it. In part it was a wild impulse to get my hands on the source code in a way not possible as long as it remained in an APP.
...
| Note |
|---|
Don't for a minute think that whatever I'm describing in the following text is the "final" version of ClarionTest. If anything, ClarionTest has been, is and will be in a state of evolution. There are compromises and failures in the current code. When I notice them I'll comment on them, and try give some reason for my choices. And I'll come back to the code periodically and complain about the crap I wrote last time. To paraphrase Anil Dash, writing code is all about trying to suck less. That doesn't mean I'm not ever happy with my code - I frequently sit back and look at something I've written with a great deal of satisfaction. But I know that just because it looks good now doesn't mean it will look equally good down the road. |
Starting over (again and again)
After commenting out all of the existing code and many of the data declarations, I had a bare bones, non-working app. So what were my requirements?
- Be able to load up a test DLL
- Remember the last test DLL loaded
- Mark the individual tests that should be run, or run all
- Display a summary of how many tests have failed and how many have passed
- Option to display only the failed tests
- Fix resizing so the last position/size is remembered
An accept loop
For the last couple of years I've been consulting on a very large Legacy system. And while Legacy is painful to work with, there is one thing I really do appreciate about it: there's an actual Accept loop in the generated code. I sometimes think it was a mistake for ABC to bury that little bit of Clarion brilliance in the WindowManager.Ask method:
...
Maybe it's nostalgia, and maybe I'll regret not using WindowManager for ClarionTest, but for now I'm going to go with a regular old Accept loop and see where it takes me. If that means coming up with my own WindowManager replacement, I think I'm up for that.
Resizing
For no particularly good reason I decided to tackle window resizing first. The first step was to find a way to remember the last window size and position.Here I did go with an ABC option: INIClass.
...
I wouldn't be the first person to write my own resizer class, but again I can live with these limitations for now.
Down the wrong rabbit hole
I had bit of a detour early on. In reviewing the original code I saw that there was a call to read the list of test DLLs from the directory. First there was a queue declaration:
...
Moral: Don't spend time on code that isn't needed! Although as noted it was probably time those classes made their way into DCL.
Loading up a test DLL
One line of code lets the user look up a DLL with FileDialog:
...
The extra ADD at the top half of the loop is to handle test groups, e.g.:
Directory monitoring
With most of the core functionality in place, I still needed to re-implement directory monitoring which uses the DCL_System_Runtime_DirectoryWatcher class. The original class was written by Alan Telford (building on work by Jim Kane) and is described in Clarion Magazine article Waiting For Files With Clarion Threads. I've made a few minor changes, including moving the suggested event trapping code into a TakeEvent() method which you place in the Accept loop. Then you just need to derive the DoTask method which will be triggered any time a file in the monitored directory changes.
...
Also I'm not too impressed with the code I'm using to manage the on-screen list of test procedures. I need to add icons and some more sophisticated marking code, and I can see that becoming a mess in a hurry.
Still work to be done
There's always still work to be done. Besides monitoring for DLL changes only, I need to find some way of presenting summary information and showing only, say, failed tests. The UI is pretty ugly, so if you have some suggestions for how it can be improved please pass them along. Oh, and not all the buttons work yet. Some of that may have to wait until next week.
...