MWEdit

[DeVaultSetter]

Doesn’t look like the labels, types, relationships, milestones etc. are all out of bounds – no permissions to close an issue either.
Sounds good. 🙂
Link over the module with file_open, and shall take a look. 🙂

[Spastic Hamburger]

Will look at the settings! What’s the point of having team members if they can’t actually work on the project, after all?

Should be these files:
https://github.com/Walrus-Tech/MWEdit/blob/dev/project/OpenPluginDlg.h
https://github.com/Walrus-Tech/MWEdit/blob/dev/project/OpenPluginDlg.cpp

It searches in the same directory the program is in, which is far from ideal

Edit:

It extends CDialog instead of CFileDialog: https://learn.microsoft.com/en-us/cpp/mfc/reference/cfiledialog-class?view=msvc-170

So we’ll need to rewrite the class. Probably best to just forgo the custom class and simply apply the filters? Would be much cleaner. It’ll change down the road as the GUI toolkit is changed to support other systems, though. There’s also a note about upgrading from older versions of Windows. Would it be better to wait until we do the swap or should we try and fix things up first? Going to be difficult either way as I’m not a GUI person 😛

• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.

[DeVaultSetter]

Cdialog looks as if it can do the job at least – haven’t got the toolchain setup for as yet. Doesn’t look as if it is invoked anywhere. Should be in the module which manages the click events for menus and/or buttons – has this always been the case?
The dialog is supposed to open when ID_SETACTIVE is clicked – hmmm this is a CListCtrl – e.g.
https://stackoverflow.com/questions/1462895/how-to-detect-a-clistctrl-selection-change
Try something like the following at this line:
m_FileList.ShowWindow(SW_SHOW);

• This reply was modified 2 months ago by DeVaultSetter.

[Spastic Hamburger]

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!

• This reply was modified 2 months ago by Spastic Hamburger.

[Spastic Hamburger]

Working on the build script now. Slow going as I need to add all of the source files to the list. Once I’ve gotten the basics down, I’ll want some testing done in VS to see if things work before merging it into master and letting the CI do its thing since it’s hard to test things right now on Linux. It’ll be easier for me to test things once everything is set up properly for me to use MinGW. But, right now, I’m mostly doing things blind. Hopefully I’ll have something for you in a few days, depending on how long it takes to figure everything out and to add all the source files.

I’m going to start with Meson so you’ll want to grab the Windows installation 🙂

• This reply was modified 2 months ago by Spastic Hamburger.

[Spastic Hamburger]

Okay, all of the source files have been added to the build script. Next, I need to add in the commands for the Windows resource compiler (will toss it in a system conditional at some point; may do that later after I get the basic script working). Then I need to add in the rest of the files to the bundle command to copy over all of the files necessary for the program to properly run. Finally, I’ll need to go through the VS project file to see if I need to set any other settings.

Once things are confirmed to work, I can look at adding Meson support to the CI script.

Okay, got the basics done. I think. Here’s the pull request: https://github.com/Walrus-Tech/MWEdit/pull/32

Please test it! Including the install command. If it works, we can go ahead and remove the other VS project files. It’ll also help with future organization and a lot of other things 🙂

Default build type is debug so you may want to set it to release on meson setup using meson setup --buildtype release if you don’t to see the built-in debug messages 😛 All up to you!

Edit:

Missed a directory on the install command. Will fix that tomorrow but you can go ahead and test the building, at least. 🙂

• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.

[DeVaultSetter]

Sorry, there’s too much on this hard disk (including old versions of VS etc). The move away from VS is understandable though, will get Meson loaded on the HP once the move downstairs is complete. 🙂

[Spastic Hamburger]

No problem! Whenever you get to it! I’ll move on to other tasks in the meantime that don’t require the build script and won’t conflict 🙂

It’ll still require VS to build (at least for now; VS should be optional long term in favor of letting you build using a variety of compilers) but Meson does make management a whole lot simpler. Instead of having build recipes for each compiler, needing to modify all of them whenever we change something project related, we can just edit the build script. When running it, it’ll spit out a recipe for whatever system we’re using and then run the recipe. It also lets us manage configuration. It works similarly to how we used CMake in the past. 🙂

• This reply was modified 2 months ago by Spastic Hamburger.
• This reply was modified 2 months ago by Spastic Hamburger.

