Reply To: MWEdit
This could be a result of MFC updates over the years, where the old stuff was superseded by newer functions. Here’s a sample of what I’m looking at:
int CCustRichEdit::GetCurLineCharPos() {
long StartChar;
long EndChar;
int CharPos;
GetSel(StartChar, EndChar);
CharPos = StartChar - LineIndex(-1);
return CharPos;
}GetSel() isn’t defined in MWEdit so it’s probably coming from MFC somewhere.
Edit: Looks like it’s coming from the parent class after all: https://learn.microsoft.com/en-us/cpp/mfc/reference/cricheditctrl-class?view=msvc-170#getsel
So I just missed it. That mystery has been solved.
CMake is supposed to have support for .manifest files like it does for resource files so I’ll try adding the file to the target_sources command first. stdafx.h would be nice but it broke when I turned on WIN32_LEAN_AND_MEAN for some reason.
Failing CMake, we should be able to tell the CI to run the manifest embedding command. No idea how to use InitCommonControls() and its newer version (InitCommonControlsEx(const INITCOMMONCONTROLSEX *picce)) makes even less sense to me as they don’t provide examples but we’ll get there when we get there. Things may be different when we switch GUI toolkits but it doesn’t hurt to do the minor work needed to make the GUI look more pleasing in the time leading up to the GUI change 🙂
The way the CMake script is being set up, it only worries about the .rc and .manifest files on Windows and ignores them on other platforms so that won’t be an issue. The toolkit change will take care of the latter and we’ll need to come up with a solution for the former but we’ll get there!
I could put the manifest bundling in an MSVC check instead of a WIN32 check so that it only tried to bundle it when VS is being used. MinGW supports resource files, not sure about manifest files. Will need to check on that.