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.
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.
Added the progress dialog as a relatively generic thing (it was
implemented as a pair of dialogs in the WinForms version, for no
very good reason). Generation and assembler execution works.
Getting the layout just right got a little wordy in XAML. There's
probably a way to make a Grid do what I want. This'll do for now.
Also, fixed the labels on the buttons in DiscardChanges, which were
reversed.
Pretty simple dialog, but it took a while to figure out the best
way to deal with input validation. Works from the various menus as
well as double-clicking on .ORG and address column entries.
Also, moved some stuff around to places that made more sense.
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.)
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.
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.
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.
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.
