Generation of HTML is extremely fast, but compressing thousands
of frames for wireframe animated GIFs can take a little while.
Sharing bitmaps between threads required two changes: (1) bitmaps
need to be "frozen" after being drawn; (2) you can't use Path because
BackgroundWorker isn't a STAThread. You can, however, use a
DrawingVisual / DrawingContext to do the rendering. Which is really
what I should have been doing all along; I just didn't know the
approach existed until I was forced to go looking for it.
Also, we now do a "run finalizers" call before generating an animated
GIF. Without it things explode after more than 10K GDI objects have
been allocated.
Defined a simple monochrome bitmap format, and created some pieces
for a Tic-Tac-Toe game. Wrote a tutorial that explains how to
visualize them.
Also, updated some comments.
As with still images, animations are rendered at original size and
then scaled with HTML properties.
Also, fixed the blurry scaling on animation thumbnails. I couldn't
find a way to do nearest-neighbor scaling in the code-behind without
resorting to System.Drawing (WinForms), so I added an overlay image
to the various grids.
Visualization animations are now exported as animated GIFs. The
Windows stuff is a bit lame so I threw together some code that
stitches a bunch of GIFs together.
The GIF doesn't quite match the preview, because the preview scales
the individual frames, while the animated GIF uses the largest frame
as the size and is then scaled based on that. Animating frames of
differing sizes together is bound to be trouble anyway, so I'm not
sure how much to fret over this.
We now store Visualizations, VisualizationAnimations, and
VisualizationSets as three separate lists linked by tag strings.
WARNING: this breaks existing projects with visualizations. The
test projects have been updated.
The ListView control provides a ScrollIntoView() method that ensures
the specified item is on screen, scrolling the ListView if needed.
Unfortunately this method is very slow (50-100 ms) and sometimes
fails entirely on larger lists. (Yay WPF.)
Because the ListView is scrolling by fixed-height item, it's possible
to use the underlying ScrollViewer to move the list instantaneously
and reliably. So now we do that.
Also, fixed a bug with select-all, where we weren't clearing the
previous selection before calling SelectAll(), leading to a mismatch
with the secondary data structure that we maintain because WPF
ListViews can't deal with large selections efficiently. (Yay WPF.)
There's still some weird behavior, e.g. sometimes hitting F5 clears
the current selection and sometimes it doesn't. I think it's related
to which item has focus and the fact you're hitting a key; using the
debug menu item doesn't cause the behavior.
Also, increased MAX_SEL_COUNT from 2000 to 5000. That takes about
200ms to restore to a ListView on my 5-year-old system.
Whenever the display list gets regenerated, we need to restore the
code list view scroll position to the previous location in the file.
This gets tricky when multiple lines are appearing or disappearing.
We were saving the file offset of the line, but that works poorly
when there's a multi-line comment associated with that offset,
because we end up scrolling to the top of the comment whenever any
part of the comment is at the top of the screen.
We now track the file offset and the number of lines we were from
the top of that offset's content. This works well unless we remove
a lot of lines. If the adjusted line index would put us into a
different file offset, we punt and just scroll to the top of the item.
Also, fix a crasher in Edit Note.
Also, fix behavior when the list shrinks while a line near the end
of the file is selected.
Also, change a few instances of "Color.FromArgb(0,0,0,0)" to use a
common constant.
I haven't figured out how to make the AppendText(text, color) extension
work right with the WPF version of RichTextBox, but I was able to work
around the issue, and it's not really worth sinking time into.
Notable items include the column show/hide buttons, which were
straightforward except for the "determine the default width" part,
and the font picker, which is no longer a standard dialog. The
latter was complicated by the absence of a good way to detect
whether a font is mono-spaced or not without calling back into code
meant for WinForms font manipulation (with a dash of PInvoke).
Yay WPF.
Also, enabled character ellipsis for code list items.
Now preserving column widths for the three DataGrids and the main
ListView. In theory the various grids would conveniently auto-size
to the content, but in practice that doesn't work well with
virtualization.
There is, of course, no simple "the width has changed" event
provided by the control. On the plus side, you can attach a
property-change event handler to pretty much anything, so once you
know the trick it's possible to make everything work. Yay WPF.
This change pulls in the settings file code, which is mostly
unchanged except when it comes to saving and restoring the window
location and size.
The old system has been replaced with a PInvoke-based version that
calls the underlying Win32 window placement code. This is more
likely to be correct when multiple displays are in use, and can
record the un-maximized size of a maximized window. It leaves a
nasty XML string embedded in the config file, but it's not really
meant to be human-readable anyway.
The sub-window dividers all work completely differently from the way
they did in WinForms, and some of the behavior is a bit obscure
(like noticing when a splitter moves due to keyboard input, and
setting the position in a way that doesn't break the auto-sizing).
Yay WPF.
Still need to preserve column widths.
Wired up the double-click handlers for References, Notes, and
Symbols. These jump to the item at the offset that was double-
clicked. Also hooked up the navigate forward/backward buttons
in the toolbar.
Except for the usual WPF gymnastics required to figure out what you
actually double-clicked on, this went smoothly.
Extract some XAML icons from the VS2017 Image Library. There's no
particular reason to prefer XAML over PNG, but somehow it feels
more forward-compatible. (OTOH, defining images as ControlTemplate
instances is just weird. Yay WPF.)
Restoring the selection works pretty much like it used to, though
I'm capping the total size of the selection because it goes into
stupid-slow mode if you have too many elements.
Getting the item that is at the top of the ListView is astoundingly
obscure, due to the ListView's extreme generality. I make a
simplifying assumption -- that we're using a VSP -- which allows us
to use a simple vertical offset once we've dug the appropriate
object out of the visual tree. (The alternative is to walk through
the list of items and see what's on screen, or perform a hit test
calculation in the upper left corner.) Yay WPF.
Doesn't work 100% correctly -- in some cases, using two different
combos in quick succession will fail -- but it's close.
Added stub methods for the four hint operations.