[Spastic Hamburger]

So, I’m trying to work on some of the includes this morning but having a little bit of trouble. Some of the symbols don’t come up in a search result and aren’t in defined in the project, even though they are used. So far, these are the problem ones:
CObjType and PQSORT_CMPFUNC. I’m sure there are others but those are the ones that I’ve found first. The first one looks like it’s from the MFC due to the naming convention but it doesn’t appear in an Internet search. The second one, I haven’t the foggiest idea where it would be from. Any ideas? I may open a new issue so that we can start logging the unknown symbols.

Edit:

Got a new task item up: https://github.com/Walrus-Tech/MWEdit/issues/33. I’ll be adding symbols to it as I find them and we can use it to track everything down.

• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.

[DeVaultSetter]

Not sure, CObjType might be a reference to CObj ?? records. From the WB readme:

(COBJ) Constructible Object — Skyrim and later

Which doesn’t make sense unless it had a previous alias. Is it possible to determine what’s using it?
MWSE references COBJmacros and GCOBJ
PQSORT is used in Daggerfall of all places, courtesy of Dave. 🙂

[Spastic Hamburger]

This is in Common so they’re not game support. All of the game support is in the esm directory. Ah, I’ve got it: it’s a leftover file that isn’t actually used. It doesn’t show up anywhere else. Will remove it now. It’ll break the Meson build file so I’ll go ahead and update the pull request.

Out of interest, here’s the grep result:

