Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
If it is relevant to add height for a header for a given list view, it
is better to override Height and do it there.
|
|
The user-defined conversion function makes the interface a lot simpler
AND safer.
|
|
Next step is to allow a double click to reset the split to be
automatically resized.
|
|
I don't hate Hungarian notation. It has some very nice qualities. But
it also adds a lot of typing.
That said, not using it feels a bit... unsafe. I might go back on this
decision. We'll see.
|
|
std::basic_string is nice, but it is not very ergonomic if everything
you really need is to automatically free C strings at end of scope.
I suppose I could have used std::unique_ptr for this, but I suspect
the ergonomics would be worse.
|
|
Pl has also been refactored, so that the unnecessary throw and
catch have been removed.
|
|
This style is more compact and quicker to read once you know what the
first two member in LVITEM are (mask and iItem).
|
|
|
|
Even though it is a fun challange in many ways, I think that,
realistically, it is probably not worth the complexity. The
Prolog backend isn't ANSI-compatible either.
|
|
|
|
This reverts much of 97f0a27.
1. It turns out not to be a good idea to resize the list view columns
based on the list view window's own rectangle, as it will change
depending on whether a scrollbar is visible. The problem is that
resizing the columns may add a horizontal scrollbar -- which in
turn may add a vertical scrollbar.
2. The WS_EX_CLIENTEDGE style does not look very good in "modern"
(non-classic) themes. In 97f0a27, I tried solving this by extending
the dimensions of the child windows such that their edges were
hidden. However, this type of overlapping causes problems with the
status bar. My new solution is to instead *reduce* the child
windows' dimensions. This achieves a visual impression similar to
the thicker (more well-designed) edges of the "classically themed"
list view control. To make it look even better, the main window
background is changed from COLOR_WINDOWFRAME (white) to
COLOR_WINDOW (light gray).
|
|
Turns out that SWI-Prolog's wide string functions, which I started
using in 03fe361, do not convert between narrow Prolog atoms and wide
C strings, as I mistakenly thought. Instead, they work with wide
Prolog atoms. In hindsight, it is not surprising.
|
|
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.
|
|
|
|
It's not very useful, but it's a fun exercise.
|
|
|
|
Apparently foreign frames ARE needed when calling Prolog from C. The
official documentation is very terse and could make this clearer.
To summarize, whenever a term is created (e.g., PL_new_term_refs), its
reference count is increased by one. It is garbage-collected when its
reference count hits zero. But the reference count is never decreased
unless (a) control returns to Prolog after executing a foreign
predicate -- which does not happen in my application -- or (b) the
foreign frame in which the term was created is closed.
In other words, terms must be created within a foreign frame. This is
achieved by initializing a Frame object before creating the term and
destroying it once the term has served its purpose.
The destructor for Frame does not DISCARD the frame, only CLOSE it.
The former would also invalidate all data bound by the terms, which is
usually undesirable.
|
|
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.
|
|
This avoids the use of TsmFromSz.
|
|
|
|
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 is a bit safer and about as complex.
|
|
|
|
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++.
|