I was setting the window size and letting the contents fill to fit.
Now I'm setting the content size and letting the window size itself
to fit around it. The latter feels like it'll hold up better as
things change.
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.
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.
This turns out to be really important. Otherwise the modal dialog
doesn't stay on top of the application's window stack, which can
make things awkward when ShowInTaskbar is set to false. The easiest
way to ensure this is getting done is to make it part of the
constructor arguments.
The code now passes the parent window in explicitly. WPF MessageBox
avoids this by calling UnsafeNativeMethods.GetActiveWindow(), but
that feels weird. We could assume Application.Current.MainWindow
is the parent, but that seems like it could go quietly and horribly
wrong.
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.
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.
The filtering uses the DataGrid View filtering mechanism. The
built-in sorting only operates on a single column, and we really
want a secondary sort on label when the type is used as the key,
so we provide a custom sort method.
Also, fixed some crashiness in the can-execute tests for hints.
If you crash an a can-execute method you get a really unhelpful
failure message. Asserts don't work there either. Yay WPF.
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.
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.
SourceGen creates "auto" labels when it finds a reference to an
address that doesn't have a label associated with it. The label for
address $1234 would be "L1234". This change allows the project to
specify alternative label naming conventions, annotating them with
information from the cross-reference data. For example, a subroutine
entry point (i.e. the target of a JSR) would be "S_1234". (The
underscore was added to avoid confusion when an annotation letter
is the same as a hex digit.)
Also, tweaked the way the preferred clipboard line format is stored
in the settings file (was an integer, now an enumeration string).
In the cross-reference table we now indicate whether the reference
source is doing a read, write, read-modify-write, branch, subroutine
call, is just referencing the address, or is part of the data.
This worked, sort of. The problem is that SourceGen will revert to
hex output in certain situations, such as a broken symbolic
reference. There happens to be one in the ZIPPY example, and it's
on a relative branch.
The goal with the segment stuff is to allow cc65 to treat the
source as relocatable code. In that context, a relative branch to
an absolute address doesn't make any sense, so the assembler reports
a range error.
We don't currently have a mechanism that guarantees no references
are broken (and no affordance for finding them), so we can't make
this mode the default yet.
Instead, we continue to use the generic config, but generate the
correct set of lines as comments.
(issue #39)
The system configuration you get with "-t none" works for smaller
files but fails for larger ones. This updates the generator to
produce a source file and linker script pair. (I kinda saw this
one coming -- it's why the gen/asm dialog has a combo box for the
file preview -- so it didn't require that much work.)
This currently generates a fixed script for a generic system with
64KiB of RAM, using .ORGs to set the addresses as before.
With this change, assembling a file with 65536 NOPs succeeds.
(issue #39)
