That’s due to the generated code that translates from the resource files to the code itself. Essentially, the GUI is set up in the resource files and then mapped to each class via the compiler at build time. It’s on the list to be taken care of at some point as it makes it hard to work with.
COpenPluginDlg is making a new window that’s essentially a list view, populating it with files in the current directory. Essentially, it’s implementing a basic file manager. It’s working as it was designed to but the design is very much in question. If we were to use CFileDialog instead, we could scrap the majority of the class and simply have it pass the file name (may be OFN instead, not sure) to the file pointer (whatever that happens to be, I don’t see it in the class that’s in question) after the user selects the file. At least, that’s the idea on the surface. It’ll probably make more sense after we get all of the GUI code where it belongs. Of course, the GUI code details don’t make sense to me yet. I’m mostly an algorithms person 😛
For reference, here’s the issue I set up for it: https://github.com/Walrus-Tech/MWEdit/issues/31
And which header files are the MFC GUI classes in? Microsoft’s API reference doesn’t mention anything about that.
And no hurry on the tool-chain! I’m still working on basic cleanup clean up tasks 🙂
And been talking things over with other folks and the general consensus is that Meson is probably worth trying so I’ll add it to the list!
