MWEdit

[Spastic Hamburger]

Fixed a bug in ui/class_dlg.h: for some reason, it had an improper include-guard that came in the original project import. Will be in the next upload 🙂

[Spastic Hamburger]

Random remarks:

It may be possible to set up the multi-game support as external plugins so that the whole program doesn’t need an update when individual game components are updated by dynamically loading the libraries using LoadLibrary() on Windows and dlopen() on *nix (at least on Mac and Linux, would need to check for the BSDs). This can be further combined with std::filesystem::exists() to ensure that support for the specific game is installed first.

To improve readability, we’ll want to wrap that code in a project-scope loader so we don’t need conditional compilation everywhere

Edit:

Looks like BSD is the same: https://man.freebsd.org/cgi/man.cgi?dlopen

Never messed with that stuff before so it’ll definitely take some research to figure out how to set it up.

[Spastic Hamburger]

Just finished correcting all of the paths. All of those commits have been uploaded. I haven’t yet merged things into master, though. I may also look at setting up the CI to create debug builds on the dev branch first, as well. Anyways, there may be stuff to fix once the CI runs on it (quite possibly the resource files as they choked before when I was messing with the paths). Will do all of that another day. My neck needs a break 🙂

[Spastic Hamburger]

So setting up different tasks for different branches using GitHub Actions is rather ugly. There’s no clean way to do it in one workflow file as you can only specify the branches on which the file runs, not the tasks. There are two options: set up the jobs section as an if-statement using Git references or have multiple workflow files. I’m leaning towards the latter option as it’s cleaner even if it is another thing to add to the repository. Yuck.

Give me a bit and I’ll copy the file, change the branch, and add the debug flag to the build command. Wish the if-statement version wasn’t so ugly. I hate duplication *sigh*

[Spastic Hamburger]

Test_TemplateArray() in common/container/tem_array is bad. It’s got lines like this: CreatePointer(pTestInt, (long)(12345678l));. That’s incorrect as CreatePointer takes a pointer object and a type, not a number:

#define CreatePointer(pObject, Type) { \
		(pObject) = new Type; \
		if ((pObject) == NULL) { \
			SystemLog.Printf(stderr, _T("Failed to allocate %u bytes!"), sizeof(Type)); \
			throw (_T("Out of Memory!")); \
		} }

I’ll comment those lines out for now as I’m not entirely sure what they’re supposed to accomplish (working through the errors for the DEBUG portions of the code which we haven’t done yet).

Edit:

Going to take another day or so. As usual, I mistyped some of the paths so I’m fixing them as the CI complains. I’m also fixing some MSVC and C++20 compatibilities that exist with the types and preprocessor stuff that wasn’t caught earlier due to the debug builds not being enabled

[DeVaultSetter]

What was the intentions of the bracketed lvalue? The Type passed through doesn’t make much sense either, think he wanted something like make-unique, it came just a few years too late!
Sounds good. 🙂

[Spastic Hamburger]

Yet another thing to add to the investigation list! Yeah, we may want to swap out that macro with something more modern. There have been a lot of updates to pointer support in recent years 🙂

The debug settings are complaining about missing libraries such as winsock when release does not so I’m going ahead and removing the PCH support to help us sort through everything. Needs to be done anyways and it’ll help us diagnose what’s needed where. This is going to take some more time, it looks like, to untangle the Windows library stuff. This means I’m going to have to remove the mwedit/std_afx.h include from all of the files, which will take another week or so. *sigh* It’s probably as good a time as any.

Er never mind. I just realized that’ll break MFC support. Reverting now….

Will need to keep at it for a while. The MFC headers need to be added to the GUI files before we can remove PCH support. I hope I’m not breaking too much here…. I should probably check the commit log before I do anything more to make sure release would still function

Okay, now we’re back to it complaining about winsock even though we’re not using network code. Weird. Will set it aside for now and take a look another day. Don’t know why turning on debug builds meant trying to use winsock. Here’s the current build log if you want to take a looksie: https://github.com/Walrus-Tech/MWEdit/actions/runs/21025793442/job/60449870823

Did some looking at it appears that winsock is brought in regardless and not all of the MFC includes have been updated to use winsock2. Weird. May or may not be easy to fix.

[Spastic Hamburger]

Fixed the WinSock2 errors. Had to add WIN32_LEAN_AND_MEAN to the definitions in the build script. It didn’t work in the code but that may been due to include order (which is still being worked on). The build script will need some cleaning up at some point, more than likely. It’s already on the tracker 🙂

Still working through getting the debug build working.

Edit:

We’re getting closer. There’s at least one error buried somewhere in the 25,000-line build log. Could do a search for it but, even then, it’ll be hard to spot among all of the warning noise.

Looks like it’s complaining about mwedit/script_options.h now when it was fine before. I added the necessary Windows includes but still no luck. It’s complaining about syntax errors but I’m not seeing them. It could be something with the macros. Any ideas? I may merge it into master and see what happens on a release build as it didn’t happen before debug builds were turned on and I started messing with the file paths. I’ll start by doing a direct comparison though that may fail due to the file name changes.

Edit 2:

I was afraid of that. The diff fails between master and dev due to the changes to the file names. May do a test commit with release instead of debug on the dev branch or I may create a new branch so I don’t mess up master… :/

Test branch using Release config comes up with different errors: https://github.com/deathssoul/MWEdit/actions/runs/21091754553/job/60663963134

Weird. Going to start trying to sort through them. Not sure what’s going on here but it looks like we’re dealing with some Windows breakage. Could also be due to WIN32_LEAN_AND_MEAN. Whelp. Will add all of the missing includes it’s complaining about on Release and will go from there and hopefully Debug will get fixed in the meantime.

Maybe this is a good opportunity to go back to adding all of the missing includes?

