Age | Commit message (Collapse) | Author |
|
This incidentally removes the need for the variable
template introduced by 21e96c6. I'm sure it will be
needed at some point, though.
|
|
The variable template could be generalized like this:
template <auto F, auto... A> const auto cache = F(A...);
and instantiated like:
cache<GetSystemMetrics, SM_CXVSCROLL>
It would still be limited to constant function arguments, which
usually isn't a problem for GetSystemMetrics, but might be for
other functions.
|
|
If the main window exists, it is probably a good idea for the message
box to be owned by it. Otherwise, the user may continue to interact
with the main window. Of course, that could sometimes be a benefit,
but it SEEMS a bit unsafe... I might change this in the future.
|
|
No, not "awful", AWFUN!
Speaking of AWFUN, here is an alternative implementation of it:
#define AWFUN(t, f) cond_fun<t, f##A, f##W>
template <typename T, auto F, auto G>
std::enable_if_t<std::is_same_v<T, char>, decltype(F)> cond_fun = F;
template <auto F, auto G>
auto cond_fun<wchar_t, F, G> = G;
This implementation uses a variable template instead of a function
template, but I decided against it, as (at least I think) it would
instantiate useless variables that merely point to pre-existing API
functions. Like,
auto cond_fun__wchar_t__blablabla = MessageBoxW;
auto cond_fun__char__blablabla = MessageBoxA;
which is quite useless. Better to just have a constexpr function,
which the compiler may inline, return the real function pointer.
|
|
As the message box has no owner (because the main window may not be
initialized yet), it may be unclear which application is being
terminated.
|
|
|
|
|
|
|
|
|
|
In warn_nil, the return value was undefined on exception -- I think.
While informative, the names throw_nil and warn_nil don't work very
well in conditionals:
if (warn_nil<f>(...)) g();
sounds like g should be called if f returns nil and a warning is
issued. But it is actually the other way around; g is called if f is
successful.
if (prefer<f>(...)) g();
sounds less like that.
|
|
Some of the checks are likely redundant, but the Windows API
documentation rarely makes it clear WHICH errors may be returned (and
under which circumstances) rather than simply WHETHER errors may be
returned (under any circumstances, including those that do not apply
in the given case).
|
|
|
|
|
|
|
|
|
|
|
|
It isn't really more safe, but it removes the need for a confusing
function pointer cast, which is easy to get wrong. As far as the
compiler is concerned, the result is literally the same, but it does
force the caller to (indirectly, via the template parameter) cast the
return value, which may be a good thing.
|
|
|
|
|
|
|
|
|
|
|
|
Apparently, = {0} does not zero a structure in C++.
|
|
|
|
f(void) is a C-ism that is valid but unnecessary in C++.
|
|
A getter offers encapsulation, but it is also less transparent in a
sense. Thinking of ListView as a struct, it is natural to expose hWnd
as a public member variable.
|
|
|
|
It seems that "right-spaced" pointers are more widely used among C++
programmers.
|
|
Note that I did NOT add const to non-pointer/non-reference arguments
in function declarations (without a following definition), as they do
not mean anything there.
|
|
|
|
I.e. using std::basic_string<TCHAR> instead of TCHAR *. This removes
all unmanaged frees.
|
|
This avoids g_hWnd.
|
|
This is feasible now that the makedeps script exists to automatically
manage build dependencies (see 6034fe2, d00f8b3).
|
|
|
|
|
|
This requires C++17.
|
|
|
|
In the future, it may be desirable to convert Prolog exceptions to C++
exceptions.
|
|
This is a bit safer and about as complex.
|
|
|
|
|
|
Bug introduced in 26f70ab. DataListView was initialized with g_iDPI
set to -1, which is obviously incorrect. The default value of -1 is a
remnant of earlier code and is no longer necessary.
|
|
Height(DLVSIKEY) was incorrect. The argument to Height is supposed to
be a boolean value, in this case false. It happened to work because
DLVSIKEY is 0 (because Key is the 0th column in the data list view).
|
|
The rules for what messages are sent at window creation -- and in
which order -- are neither intuitive or clear. WM_CREATE can NOT be
relied upon to initialize global state required by handlers of other
messages (such as WM_GETMINMAXINFO, which seems to be sent before
WM_CREATE).
Thus, the better solution is to initialize everything using a CBT hook
before the window procedure is even run. Because CBTProc creates
(child): windows of its own, though, one must be careful to only run
the initialization once, which is done by checking g_hWnd.
|
|
|
|
|
|
I already hit upon some object-oriented programming patterns in
*listview.c, so I felt that it would be natural to use this as an
opportunity to learn C++.
|