simon-git: putty (master): Simon Tatham

[Commits to Tartarus CVS repository.]

TL;DR:
  6163710 Fix accidental dependence on Windows API quirk in config box.

Repository:     git://git.tartarus.org/simon/putty.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2015-06-18 07:17:14

commit 6163710f043fb58fc80f6b45c14a92f7036bde75
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=6163710f043fb58fc80f6b45c14a92f7036bde75;hp=1eb578a488a71284d6b18e46df301e54805f2c35
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Jun 18 07:05:19 2015 +0100

    Fix accidental dependence on Windows API quirk in config box.
    
    Our config boxes are constructed using the CreateDialog() API
    function, rather than the modal DialogBox(). CreateDialog() is not
    that different from CreateWindow(), so windows created with it don't
    appear on the screen automatically; MSDN says that they must be shown
    via ShowWindow(), just like non-dialog windows have to be. But we
    weren't doing that at any point!
    
    So how was our config box ever getting displayed at all? Apparently by
    sheer chance, it turns out. The handler for a selection change in the
    tree view, which has to delete a whole panel of controls and creates a
    different set, surrounds that procedure with some WM_SETREDRAW calls
    and an InvalidateRect(), to prevent flicker while lots of changes were
    being made. And the creation of the _first_ panelful of controls, at
    dialog box setup, was done by simply selecting an item in the treeview
    and expecting that handler to be recursively called. And it appears
    that calling WM_SETREDRAW(TRUE) and then InvalidateRect was
    undocumentedly having an effect equivalent to the ShowWindow() we
    should have called, so that we never noticed the latter was missing.
    
    But a recent Vista update (all reports implicate KB3057839) has caused
    that not to work any more: on an updated Vista machine, in some
    desktop configurations, it seems that any attempt to fiddle with
    WM_SETREDRAW during dialog setup can leave the dialog box in a really
    unhelpful invisible state - the window is _physically there_ (you can
    see its taskbar entry, and the mouse pointer changes as you move over
    where its edit boxes are), but 100% transparent.
    
    So now we're doing something a bit more sensible. The first panelful
    of controls is created directly by the WM_INITDIALOG handler, rather
    than recursing into code that wasn't really designed to run at setup
    time. To be on the safe side, that handler for treeview selection
    change is also disabled until the WM_INITDIALOG handler has finished
    (like we already did with the WM_COMMAND handler), so that we can be
    sure of not accidentally messing about with WM_SETREDRAW at all during
    setup. And at the end of setup, we show the window in the sensible
    way, by a docs-approved call to ShowWindow().
    
    This appears (on the one machine I've so far tested it on) to fix the
    Vista invisible-window issue, and also it should be more API-compliant
    and hence safer in future.

 windows/windlg.c |   44 ++++++++++++++++++++++++++++++++++++++------
 1 file changed, 38 insertions(+), 6 deletions(-)