Forum Replies Created
-
Messed up the include order for several files. I’ll fix it when I go back through to add the correct headers for the Windows macros.
All of this is necessary work even if it’s tedious and not at all exciting
Still need to get an issue open regarding visual styles. Shouldn’t be hard to implement and it’ll be a nice upgrade until we switch GUI toolkits. Just been buried under tracking down all of these symbols
Haven’t given much thought to TES3Gecko either for similar reasons (or even browsed the TES4Gecko code) but were still a long ways off from even having MWEdit ready for that sort of thing
Thanks! Will try that if adding just what we need doesn’t do the trick 🙂
There are also some comments suggesting that the
longtypes may in fact be intended asshortintegers so we’ll definitely want to do an investigation to determine what they should be. Yep,std::atolwould do the trick for 64-bit integers. There’s no corresponding function for 16-bit integers so we may want to see if we can set the control to a limiter if we do in fact need 16-bit integers after the investigation just to make sure we don’t get an integer overflow or out of range bug. The other option would be to first convert them to a 32-bit integer and then check to see if they are out of range for a 16-bit one. If so, we set it to the max or min allowed for the type. The limiter would be cleaner in that case, though.Edit:
snprintf()incommon/dl_str.his almost identical tostd::snprintf()incstdiosave for the fact that the former usesTCHAR *instead ofchar *. We may be able to swap it out forswprintf()incwcharwithout issue sinceTCHARis just a type-def forwchar_t. Other changes may be doable as well but that is a 1-for-1 swap down the road.Edit 2:
Also found this doc which could be useful: https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
Will start adding the headers for those types as I go and will go back through later and add it to the ones I missed at some point. It’s a shame a lot of this information is hard to track down.
Ugh…those includes in
commonmay be an issue. I’m trying to avoid using WinSock entirely as MWEdit doesn’t use any kind of network code and that would cause unneeded bloat. Can be added if needed, though, if things can’t be whittled down enough.Unless I’m mistaken, shouldn’t WinSock 2 be used after the basic Windows header so it overrides the old version? Of course, as we know, most OS-specific code is arcane to me as I rarely work on code that needs to interface directly with the underlying system.
Common will be rewritten eventually. The large integer union looks like an artifact from the days where 64-bit numbers were a novelty and can probably be replaced with
std::uint64_torstd::int64_t. As for the other stuff, that’ll need some additional investigation.Trying to get the Windows code working properly is beginning to get a little discouraging. 🙁
Edit:
Just opened a task item to fix the loss of precision in the UI code. We have stuff like this:
pEnchantData->MagMax = (short)(std::atoi(Buffer));
Here’s the struct for it:typedef struct { short EffectID; byte SkillID; byte AttributeID; long RangeType; long Area; long Duration; long MagMin; long MagMax; } enchanteffect_t;Essentially, it’s converting the string first to a 32-bit integer, then casting it as a 16-bit integer, and finally storing it in a 64-bit integer. This sort of thing occurs frequently in the code. That could cause some issues. Ideally, we’d convert the string directly to the correct type so that all data is properly preserved. We’ll want to investigate things to determine the correct integer types and change the code accordingly.
Yeah, I’m not sure what the XML parser is for at the moment. Even in the other projects, I didn’t see anything that used it. From what I could tell, CSV was the only file parser that was used in the extra file support but I haven’t finished going through all of the code in detail yet (I’m currently on the undo stack support).
What does OpenMW use XML for? I must have missed that
Made some compatibility changes:
I swapped out a non-portable standard library extension with functions in the standard library:if (!(/*__iscsym(pUndo->GetChar())*/std::isalnum(pUndo->GetChar()) || (pUndo->GetChar() == '_'))) { break; }The commented function is what was there before. It was an extension to
cctypeso I removed it in favor of the combination that exists on all platforms. Minor change but I figured, “Why the hell not? I’m adding the include anyways”. 🙂Thanks. Will make a note of adding the control style commands 🙂
I haven’t been including
windows.hso we’ll see what happens with the Windows integer types (MSDN didn’t specify that I had to include that file for their type-defs). Was never a fan of how Microsoft made things more complicated than needed but we’ll get it sorted out. 🙂Unfortunately, without that flag, it exposed a known bug in the Windows API where it tries to use WinSock 1 even though it’s unneeded where MFC needs version 2 and refused to build. Release had no issues so it’s something on Microsoft’s end with the
_DEBUGflag and disabling everything extra and manually adding only the stuff we use was the only way to fix it (I hope, we’ll find out once I finish adding the headers and try to build it). Here are the details. It’s a bit of a mess. If it gets too frustrating, I may fast track ripping out the Windows API but I hope to do that later once the code quality has improved more.Where do we need to call
InitCommonControlsEx?Thanks, I’ll work on getting together the control categories in use 🙂
Looks like MinGW supports them in resource files. Not sure about standalone ones but referencing them in the resource file with
#include "winuser.h" // required for RT_MANIFEST constant CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "application.manifest"should be fine. Not sure which method I prefer but it looks like it’ll work regardless for cross-compiling. Not sure if we’ll want anything else in the manifest. Maybe the runtime version since we’re using the newest? On Linux, that’s handled by the package manager settings file
Still need to research
InitCommonControlsEx(const INITCOMMONCONTROLSEX *picce)and figure out how that works
