time for another status report:
As mentioned the last time, I extracted the device-handling code of RandFill into a subproject that generates a DLL, but which is still not fully functional.
The reason for this is the intertwined structure of the program; although I tried to keep the different parts isolated, I obviously wasn’t disciplined enough and so the code became a bit more tangled over the years than I expected.
Another area where I noticed this was the GUI code that I’ve now begun to migrate from pure Win32-API calls to Qt. Using Qt widgets and its signal/slot feature makes a lot of the code paths simpler, but there’s still work ahead of me.
Additionally, I switched to Unicode and CMake as my new build system.
The result of all this is that at the moment, much of the code is commented out, so that I could focus on one area instead of being buried under compiler and linker errors that might stem from the switch to Unicode, or because I was using a DLL now, or the use of Qt, or creating a 64-bit program, or relying on a new build system, or…
That means I’ve currently got a nice looking shell, but which doesn’t differ too much from the current look and does actually nothing — but hey, every journey begins with a single step.
So the next targets (in no particular order) are:
- Get rid of the rest of Win32-GUI code and replace it with Qt.
- Complete the switch to Unicode.
- Bring the DLL for the device-handling in a working state.
- Continue to modularize and isolate the different areas of code.
- Clean-up the CMakeLists.txt and add a way to make a complete and installable target.
And after all that, RandFill will have the same functionality it had already years ago and I can finally concentrate on new features and bug-fixes from my ToDo list — what progress…