Working on adding them. Previously, the project was set up in VS to implicitly add the stdafx.h file to each instead of explicitly so several files were missing it. Changing the project structure somehow triggered it crapping out without the explicit includes for some reason. Maybe due to how VS works, not sure. Normally, the compiler would crap out regardless. In any case, I’m going through and adding the missing Windows includes that are necessary for building on Release. Hopefully that’ll also fix Debug but we’ll revisit that once I get these issues fixed. We’ll be moving away from a stdafx.h file in favor of more explicit definitions so that we have a better handle on what’s going on and for better portability.

[Spastic Hamburger]

Now that I’ve thought about it, I’m tired of making tiny commits for each file and then waiting several minutes for them to build. It also adds stress to my storage device, which isn’t good. So I’m going to go back to fixing up the includes now that we know that they are the problem. In the process, I’ll probably look at removing stdafx as well. Any objections?

[DeVaultSetter]

That last link takes all of 30 seconds to load over here – it’s huge!
There’s MFC in there which adds extra layers. With stdafx it boils down to saving time and grunt with pre-compiled headers using either that or pch.h?
Yes, ensure the includes are working first, otherwise extend the sojourn in MWEdit no man’s land. 🙂

[Spastic Hamburger]

Yeah, it’s so big GitHub won’t load it. The MWEdit code is pretty crusty. 😛

In reality, most of those are memory alignment warnings in the Windows API. I think GCC ignores warnings in system includes by default (not sure, it’s been a while since I used it) and there may be a switch for VS to turn on.

The MFC stuff will be removed down the road when we make it system agnostic so explicitly defining them where they’re needed will also help with the porting 🙂

Sounds good. We can worry about the PCH stuff later on and focus on getting things working for now. GCC uses a different method than VS for PCH: you can simply have it compile the header files and then it’ll give them preference over the text-based headers without changing anything in the code.

[Spastic Hamburger]

Okay, started updating the includes for the UI stuff, which is where most of the missing stuff is. Some of them are a bit obscure but I’ve been adding each one individually. We’ve got things like this:

#include <afx.h>
#include <afxdd_.h>
#include <afxwin.h>
#include <atlstr.h>

Not exactly pretty and commenting them to explain what they’re for may be necessary as the names are a bit obscure.

Additionally, I’ve reached out to devakm regarding TES4Gecko. Since MWEdit will ultimately have a lot of feature overlap, I’ve asked them about the possibility of sharing information to reduce the need to come up with the same algorithms.

[Spastic Hamburger]

Okay, so we have permission to use TES4Gecko as inspiration for the algorithms with the only stipulation that we provide credit to Gecko for what we borrow. 🙂

[DeVaultSetter]

Great! 🙂
It’s Java based, and AndalayBay released a conversion to Morrowind back in 2014, converting it to C# using WPF with MVVM. She may still have the project files somewhere. The old Bethsoft release threads for Tes4Gecko and the conversion can be viewed in this edited html set.
To edit the Tes4Gecko code in VS 2022/2026 we’ll probably want OpenJDK, there are extensions for VS Code as well. 🙂

[Spastic Hamburger]

I’ll start by asking devakm about the original code. All that’s available publicly is the packaged JAR file.

AndalayBay still has some of the project files as they are currently working on a straight C# rewrite. No idea if they abandoned the previous attempts or not, though. As I recall, the Morrowind version wasn’t that far along but may still have something useful in it if we’re able to get permission. I’ll need to give that aspect some thought due to stuff in the past. In the meantime, I’ll talk to devakm 🙂

We may not need to actually run the code but time will tell. Don’t remember much about the tool-chain since I last worked with Java in 2010 (I switched to C++ as soon as I learned it) but I do remember that javac compiles the files and you run them with java. Should be the same in OpenJDK.

[Spastic Hamburger]

It looks like most of the ClassWizard notations in the files can be removed as it was just a marker for the GUI tool instead of something being done in the tool-chain? Not entirely sure but if so, that’ll help clean up the headers to be more readable.

Additionally, the custom string implementation in common/string/sstring.h isn’t used much and CString is used more predominantly so we may be able to mark it for removal. Ultimately, the plan is to replace the nonstandard string types with std::string but that will take some time to retool the code to use the functions in the C++ standard

Still need to update the tasks list from this thread more but I’d rather code than go through the thread and do that mindless work…. 😛

Adding the missing includes to the GUI files is coming along nicely and the code is becoming much more readable, as well 🙂

Also asked devakm about the TES4Gecko code 🙂

[Spastic Hamburger]

And devakm just uploaded the code!

[Spastic Hamburger]

ui/cust_rich_edit.cc and its header will need to be reviewed at some point. There are some symbols that I was unable to properly track down, such as GetSel(), so I’m not entirely sure if I’ve got the correct header files. There may be a few that we don’t need

Another symbol in other files that is hard to track down is POSITION. The difficulty comes from the fact that it’s such a generic symbol name. A search only turns up SetWindowPosition() instead.

Additionally, I’m thinking about including tag files for the project to help with editors highlighting the symbols. It’d be nice to set that up on the CI end but I’m not sure how to do that just yet. Will add it to the research list.

And I’m going to try to add a manifest file to the project to see if I can get the GUI looking more modern as per this page once the debug build is working.

[DeVaultSetter]

There’s this message in the standard edit control, EM_GetSel or for the RichEd, EM_EXGETSEL. Is there only a decl for GetSel() and no def?
Sounds good about the manifest, use mt.exe, or to “save” on extra files there’s also #pragma comment(linker,"\"/manifestdependency ... which would go nicely in one of the main headers e.g stdafx.h. Using the Windows common controls will restrict the compilation to running just Windows of course.

[Spastic Hamburger]

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.

[Author]

Posts