The Win32 wizard generates one C++ file – GA.cpp for my genetic algorithm – to hold _tWinMain (yes, I started off with Unicode defined), initialisation code and CALLBACK handler. (Actually it also produces stdafx.cpp but this just pre-compiles a ton of widely used included headers.)
Add a bit of message processing and a few dialog boxes and this file quickly grows. So, I split out the dialog message handlers into GADialogs.cpp. Still the main file kept growing. But worse, it contained the code for what had become two distinct processes within the algorithm. These were broadly the general-purpose engine, or toolkit, itself and the specific problem that it was solving. Both needed the GUI to get and display data. In fact both were using the same window. I could foresee trouble.
I already had a GASystem class as a sort of Facade pattern for the toolkit, and a TSP class for the specific travelling salesman problem. Splitting the GUI between these two would give me a cleaner design but I somehow wanted both to be interface independent. I’m still toying with the idea of converting to MFC and maybe .NET; hell, even a command-line interface is a possibility.
The answer is pretty simple. Invent GAWin32 and TSPWin32 superclasses and shunt all the GA.cpp code into them. I’ve taken this a step further and had the TSP interface call CreateWindow (with its own RegisterClassEx) if GAWin32 doesn’t want it using the main application window. There’s quite a bit of faffing to ensure that only one of each (Singleton) class is instantiated and to clean up at the end.
That’s what I’m tackling now. It’s possible for the windows to get their knickers in a twist if I don’t shut ‘em in the right order – like ending up with no windows and a still running program. I also find that I can’t get focus to the main window. It’s something to do with the relationship between the two. I suspect WS_OVERLAPPEDWINDOW may be at issue.