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.
Because of the way data virtualization works (or doesn't) in WPF,
this was a whole lot different from WinForms. What I'm doing is
pretty simple, so I avoided the complexity (and quirks) inherent
to more complete data virtualization solutions. (All I really want
is to not render the entire thing up front.)
We can now Edit Long Comment and Edit Header Comment.
Changing the number of lines in a long comment exposed a bug in the
display list update. Fixed.
Running the WinForms version trashed the column widths, which exposed
the fact that the default column widths were set too narrow. Fixed.
On an unrelated note, hitting undo/redo quickly will sometimes leave
you scrolled to the bottom of the code list. Some sort of command-
handling race in the WPF framework? (Not fixed.)
The dialog is pretty straightforward. This is the first editor that
can cause a partial update -- if you edit a label, only the lines
that refer to that label are regenerated -- so I added the code for
partial display list updates as well.
Also, while working on this I noticed that long comments were getting
ellipsized at a bad place. The column width for the semi-hidden
column used for notes and long comments wasn't getting set. After
fiddling with it a bit I determined that it really needed to be set to
the sum of the widths of the rightmost four columns, and updated
whenever column sizes change. This was easier to do than I expected.
I may actually be getting the hang of WPF.
Renamed VirtualListViewSelection to DisplayListSelection, because
it's now tied to the DisplayList implementation. Hooked it up to
handle SelectionChanged events.
Also, tweaked the code list item style to remove the one-pixel gap
between items. Somehow I manage to click on the dead zone with
surprising regularity.
There was a bigger change here, but the approach turned out to
have some problems with large sets. The current app saves and
restores the selected rows when you make an edit, retaining the set
of selected bytes even if the number of lines changes (maybe you
reformatted bytes into a string). There's no way to do that quickly
with WPF when the number of selected items gets large (say 10K+).
I will probably just cap the selection, and refuse to restore it if
it exceeds a certain size.
The ListView SelectedItems management seems to use an O(n^2) (or
worse) algorithm. It might be trying to verify that items being
added to SelectedItems actually exist in Items -- I can see it
calling Contains(). Whatever the case, it's a big step backward
performance-wise from WinForms. Yay WPF.
See the DisasmUiTest project's Selection Test to see what I tried.
The disassembled lines are now shown in the custom-styled list view.
The DisplayList isn't being kept up to date on edits, but since we
can't edit anything yet that's not too limiting.
Pulled more code over, including the mostly-GUI-agnostic bits of the
source generation and assembler execution code.
I'm trying to make the ListView look like the old owner-drawn
WinForms UI. The tricky bit is getting long comments and notes to
start in column 5 (label) and extend across multiple columns.
This approach sort of works, though it's currently incomplete, e.g.
the selection highlight style apparently gets dropped.
In WinForms, if you want a virtual ListView, you set the "virtual"
property and define a couple of callbacks. In WPF, there are
separate notions of "UI virtualization" and "data virtualization".
The former is done automatically (usually) by the ListView. The
latter requires creating an implementation of IList, and relies on
behavior that I'm having trouble finding in official documentation.
Yay WPF.
This splits the source-generation stuff out into DisplayListGen,
leaving DisplayList as a list of stuff to display that can be bound
to WPF as a ListView ItemsSource. The DisplayList instance will have
a hook back into DisplayListGen to perform the on-demand string
rendering. (For now it's just generating test patterns.)
Mostly a straight copy & paste of the files. The only significant
change was to move the localizable strings from Properties/Resources
(RESX) to Res/Strings.xaml (Resource Dictionary). I expect a
number of strings will no longer be needed, since WPF lets you put
more of the UI/UX logic into the design side.
I also renamed the namespace to SourceGenWPF, and put the app icon
into the Res directory so it can be a resource rather than a loose
file. I'm merging the "Setup" directory contents into the main app
since there wasn't a whole lot going on there.
The WPF Color class lacks conversions to/from a 32-bit integer, so
I added those.
None of the stuff is wired up yet.
