- Add IDS_ADDRESSMENUTEXT resource string (whose ID matchs the string of addressband.rgs).
- Add SHLoadRegUIStringA/W function prototype to <shlwapi_undoc.h>.
- Use SHLoadRegUIStringW to load MenuTextPUI.
CORE-18394
- Add as well the undocumented 0x40 dwFlags value from shlwapi!PathFileExistsDefExtW()
to the list.
- Fix a bug (also present in Win2k3) in PathResolveW() where, specifying
the PRF_DONTFINDLNK flag, would also erroneously exclude checking for
the .cmd extension as well (which was obviously NOT the original
intention, from the name of the flag and the documentation as well:
https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-pathresolve
).
Addendum to 3a822e4f.
This makes ShellMessageBoxW use the correct implementation where the
text buffer size is dynamic, instead of having a too small hardcoded
size.
Fixes CORE-17271.
See also PR #3172 by Kyle Katarn, supplemented with some ideas from
Mark Jansen.
However we cannot straightforwardly implement ShellMessageBoxA around
ShellMessageBoxW, by converting some parameters from ANSI to UNICODE,
because there may be some variadic ANSI strings, associated with '%s'
printf-like formatters inside the format string, that would also need
to be converted; however there is no way for us to find these and perform
the conversion ourselves.
Therefore, we re-implement ShellMessageBoxA by doing a copy-paste ANSI
adaptation of the shlwapi.ShellMessageBoxWrapW function.
Note that, on Vista+ onwards, shlwapi implements both ShellMessageBoxA/W,
and shell32 directly forwards these exports to shlwapi, thus avoiding
these workarounds.
[PSDK] Explicily use WINAPIV for the variadic ShellMessageBoxA/W functions.
[INCLUDE/REACTOS] Add ShellMessageBoxWrapW in shlwapi_undoc.h .
Shell change notification has been implemented in #2432. But as @yagoulas said, source code structure is in mess. We improved simplicity and human readability of our source code.
- Move wine/changenotify.c code into changenotify.c and shelldesktop/CChangeNotify.cpp.
- Simplify code and rename the identifiers and add many comments. CORE-13950
[SHLWAPI] Refactor the SHCreateWorkerWindowW() prototype to match its ANSI SHCreateWorkerWindowA() counterpart.
The last parameter is really to be understood as an extra window data, and not a "message result" (as it would be the case for dialog window procedure).
That is why I also remove the mention of "DWLP_MSGRESULT" in the SetWindowLongPtrW() call.
SHCreateWorkerWindowA() had it OK but SHCreateWorkerWindowW() did not.
------------------
[SHLWAPI] Make SHCreateWorkerWindowA() and SHCreateWorkerWindowW() x64-compatible.
The first parameter of these functions is a pointer to a window procedure, having a definite prototype, so employ a correct typedef WNDPROC,
which ensures both correct pointer size and parameter type enforcement.
This also ensures that we use instead a correct pointer size, since otherwise LONG remains 32-bits for Windows compatibility on x64 platforms.
The wndProc parameter is thus casted to LONG_PTR to comply with the SetWindowLongPtrA/W calls.
In SHCreateWorkerWindowW(), the last "wnd_extra" parameter should also be LONG_PTR to be able to pass 64-bit data pointer on x64 platforms.
Therefore fix also setting the wc.cbWndExtra size. One should note that the ANSI SHCreateWorkerWindowA() function had everything OK already.
