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).
The previous code was a stickler for only opening files whose type
matched what was selected in the filter pop-up. The original goal
was to allow you to choose whether a BXY or SDK file was interpreted
as Binary II, ShrinkIt, or disk image, since they could go either
way. Unfortunately, its refusal to consider types other than what
was selected made it kind of annoying.
The new code will start by trying to open the file with the selected
filter, so that it's still possible to choose how SDK and BXY files
are opened. However, it now continues on, trying all other types
before finally giving up.
If the generic ("*.*") filter is selected, CiderPress will start by
trying to open the file as a disk image.
This seems to produce good results with a variety of known and
unknown files.
Was setting the original pathname improperly, so when attempting
to add a file to a NuFX archive the "do you want to overwrite
existing entry?" dialog contained gibberish.
The previous version was written to work on Win98+, and used the
rather gnarly ShellTree class. Since we no longer support Win98,
we can now use CShellManager::BrowseForFolder(), which does exactly
what we want without all the ugly code (and it looks nicer, and it
integrates better with the rest of the system).
We can also get rid of NewFolderDialog, which only existed to allow
the user to create a folder when trudging through ShellTree.
This required "upgrading" the main app object from CWinApp to
CWinAppEx, but that appears to be benign. Tested on WinXP and it
all seems fine.
This handles version 1 and 2, and copes with the broken files
created by the Mac OS X "applesingle" command-line tool (which is
unable to decode the broken files it creates).
I get the sense that many AppleSingle files don't end with ".AS", so
the filespec includes "*.*" as well.
Some AppleSingle files don't include a filename. In that case, we
use the file's name as the entry name, minus any ".as" extension.
The current implementation doesn't convert from Unicode to Mac OS
Roman, so non-ASCII characters are mishandled unless the file was
generated by GS/ShrinkIt. (We assume version 1 AppleSingle files
use MOR name strings.)
Also, version bump to 4.0.0d3.
This updates GenericEntry's filename handling to be more careful
about Mac OS Roman vs. Unicode. Most of the work is still done with
a CP-1252 conversion instead of MOR, but we now do a proper
conversion on the "display name", so we see the right thing in the
content list and file viewer.
Copy & paste, disk-to-file-archive, and file-archive-to-disk
conversions should work (correctly) as before. Extracted files will
still have "_" or "%AA" instead of a Unicode TRADE MARK SIGN, but
that's fine for now -- we can extract and re-add the files losslessly.
The filenames are now stored in CStrings rather than WCHAR*.
Also, fixed a bad initializer in the file-archive-to-disk conversion
dialog.
Most of this change is a conversion of the old FileDetails struct
into a new LocalFileDetails class. The new class keeps the
members private, and keeps the Unicode and MOR representations of
the string separate.
The NuFX and DiskImg libraries don't support UTF-16 filenames,
so we stil can't add files with non-CP-1252 filenames, but we're
a step closer.
Also, update NufxLib with a couple of fixes from the main project.
Also, fix handling of "%00" when adding files.
Also, mark most of the A2FileDOS fields private. Not sure why
they weren't.
This tweaks the output for AWGS and Teach Text to convert from Mac
OS Roman to Unicode, rather than Windows code page 1252.
It would be slightly more efficient (and possibly a bit more legible
in the RTF file) if we left the "good" conversions alone, e.g.
continue to use the CP1252 character for "E with acute", instead of
converting to U+00C9. That might leave us at the mercy of the code
page converter in some random RTF reader, though, so it's probably
best to just use the official Unicode values.
The file extraction dialog allows you to select file parts, so you
can choose to exclude resource forks or just extract disk images. If
you don't choose any parts, nothing will extract, and you get a
confusingly generic message about nothing matching the criteria.
This adds a specific error message for the case where no parts are
selected.
DeployMaster can detect whether or not CiderPress is currently
running by checking for the presence of a window with a specific class
name. The default class name is generated differently each time, so
we need to set a custom class name.
Also, bumped version to 4.0.0d2.
The static analyzer was annoyed that the return value from calls to
CString::LoadString() was being ignored. This adds a wrapper
function that checks the value and logs a failure message if the
string can't be found.
The DeployMaster installer issue prevents the user from seeing more
than nine of the 18 file extensions that CiderPress wants to handle,
and I don't want to go stomping on file associations without some
way to disable the behavior. So this returns to the previous behavior,
where CiderPress directly manages the file associations.
The CiderPress app is not able to modify HKEY_LOCAL_MACHINE (which
it used to do via HKEY_CLASSES_ROOT) on recent versions of Windows --
tested in Win7, but it probably broke with Vista. So now we do
everything in HKEY_CURRENT_USER. This works, more or less.
We're not looking at the Windows shell overrides, which are made
in yet another set of registry entries, so there are multiple
reasons why the values reported by the Edit Associations dialog may
now be inaccurate. I still favor eliminating the dialog as a
long-term strategy.
I took the opportunity to do some code cleanup in the registry code.
I also added calls to SHChangeNotify() to tell the Windows shell when
file associations change, so Windows Explorer windows get updated
promptly.
