The various items in the Actions menu are enabled or disabled based
on the current selection. There's no SelectedIndices property in
WPF ListViews, so we have to do things slightly differently.
The SelectedItems list isn't kept sorted to match the list contents,
so finding first/last item requires a bit of scanning.
Also, rearranged some stuff. I'm trying to keep the old and new
code somewhat parallel, to make it easier to walk through at the end
and see if I've missed something.
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.
Create context menu as a clone of the Actions menu. This is a bit
easier than it was in WinForms because the ICommand stuff provides
common routing and enable/disable logic for all instances. (It's
one of the few places where WPF has made my life easier. Yay WPF.)
Added CanExecute tests to existing items. Currently they just
check to see if the project is open.
Wired up File > Close.
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.
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.)
Set up a notifiable property to control whether the "launch panel"
(i.e. the thing you see when the app launches) or the code ListView
is visible. Unearthed the magic required to left-justify the column
headers.
Fixed some stuff that crashed. The project is loaded but nothing
visually interesting happens yet.
I'm still not entirely sure what the deal with declaring resources
is, but it seems you can either declare a ResourceDictionary and put
everything in it, or you can declare a bunch of items, which are then
implicitly placed in a ResourceDictionary. This matters if you want
to have your string definitions merged in with everything else. All
of the examples I found did one thing or the other, not both at once,
so it took some fiddling. Yay WPF.
Done with full WPF fanciness, including XAML string formatting and
property extraction, with a fallback value so I can see what it looks
like in the designer.
It took about half an hour to figure this out. Yay WPF.
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.
