Windows' default behavior is apparently to fill the display with the
app window, capped at 1920x1200. This is annoyingly large for most
situations.
We now save the main window rect (LTRB) and maximization status in
the configuration area of the registry. The window placement calls
are supposed to do something reasonable when the window would be
completely off-screen (e.g. because a secondary monitor was disabled).
This updates the project to use the VS2019 toolchain (v142). Note
this breaks WinXP compatibility.
The MFC and VC runtime DLLs have been updated from v120 to v140.
The program version has been updated to v4.1.0-d1.
Windows is currently creating the main window at near-maximal size.
It used to remember the size and placement, but no longer does.
As a workaround, the initial size is set to 1150x800, which is large
enough to show all columns without scrolling even with very wide
pathnames. With some effort this could be modified to respect the
maximum size of the monitor on which it will be displayed, so that
anyone still running at 1024x768 won't be in a bad place.
Ideally it would remember the previous size and position. See
issue #41 for discussion.
VERSION=0/1/2 corresponds, simply, to v0/v1/v2, where v0 was only
used for some older 8-bit Orca/M stuff. v2.1 can be detected by
looking for the optional "tempOrg" field.
Also, allow the disk version number to be set to zero in 2IMG images.
When extracting files, you can ask CiderPress to add a file extension
by checking the "add file extension" box. Whether or not this box
is checked, files that undergo a format conversion (e.g. AWP to RTF,
or SHR to BMP) have a file extension added to identify the file's
new format.
This turned out to be confusing and inconvenient at times, notably
when working with Merlin source files. See issues #10 and #26 on
github for details.
CiderPress no longer adds file extensions to format-converted files
unless the "add file extension" box is checked. (The "Configure for
easy access in Windows" button checks this box for you, so the
default behavior is still "safe".)
Also, fix a minor visual glitch in the extract dialog.
Also, update to version 4.0.3-a3.
32-bit * 32-bit = 32-bit, so disk images with partitions whose size
exceeded the capacity of a 32-bit int were coming out wrong.
Updated version to 4.0.3-a1.
The file viewer was seeing zero-length formatted output and assuming
that it was the result of zero-length input. This is a problem
because the code disables the format options when there's nothing to
format. This resulted in the strange behavior noted in issue #14.
Now the "is source empty" value is passed explicitly, and we display
a different message when the formatter fails.
When initially opened in Visual Studio 2015 Community Edition, the
project was updated to use the v140_xp toolset. When the program
was run under WinXP it complained about a missing runtime DLL. When
the DLL was provided, it complained about another one (with a
slightly strange name). So I reverted the tools to v120_xp, i.e.
Visual Studio 2013. (I don't know if this works because the tools
are included with VS2015, or because I have VS2013 installed and it
managed to find them.)
Whatever the case, it now builds for me with either IDE, and seems
to work fine on Windows XP, but I'd like to figure out why the XP
build isn't working with the v140_xp tools.
The code was mis-handling semicolons embedded in macros, treating
them as the start of a comment. It now checks to see if they're
at the start of a line or preceded by a space.
The 1.0 edit control only searched down, so the fact that CP was
misconfiguring the search request didn't matter. This change fixes
the search parameters and enables bi-directional searches.
DiskCopy disk images on HFS volumes, such as the ByteWorks Opus ][
CD-ROM, have resource forks. The double-click handler was screening
out forked files, so double-clicking on one of these disk images
was popping open the file viewer instead of creating a new instance
of CiderPress.
Ideally there would be a preference that allowed you to enable
logging and specify the file's location. That could make remote
debugging of certain problems easier.
The images in Paintworks PNT files are 2x the height of the SHR
screen. The rich edit control was ending up scrolled to the bottom
of the image, which is bad because many of the image files don't
really have anything interesting in the bottom half. This shifts
the position back to the top.
Also, some minor source code touch-ups.
The height was supposed to be just tall enough to fit a Super
Hi-Res graphic without needing to scroll, but it had become too
short by about 6 pixels.
The width was supposed to be wide enough to exactly fit 80-column
text, but the optional scroll bar ate two columns when it appeared.
We now over-size the viewer so it looks right when the scroll bar
appears.
Switch the remaining dialogs to the system font. This required
minor adjustments in a couple of places.
Also, remove the remnants of the ChooseDir dialog.
For a file with ".shk" extension, prioritize disk image over NuFX
file archive. The disk image code won't accept it if it has more
than one entry, and it's pretty rare for somebody to want to open
a single-disk archive in file mode.
Ideally all single-disk archives are named ".sdk", but there's
probably a lot that are just named ".shk", so this will probably
be more convenient.
More volume name MOR conversions. I think I got them all.
This also switches the "archive info", "add files", and "extract
files" dialogs to use the System Font. We were using "MS Sans
Serif" before, which looks a bit ratty on Windows 7 because it
doesn't take advantage of ClearType. (Apparently the ClearType
version is "Microsoft Sans Serif", though when you set the "use
system font" boolean to true it changes the font name to "MS Shell
Dlg".) The old font also seems to be missing certain glyphs, e.g.
my HFS volume name had 'TM' in it, but that just showed up as a box
(which is why, in case you were wondering, these changes ended up
together).
The new font seems to work equally well on WinXP, so I may enable
it for all dialogs in a follow-up change. As far as I can tell it
has the same font metrics -- I haven't seen anything weird looking
in the dialogs I've updated so far.
Also, bumped the version to 4.0.0-b3.
We needed to convert the volume name correctly for the volume list
and the progress dialogs when copying to or from a file. This
shouldn't affect how anything works, but it looks nicer with HFS
volumes that have non-ASCII characters.
We weren't doing a MOR-to-UNI conversion on the sub-volume name, so
HFS volumes with non-ASCII characters didn't look right.
This also relocates the character-conversion code to a new source
file. It's currently part of the reformat lib, though it arguably
belongs in util (but that would introduce a new dependency
between reformat and util).
