|
Notes |
|
|
(0021014)
|
|
Zalewa
|
|
2019-08-30 16:39
|
|
|
|
|
(0021015)
|
|
Blzut3
|
|
2019-09-02 07:36
|
|
|
While that fix is probably just fine, is there a chance that we should be adding some flag to compile Doomseeker in Unicode mode? |
|
|
|
(0021016)
|
|
Zalewa
|
2019-09-02 16:18
(edited on: 2019-09-02 16:19) |
|
From what I see the `A` variant of LoadLibrary() can also work if the string is converted to a local 8-bit string rather than to UTF-8:
// Both work
d->library = LoadLibraryW(nativeFilePath.toStdWString().c_str());
d->library = LoadLibraryA(nativeFilePath.toLocal8Bit().constData());
In regards to your question, from what I can discern the "Character Set" compiler flag in the MSVC actually controls only whether a `#define _UNICODE` is implicitly added. This #define, in turn, controls whether the various WinAPI #defines resolve to the `A` or the `W` variant. In this case: `LoadLibrary` is a preprocessor macro that can either resolve to `LoadLibraryA` or `LoadLibraryW`. If you pass to it a TCHAR string (another macro that expands to char or wchat_t) you can control the ANSI or widestring variants with a compiler flag. In Doomseeker I simply explicitly chose to use the widestring variant.
Nevertheless, I missed an important remark in MSDN that states that backslashes should be used in the path instead of forward slashes. So, adjustment for that is here:'https://bitbucket.org/Doomseeker/doomseeker/commits/a4dfeee1abefddfcec79aee55f0405c92866adff [^]'
Moreover, this exists:'https://doc.qt.io/qt-5/qlibrary.html [^]'
Unless QLibrary will bring back 0003401, we should consider using that instead of the native API functions.
|
|
|
|
(0021056)
|
|
Zalewa
|
|
2019-10-06 08:56
|
|
|
|
|
|
|
This went out to 1.3.1 release. I don't have a Windows operating system, sorry; Can anyone confirm this to be resolved, please? |
|