Effects > Artistic > Stained Glass: add debug code for displaying Voronoi points
FreeImage interface: minor debug additions
Improve build state reporting

Since VB lacks a good method for automating crash dumps, and most
OS-level crash dump tools require interactions outside the scope of a
portable application (e.g. WER registry spelunking), I'm starting work
on a custom, light-weight action tracker to help me debug some of PD's
more unpredictable crashes.

The first step toward this is more detailed tracking of PD's current
build mode.  A public const can now be checked against pre-alpha, alpha,
beta, and production build states.

This constant will also auto-enable certain behaviors; e.g. for
pre-alpha and alpha builds, timing reports will be automatically
enabled.
Preferences engine: for non-release builds, create a /Debug folder

...inside the /Data folder.  All of PD's custom debug and performance
data will be written to this folder.
Effects > Artistic > Stained glass: fix alpha handling of 32bpp layers
File interface: new function for retrieving creation, last access, and/or last-modified dates of files

As noted in the comments, thank you to
http://vb.mvps.org/hardcore/html/filedatestimes.htm for help with these
APIs.
OS interactions: many improvements and new features

For the new debugging class, it makes sense to add basic OS information
to our debug logs, to save bug reporters from having to supply that data
manually.  New features include:

- Retrieve detailed OS version data (build, architecture, etc)
- Retrieve logical processor core count
- Retrieve relevant processor features (helpful if we ever decide to
implement some inline ASM functions)
- Retrieve RAM data, including total amount, and amount available to PD
(both virtual and hypothetical max)

This should be sufficient data to narrow down OS-related issues, if they
ever arise, while still being sufficiently generic to protect user's
privacy.
pdDebug: a better solution for client-side debugging

Keeping with PD's grand tradition of NIH syndrome, I have just wrapped
work on a new custom debug logger for the program.

(Joking aside, this will hopefully save a great deal of time and effort
in the future.)

As PD gets more complex, I'm having more and more trouble debugging
unpredictable errors on client PCs.  Granted, a lot of these errors
occur due to nightly builds being inherently untested, and many of the
worst issues get corrected as development carries on, but for every
error I hear about, I assume a lot more are going unreported.

Unfortunately for me, classic VB is very unhelpful when it comes to
debugging a program of PD's size and complexity, especially with all the
subclassing and hooking I do.  Even more problematic is the many program
behaviors that differ between the IDE and compiled exe, not to mention
complex interactions with OS version, display drivers, screen
resolution, and many other factors inherent to a photo editor.

To try and work around some of these issues, and to ultimately make my
life much easier, I'm going to be replacing many of PD's Debug.Print
{string} statements with this:

#If DEBUGMODE = 1 Then
pdDebug.LogAction {string}
#End If

The new pdDebug class is basically a lightweight log file interface.
Its main purpose is to take all data it receives, timestamp it, and
mirror it across the Immediate window (if in the IDE) or to a log file
(if PD is compiled with DEBUGMODE = 1).

This is effectively a transparent change for the program, aside from the
manpower involved in replacing most Debug.Print statements.  When PD is
*not* compiled in debug mode (e.g. production builds), all
pdDebug.LogAction requests will simply be removed from the compiled
.exe, thanks to the conditional compilation flags.  In this regard, the
new code is basically a supercharged Debug.Print statement that also
happens to be available in the compiled .exe, depending on the
compile-time flags used.

In addition to logging manually posted data, the debugger also writes
some basic system and PD build data to the log, saving me from having to
manually ask testers for that data.  In the future, I'd like to add
automatic logging of things like the program's RAM usage, which should
help me identify memory leaks much earlier than I historically have.

All debug data is written to a new /Debug folder in the program's /Data
subfolder.  The debug folder is not created by production builds.  PD's
automated performance reports will also be moved to this folder, so
testers can just .zip the whole thing up and send it to me if problems
arise.

I've been quite careful to keep debug log data as generic as possible,
to protect users' privacy, and to that end I have used a plain-text log
format so users can see exactly what data is being shared.

PD will automatically save debug logs from up to ten sessions.  If an
eleventh session is initiated, the oldest debug log will be overwritten.
(This was a good chance to write some "sort files by age" code that I
need elsewhere in the program, so two birds with one stone, etc.)

Going forward, I'm going to start reworking debugging in the most
complex and error-prone portions of the program (e.g. loading image
files), then gradually working my way into more obsolete areas of the
program.  This debug overhaul will take place amidst other work on
preparing for 6.4's release, but I'd really like to have most the debug
code rolled over to this new system before releasing a beta, as
obviously betas are great for bringing in new testers.