Skip to content
Commits on Feb 6, 2016
  1. pdTextBox: implement font sharing

    Edit boxes will now share their font objects amongst themselves, further
    dropping GDI object count throughout the project.  (GDI object count on
    a cold-start has dropped by more than 1,000 objects since I started this
    initiative - pretty exciting, and IMO a good sign that PD is running
    much more efficiently than it historically has, despite migrating to a
    nearly-100% custom-drawn UI.)
  2. pdTextBox: massive overhaul

    Text boxes are arguably the hardest control to theme, as they rely on an
    API-created edit box for text handling.
    This commit does a lot of things with text boxes; besides enforcing
    theming, the entire drawing system has been overhauled as well.  GDI
    count is down again, and high-DPI support is now active.
    Note that this commit breaks certain sliders inside the IDE.  I don't
    know why, but it's most likely due to a mismatch between API object
    resizing on the text box (required for high-DPI support) and internal VB
    size caches (used by the slider, which hasn't been migrated yet).  The
    compiled .exe is fine, and slider behavior inside the IDE will be
    restored once it's migrated to PD's high-DPI resize methods.
Commits on Feb 4, 2016
  1. Implement shared GDI brushes for edit boxes

    This cuts cold-start GDI objects by ~50 and simplifies future theming
Commits on Feb 3, 2016
Commits on Feb 2, 2016
  1. Continued improvements to theming support

    - pdButton has been overhauled to support spritesheets, ucSupport, and
    - started applying theming fixes to the command bar
    - wordwrap issues have been fixed in pdLabel when themes are active
    - vertical text centering added to ucSupport caption rendering options
    - some button-related fixes applied to the Batch Convert screen
    - Got/LostFocus events are now supported in pdHyperlink
  2. Theme engine: allow user-selectable color swatches

    In a perfect world, PD would support themes defined via generic CSS and
    HTML... but this is not a perfect world, so I have to fudge things a
    With this commit, PD's theme files now support a rough equivalent of
    CSS's "@import" rule.  A new "DefinitionFile" tag can either be defined
    by a theme file itself, or overridden at run-time.  This tag allows
    theme files to dynamically import a separate color definition XML file,
    while retaining the rest of the theme's data.
    For example, this feature lets me support different accent color schemes
    without needing to define a whole stupid theme for each accent (since
    the core mappings between UI elements and color values stays the same -
    we just change the color values to some other hue).
    The Tools > Developers > Theme Editor dialog now exposes Blue, Green,
    and Purple themes (each supporting light/dark variants), with swatches
    shamelessly stolen from Google's Material Design palettes
    (  These swatches
    are only for testing at present - as you can see, the dark themes are
    *too* dark in a number places - but this is very helpful for testing, as
    it exposes places where PD's old theming code may be sneaking through.
    In it's final form, I'd ideally like to let users select their own
    accent swatch similar to the Windows 10 Personalization -> Colors panel.
    This commit makes that a fairly trivial feature to implement.
Commits on Feb 1, 2016
  1. Fix missing text in pdResize

    There will be lots of little breaks like this as theming integration
    progresses, so please let me know if you encounter anything unexpected,
    and I'll try to fix it as quickly as I can.
  2. Brush, pen, gradient controls: finalize theming code

    Also, this commit adds manually clipping bounds support to
    pdGraphicsPath, which becomes important when we're rendering pen
    previews to only a sub-portion of a user control.
Commits on Jan 31, 2016
  1. Fix control name inconsistencies

    As part of this long-coming fix, there's a new (quick-and-dirty) tool in
    the /Support subfolder for applying universal search-and-replace inside
    a classic VB project.  Multiline search-and-replace is supported
    (although tabs are not treated specially, so you'd need to manually
    match indentation), but more relevant for me is replacing text inside
    Class/Control/Form/Module headers.  This is incredibly helpful when
    doing something like renaming user controls, as their instance names
    can't be replaced from inside the IDE (unless you do it manually for
    each occurrence, ugh).
Commits on Jan 28, 2016
  1. pdHyperlink: total redesign

    Microsoft's design guidelines refer to these as "command links", but
    it's roughly the same idea in PD.  The new control uses ucSupport and
    interfaces correctly with the current theme engine.
    I've also renamed the "File_And_Path_Handling" module to just
    "FileSystem".  My goal is to have PD's various modules look more like
    .NET classes, e.g. "FileSystem.FileOpen", to try and improve code
  2. Theme engine: optimize color caching

    Once PD's theme engine has successfully resolved an Object+Color pair
    (meaning it has connected the two strings into a base color + list of
    potential color variants for hover, click, etc), it will now cache the
    result centrally.  This spares subsequent lookups from needing to delve
    into XML.
    The speed difference isn't large at present, but as the list of colors
    (and corresponding XML size) grows, this will be crucial for keeping
    program load-time down.
Commits on Jan 26, 2016
  1. pdLabel: finalize theming support

    With this commit, I can now start serious theme testing via the Tools >
    Developers > Theme Editor menu.  The dark theme at this point is
    (literally) a cut-and-paste version of the light theme, with dark and
    light shades reversed, but I'll start editing the file seriously once I
    have a few more controls to play with.
    In the meantime, the few controls I've finished at least confirm that
    the theme engine is correctly loading and parsing the theme XML files,
    and the IDE can still be used without everything exploding...
  2. Theming: continued improvements

    - PD's central UCSupport class, which handles background buffer
    management for multiple controls, now supports theming.
    - PD's central pdCaption class, which handles caption painting for
    multiple controls, now supports theming.
    - Vertical ButtonStrip has been added to the "fully themed" list
    - Vertical ButtonStrip has been updated to use the same new rendering
    style as its horizontal partner
    - I've revisited PD's user control enumeration once again (sorry!).  To
    permanently fix TabStop issues, I'll soon make each custom PD control
    register itself with a central control handler when the control is
    loaded.  That handler will group controls by parent, and automatically
    sort registered controls from left-to-right, top-to-bottom.  TabKey
    presses will automatically be passed to the next enabled control in
    line, which spares me from having to manually specify TabStop order
    inside the IDE (a system that breaks constantly).  Anyway, because that
    handler will have a foolproof list of all the custom controls on a given
    form, I can just use THAT list to apply themes, rather than manually
    iterating ALL controls on a form!  Much more elegant.  (Please note that
    this fix is not present in this commit; I've postponed construction of a
    central control manager until I've finished the last few PD-specific
    user controls.  I just mention it here to explain why I've temporarily
    reverted to the old style of per-form control enumeration, with
    apologies to @Kroc for breaking his work.)
Commits on Jan 23, 2016
  1. ButtonStrip UC: add title caption support

    This allows me to strip many more label instances out of the project,
    reducing overhead and greatly simplifying theme-aware caption rendering.
    I've also made some modifications to the appearance of button strips.  A
    chunkier border is now applied when hovering, which should greatly
    improve visibility for users with poor eyesight (or cheap monitors).
    This also brings it more into line with other PD controls.
Commits on Jan 22, 2016
  1. Set up a basic theme testing framework

    It's hard to test something like a dark theme XML file without a way to
    toggle themes!  Time to finally put the Tools > Developers > Theme
    Editor menu to work.
    As various PD controls get migrated to the new theming engine, I'll add
    them to that dialog for testing.
  2. ButtonStrip UC: finish up work on theming integration

    I think this control is in a pretty good place now, with improved
    rendering across the board.  It's also been a good candidate for testing
    the updated theming engine, and it should be relatively straightforward
    to migrate the new techniques to other controls.
Commits on Jan 21, 2016
  1. ButtonStrip UC: implement bulk of new theming features

    The trusty horizontal "ButtonStrip" control has been the testbed for
    PD's capstone visual themes feature: determining UI colors from a
    standalone XML file, instead of hard-coding into the program.
    (Eventually, failsafes will be added to ensure said XML file exists and
    is valid, etc, but for now, do not do weird things like delete PD's
    /Themes subfolder).
    This is a cumbersome project because I need to rework most controls to
    optimize how theme-specific colors are retrieved and applied.  XML
    lookups are obviously slow inside of rendering code, so a new class -
    pdThemeColors - is used by each control to cache whatever color values
    they require.  Inside the rendering loop, that class returns needed
    colors very quickly, without having to touch their original XML
    definitions.  Similarly, if PD's visual theme is live-changed, the
    pdThemeColors class will handle caching the new colors, sparing the
    control from that kind of monotonous work.
    Similarly, a lot of PD's controls currently shortcut parts of the
    rendering process because the current "theme" decisions don't always
    require (for example) separate border and fill colors.  In an ideal
    world, however, these colors *could* be defined inside a theme file, and
    PD should automatically pick up the new definitions and render
    Finally, the actual theme file has to be slowly assembled according to
    the needs of each individual PD control, and color definitions have to
    be moved out of the code and into XML format.  This is a tedious
    process, but a necessary one for easily supporting dark themes (and
    other accessibility-friendly variants).
    There's still some clean-up to do on the buttonStrip implementation, but
    so far it's proven to be a solid testbed for finding weaknesses and
    problems in PD's existing theming code.  Once I'm confident that the new
    theming classes are all working as they should, I'll start converting
    PD's other custom controls to match.
  2. Ensure raised dialogs have their OK/Cancel buttons on-screen

    Thanks to Robert Rayment for reporting.  If the primary PD window is
    made very tiny and positioned off-screen (in the bottom-right corner,
    especially), raised dialogs may have their OK/Cancel buttons hidden
    PD will now ensure that OK/Cancel buttons are always on-screen for a
    newly raised dialog.
Commits on Jan 20, 2016
  1. Implement a bunch of theming code

    Work in progress.  User-facing changes in this commit are minimal.
    Apologies for the huge commit; other minor misc fixes are included here,
    but I've done a poor job of separating them out.  Theming code touches
    many, many parts of the program, so I'm fixing and cleaning-up quite a
    bit of code while implementing true theming support.
    The default theme file is also a WIP, obviously; values in this version
    exist only for testing purposes.
Commits on Jan 14, 2016
  1. Primary translation and theming functions: start code clean-up

    It's time to finally sit down and write PD's visual theming code.  A lot
    of (large, much-needed) changes are coming down the pipeline, and the
    first step is to remove all the old, redundant code from when PD only
    used common controls.
    This, combined with recent contributions from @Kroc, should make load
    time of complex dialogs noticeably better, particularly when
    translations are active.
    (Apologies for the extra case-related changes, uggggh VB)
  2. Merge pull request #179 from Kroc/master

    Add `iControlThemeable` interface
Commits on Jan 13, 2016
  1. @Kroc

    Add `iControlThemeable` interface

    Kroc committed
    Makes checking for controls that support PDs custom theming easy to maintain
  2. Adjustments > Photo > Red-eye: add antialiasing, performance improvem…

    There's more that could be done to improve this filter, but the code's
    become somewhat of a rat's nest, and integrating the tool into PD has
    taken way longer than I intended.  So I'm going to move on for now, with
    plans to revisit when things have quieted down a bit.
Commits on Jan 12, 2016
  1. Adjustments > Photo > Red-eye: additional features, fixes

    - User now has control over the eye classifier's shape and size
    thresholds (UI for these looks weird; I'll fix it soon)
    - Size and shape heuristics work much better now
    - Progress bar and messaging is now properly implemented
    - Misc clean-up and improvement
    Note that the quality is still poor on some photos and there are
    additional validation checks that need to be implemented.  These are on
    my to-do list.
Commits on Jan 11, 2016
  1. Adjustments > Photo > Red-eye: finish core correction framework

    This commit includes the dynamic region merge code that combines
    highlight and red-eye regions into contiguous "eye" shapes, as well as a
    basic implementation of the original paper's suggested correction
    algorithm (which I'm not thrilled with, but I'm still investigating
    There's still work to be done to make the result look "natural" (e.g.
    blending along rough edges), but as of this commit, the most troublesome
    portions of the algorithms are complete.
Commits on Jan 9, 2016
  1. Adjustments > Photo > Red-eye: add UI for user-controllable elements

    Also, there's a new option to reject non-circular red-eye regions; this
    helps mitigate the problem of false-positive bright red lips/lipstick.
Commits on Jan 8, 2016
  1. Adjustments > Photo > Red-eye removal: implement first stage false-po…

    …sitive removal
    This false-positive removal step works by comparing each potential
    red-eye region to the pixels surrounding it.  If a significant degree of
    pixel similarity is found (e.g. > ~10%), we discard the entire region,
    as we've probably found a skin or scenery element that's part of a
    larger pattern (vs a standalone eye or eye pair).
    This is arguably the most important false-positive removal stage, as
    1) Not prone to false-negatives
    2) Easy to implement a UI toggle for the method's sensitivity (as a
    failsafe only; the default value actually works very well)
    On my set of test images, this test removes 80-90% of false-positive
    Next up are additional checks for invalid region shapes and sizes, which
    are much easier to detect and remedy.
  2. Adjustments > Photo > Red-eye removal: implement region detection

    The hardest part of migrating this portion of the tool was optimizing it
    against very large images.  Performance should be pretty darn excellent
    at this point, regardless of image contents or size.
    Next up is migrating the set of checks that eliminate false-positive
    red-eye regions.
Commits on Jan 6, 2016
  1. Minor code cleanup for the new year

    Despite the number of files involved, this is a largely incidental
    commit (some copyright date changes, some reorganization, a few new
    modules, etc)...
  2. Red eye detection/correction: initial commit

    This tool is in the midst of a major migration from the project where I
    actually developed it, but I wanted to get this in-progress bit
    committed so others know PD's not dead.  The new year and some RL issues
    have interfered with my VB6 time over the past week, but I'm hopeful
    that things will improve as we move deeper into January.
    Anyway, my goal for PD is to support fully automated red-eye removal,
    without need for users clicking around the photo.  I've basically
    implemented a modified version of Microsoft's original white paper on
    automated red eye removal
    and am mostly optimizing and cleaning up the code as I migrate it into
    This will be a particularly neat addition to the program, as it involves
    dynamic region generation/analysis, which has many other potential uses
    (e.g. smart object identification/removal).
Commits on Dec 29, 2015
  1. pdListBox: integrate enough code to get project compiling again

    "One custom listbox to rule them all" is proving to be a long and
    arduous process.  Despite being unfinished, I'm committing here because
    I've got PD compiling again, and I need to integrate some other fixes
    into nightly builds.
Something went wrong with that request. Please try again.