This adds a new class and a rough GUI for the editor. Animated
visualizations take a collection of bitmaps and display them in
sequence. (This will eventually become an animated GIF.)
Fixed the issue where changes to tags in the set currently being
edited weren't visible to the tag uniqueness check when editing other
items in the same set.
Project symbol address values are now limited to positive 24-bit
integers, just as they are for platform symbols. Constants may
still be 32-bit values.
While disassembling some code I found that I wanted the ROM entry
points, but the zero page usage was significantly different and the
ROM labels were distracting. Splitting the symbol file in two was
a possibility, but I'm afraid this will lead to a very large
collection of very small files, and we'll lose any sense of relation
between the ROM entry points and the ZP addresses used to pass
arguments.
Platform symbols have the lowest priority when resolving by address,
but using that to hide the unwanted labels requires creating project
symbols or local variables for things that you might not know what
they do yet. It's possible to hide a platform symbol by adding
another symbol with the same label and an invalid value.
This change formalizes and extends the "hiding" of platform symbols
to full erasure, so that they don't clutter up the symbol table.
This also tightens up the platform symbol parser to only accept
values in the range 0 <= value <= 0x00ffffff (24-bit positive
integers).
An "F8-ROM-nozp" symbol file is now part of the standard set. A
project can include that to erase the zero-page definitions.
(I'm not entirely convinced this is the right approach, so I'm not
doing this treatment on other symbol files... consider this an
experiment. Another approach would be some sort of conditional
inclusion, or perhaps erase-by-tag, but that requires some UI work
in the app to define what you want included or excluded.)
We were failing to update properly when a label changed if the label
was one that a plugin cared about. The problem is that a label
add/remove operation skips the code analysis, and a label edit skips
everything but the display update. Plugins only run during the code
analysis pass, so changes weren't being reflected in the display
list until something caused it to refresh.
The solution is to ask the plugin if the label being changed is one
that it cares about. This allows the plugin to use the same
wildcard-match logic that it uses elsewhere.
For efficiency, and to reduce clutter in plugins that don't care
about symbols, a new interface class has been created to handle the
"here are the symbols" call and the "do you care about this label"
call.
The program in Examples/Scripts has been updated to show a very
simple single-call plugin and a slightly more complex multi-call
plugin.
Extension scripts (a/k/a "plugins") can now apply any data format
supported by FormatDescriptor to inline data. In particular, it can
now handle variable-length inline strings. The code analyzer
verifies the string structure (e.g. null-terminated strings have
exactly one null byte, at the very end).
Added PluginException to carry an exception back to the plugin code,
for occasions when they're doing something so wrong that we just
want to smack them.
Added test 2022-extension-scripts to exercise the feature.
The analyzer sometimes runs into things that don't seem right, like
hidden labels or references to non-existent symbols, but has no way
to report them. This adds a problem viewer.
I'm not quite ready to turn this into a real feature, so for now it's
a free-floating window accessed from the debug menu.
Also, updated some documentation.
The plugin objects are MarshalByRefObject stubs, which means they
don't actually implement the interfaces we're checking for. There's
some additional overhead to do the interface check. We can avoid
it by doing the interface queries during initialization, and just
checking some bit flags later on.
Also, in the extension script info window, show a list of
implemented interfaces.
Once upon a time, symbol files and extension scripts could only be
defined in the RuntimeData directory, so having the documentation
there made sense. Since both of these things can now be defined in
project directories, the documentation belongs in the manual.
(issue #27)