$ grep --recursive --line-number ObjArray
Common/Contain/ObjArray.h:7: * Defines the template class TObjArray which defines a class to hold an
Common/Contain/ObjArray.h:21: * Begin Class TObjArray Definition
Common/Contain/ObjArray.h:27:template <class CObjType> class TObjArray {
Common/Contain/ObjArray.h:39:	TObjArray(const int MaxSize = 0, const int GrowSize = -1);
Common/Contain/ObjArray.h:40:	virtual ~TObjArray() {
Common/Contain/ObjArray.h:190: * Class TObjArray Constructor - TObjArray (MaxSize);
Common/Contain/ObjArray.h:196:template <class CObjType> TObjArray<CObjType>::TObjArray(const int MaxSize, const int GrowSize) :
Common/Contain/ObjArray.h:198:	//DEFINE_FUNCTION("TObjArray::TObjArray()");
Common/Contain/ObjArray.h:203: * Template TObjArray Method - void Destroy (void);
Common/Contain/ObjArray.h:207:void TObjArray<CObjType>::Destroy() {
Common/Contain/ObjArray.h:208:	//DEFINE_FUNCTION("TObjArray::Destroy()");
Common/Contain/ObjArray.h:214: * Class TObjArray Method - CObjType* AddNew (void);
Common/Contain/ObjArray.h:220:CObjType *TObjArray<CObjType>::AddNew() {
Common/Contain/ObjArray.h:231: * Class TObjArray Method - void DeleteElement (pString);
Common/Contain/ObjArray.h:237:void TObjArray<CObjType>::DeleteElement(CObjType *pObject) {
Common/Contain/ObjArray.h:251: * Class TObjArray Method - void DeleteElement (Index);
Common/Contain/ObjArray.h:257:void TObjArray<CObjType>::DeleteElement(const int Index) {
Common/Contain/ObjArray.h:258:	DEFINE_FUNCTION("TObjArray::DeleteElement()");
Common/Contain/ObjArray.h:275: * Template TObjArray Method - void DeleteElements_Priv (void);
Common/Contain/ObjArray.h:281:void TObjArray<CObjType>::DeleteElements_Priv() {
Common/Contain/ObjArray.h:282:	DEFINE_FUNCTION("TObjArray::DeleteElements_Priv()");
Common/Contain/ObjArray.h:298: * Template TObjArray Method - void SetMaxElements (MaxSize);
Common/Contain/ObjArray.h:304:void TObjArray<CObjType>::SetMaxElements(const int MaxSize) {
Common/Contain/ObjArray.h:305:	//DEFINE_FUNCTION("TObjArray::SetMaxElements()");
Common/Contain/ObjArray.cpp:7: * Contains test procedures for the TObjArray template.
Common/Contain/ObjArray.cpp:20:DEFINE_FILE("ObjArray.cpp");
Common/Contain/ObjArray.cpp:28:TObjArray<long> m_LongArray;
Common/Contain/ObjArray.cpp:29:TObjArray<fixedstring> m_StringArray;
grep: .git/index: binary file matches
meson.build:9:              'Common/Contain/ObjArray.cpp',
$ grep --recursive --line-number objarray
Common/Contain/ObjArray.cpp:12:#include "objarray.h"

There are likely others but the build errors will help us track them down!

Edit:

Okay, pull request has been updated with those files removed 🙂

It’s also part of the previous task item of removing as much of Common as we can 🙂

Still unsure about PQSORT_CMPFUNC. It’s used in Common/dl_base.h and Common/dl_base.cpp so we definitely need to figure out where that’s coming from. It’s definitely not defined in the project per the grep result. Maybe it’s from an obscure Windows file?

$ git grep --recursive --line-number PQSORT_CMPFUNC
Common/Contain/PtrArray.h:45:   PQSORT_CMPFUNC m_pCmpFunc; /* Pointer to a user supplied compare function */
Common/Contain/PtrArray.h:89:   int FindFastFunc(PQSORT_CMPFUNC pCompareFunc, void *pElement2);
Common/Contain/PtrArray.h:91:   int FindBSearch(PQSORT_CMPFUNC_ORIG pCompareFunc, void *pElement2);
Common/Contain/PtrArray.h:152:  void SetCompareFunc(PQSORT_CMPFUNC pFunction) {
Common/Contain/PtrArray.h:526:int TPtrArray<TArrayPtr>::FindFastFunc(PQSORT_CMPFUNC pCompareFunc, void *pElement2) {
Common/Contain/PtrArray.h:610:int TPtrArray<TArrayPtr>::FindBSearch(PQSORT_CMPFUNC_ORIG pCompareFunc, void *pElement) {
Common/Contain/temarray.h:44:   PQSORT_CMPFUNC m_pCmpFunc; /* Pointer to a user supplied compare function */
Common/Contain/temarray.h:117:  void SetCompareFunc(PQSORT_CMPFUNC pFunction) {
Common/dl_base.cpp:28:PQSORT_CMPFUNC l_QSortCmpFunc = NULL;
Common/dl_base.cpp:135:           PQSORT_CMPFUNC pCmpFunc,
Common/dl_base.h:265:typedef int (_cdecl *PQSORT_CMPFUNC)(const void *pElem1,
Common/dl_base.h:268:typedef int (_cdecl *PQSORT_CMPFUNC_ORIG)(const void *pElem1, const void *pElem2);
Common/dl_base.h:423:           PQSORT_CMPFUNC pCmpFunc,
Common/dl_base.h:444:extern PQSORT_CMPFUNC l_QSortCmpFunc;

It could potentially be the function pointer in dl_base. I’m not well versed on them, though, so I can’t tell if it’s defining a type with PQSORT_CMPFUNC as the name or using it. Comparing it to the new qsort implementation, that’s what it looks like it’s doing. qsort is used in PtrArray, which is used extensively in the esm directory. From the search, qsort is really only used in PtrArray so we may be able to move it over there to help with organization.

Looks like we’ve got that mystery solved, at least 🙂

• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.
• This reply was modified 1 month, 3 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

Common/conapp.h and Common/conapp.cpp can be removed as the CConsoleApp isn’t used anywhere in the project. Unless, that is, we decide to split Common/ out into a separate library. At the very least, I can remove it from the build script.

Okay, PR updated for when you’re able to review it 🙂

• This reply was modified 1 month, 2 weeks ago by Spastic Hamburger.

[Spastic Hamburger]

I’ve started making notes to the Dead Code issue regarding unused files. Feel free to add to it as you find them! Some of the latest additions do break the build script due to name clashes so I’ll get it updated soon so you may want to hold off on testing it until I report back 🙂

[Spastic Hamburger]

Okay, build script has been updated again. I’ll keep updating it as I find things or things that come up during testing but it’s once again ready for a whirl 🙂

[Spastic Hamburger]

And updated again to fix some file names that I had mistyped. Once we get the build script tested, it’ll allow us to do more with restructuring the project 🙂

[Spastic Hamburger]

I’ll be pushing up a new PR in the next day or so for removing legacy code. This will need a brief review before merge just to make sure it all looks good. 🙂

Just to note: it’ll need to be merged before additional edits can be made on account of how extensive the changes are and I don’t like dealing with merge conflicts if I can help it.

Once merged, I’ll start fixing the include paths in the headers and source files so that they’re more explicit. Once that’s done, I’ll merge it into the PR for the build script in preparation for testing that and (hopefully) removing the old VS files and adding Meson support to the CI (assuming I can figure that bit out). Once testing is done on the includes and build script, I can merge it all in to dev so that we can start making even larger changes. The build script, once working, is really going to help streamline everything 🙂

Along the way, I’m expecting some hiccups as we figure out all the correct settings since release engineering isn’t exactly my specialty. I sort of just stumble through it 😛

• This reply was modified 1 month, 1 week ago by Spastic Hamburger.

[Spastic Hamburger]

Okay, got the pull request up for the removal of legacy systems: https://github.com/Walrus-Tech/MWEdit/pull/34

Also took the liberty to modernize the syntax of the conditional compilation statements. I kept the checks for Windows as those will be needed for Linux support anyways and they’ll help provide a note to check those blocks (not all blocks are noted, though) to make sure they’re cross-platform compliant.

As for syntax style, I prefer #if MACRO and #ifndef MACRO over #ifdef MACRO and #if !MACRO but can certainly change #ifndef MACRO to #if !MACRO if the consensus is that it looks cleaner 🙂

Once that’s reviewed, I can merge it and get to work fixing up the include paths 🙂

• This reply was modified 1 month, 1 week ago by Spastic Hamburger.

[Spastic Hamburger]

Merged that in this morning and started on the include paths. 🙂

Ultimately, the pragmas will need investigating to see if they’re needed. Some disable warnings, which can likely be removed. It would be better to fix the issues in those cases instead of suppressing the problems

[Spastic Hamburger]

Okay, I updated the Meson PR with the updates to the include paths. Should be ready for testing now if you want to give it a whirl. 🙂

[Spastic Hamburger]

Hit a bit of a snag while updating the build scripts. Now I’m getting this error in the Meson branch while the main branch builds without issue:

[1/199] "cl" "-IMWEdit.exe.p" "-I." "-I.." "/MD" "/nologo" "/showIncludes" "/utf-8" "/Zc:__cplusplus" "/W4" "/EHsc" "/std:c++20" "/permissive-" "/O2" "/Gw" "/FdMWEdit.exe.p\Common_File_CfgFile.cpp.pdb" /FoMWEdit.exe.p/Common_File_CfgFile.cpp.obj "/c" ../Common/File/CfgFile.cpp
FAILED: [code=2] MWEdit.exe.p/Common_File_CfgFile.cpp.obj 
"cl" "-IMWEdit.exe.p" "-I." "-I.." "/MD" "/nologo" "/showIncludes" "/utf-8" "/Zc:__cplusplus" "/W4" "/EHsc" "/std:c++20" "/permissive-" "/O2" "/Gw" "/FdMWEdit.exe.p\Common_File_CfgFile.cpp.pdb" /FoMWEdit.exe.p/Common_File_CfgFile.cpp.obj "/c" ../Common/File/CfgFile.cpp
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\ATLMFC\include\afx.h(24): fatal error C1189: #error:  Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]

Any ideas what that error means and how to fix it? Also, why is it complaining now but didn’t before?

You can see the changes in the PR

I’m sure I’m missing something from the Meson script but not sure what

The other warnings you’ll see in the log have been on the list for months 🙂

So it looks like it’s a setting in the project files that needs to be set in the Meson script somehow, which explains why it’s coming up now.

Not sure how to set it in Meson, though. Can’t find much about it. May take it to their GitHub page tomorrow

Another question: what triggers it? Is it something that can simply be fixed in the code or is it inherent in the MFC stuff?

• This reply was modified 3 weeks, 2 days ago by Spastic Hamburger.
• This reply was modified 3 weeks, 2 days ago by Spastic Hamburger.
• This reply was modified 3 weeks, 2 days ago by Spastic Hamburger.
• This reply was modified 3 weeks, 2 days ago by Spastic Hamburger.

[Author]

Posts