If scaling > 100% is enabled on the primary display, the controls in
the dialog window get bigger. The file viewer uses hard-coded values
for the initial and minimum window size, which causes the expanded
controls to draw on top of each other. (Issue #53.)
We now query the system for the scale factor, and adjust the window
size accordingly.
It appears that some programs, notably Copy ][+ and the GS/OS FST,
expect that the first block of a sparse file will always be
allocated, even if it's just 512 zeroes. I've only seen this fail
in cases where the first entry in the master index block of a "tree"
file is zero, because the first 128KB are sparse, but rumor has it
that the issue can affect "sapling" files as well.
This changes CiderPress to work the way ProDOS does: always allocate
a block to hold the first 512 bytes of the file. The only exception
to this is a file that is nothing but zeroes (perhaps populated by
creating a file and setting its EOF to something large), which can
be stored as a seedling.
(for issues #15 and #49)
It's okay to have the window off the top/left edge of the primary
display, but CiderPress was rejecting the values and reverting to
default placement.
(for issue #41)
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.
The test for "is this an S-C Assembler source file" tried to
dereference a null pointer when asked to examine a file with a
zero-length data fork. The test only fires for files with type=INT
and auxType=0, so this is pretty hard to hit. The specific failing
case had a damaged file with the appropriate file type.
Issue #42
The ProDOS code was assuming that the volume directory was 4 blocks
long. Some disks, such as the ProDOS 2.4.2 distribution disk, only
use the first two blocks. CiderPress now scans the volume directory
to determine the actual length.
Fixes issue #32.
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.
AppleWorks 5 added inverse text and MouseText. We can handle inverse
text with RTF features, and convert MouseText to something vaguely
similar in the Unicode symbol set.
