engine
9th May 2007 14:30 UTC

A small redraw issue of MakensisW's SettingsDialog
I want to feed back a small bug in MakensisW. (Maybe it's not MakensisW's fault.)

When you:
1. run a new instance of Makensisw.exe ...
2. Open the [settings] dialog of the makensisW...
3. (Without any other window-views switching.)Move the [settings] dialog to a right-top position, but here, donnot let the entire dialog region move away from the display area of it's parent window(the MakensisW main window).

Then the bug here:
A transparent window area appears, Please just look at my screenshot in the attachment.


Excuse for my poor English description.:p

engine
9th May 2007 14:37 UTC

Precondition:
Disable the MS-Windows appearance effect [Show Window contents while dragging]...

engine
13th May 2007 15:55 UTC

//global var flag.
static fRedraw = TRUE; //Flag -> only handle at first time.

//intercept the WM_MOVE message in SettingsProc()...
//and both in SymbolSetProc().

case WM_MOVE:
                        
{
        if(fRedraw)
        {
                fRedraw=FALSE;

                InvalidateRect(hwndDlg,NULL,TRUE);
                SendMessage(hwndDlg,WM_NCPAINT,1,0);
        }

        break;
}

kichik
13th May 2007 19:31 UTC

I can't reproduce this with or without the "Show window contents..." effect. Can you reproduce this on more than one computer? Are you sure it's not a result of a buggy display driver or some other program that might be messing with the display? SettingsProc, which handles all the messages of the settings dialog, always returns FALSE which lets the default Windows dialog procedure handle everything, including drawing, with the defaults.

demiller9
13th May 2007 22:20 UTC

I reproduced this error the other day on Windows 2000, but it won't do it today (at home) on Windows XP SP2.

Don

kichik
13th May 2007 22:37 UTC

I can't reproduce on either Windows NT4 or XP and that screenshot was taken on XP.

engine
14th May 2007 01:55 UTC

Originally posted by kichik
I can't reproduce this with or without the "Show window contents..." effect. Can you reproduce this on more than one computer? Are you sure it's not a result of a buggy display driver or some other program that might be messing with the display?

Originally posted by kichik SettingsProc, which handles all the messages of the settings dialog, always returns FALSE which lets the default Windows dialog procedure handle everything, including drawing, with the defaults.

engine
14th May 2007 02:44 UTC

Oh, I think of something.
All those computers with this problem have the UXthemePatcher installed in order to apply third party themes.
Maybe... Can this be the cause?

engine
14th May 2007 04:23 UTC

I am sorry to tell that UXthemePatcher is not the real cause of it.

I just reproduced the issue on two other computers.

One with Win2000:

The other with WinXp(without UXthemepatcher):

kichik
14th May 2007 18:50 UTC

I can't get the pictures you've uploaded. Try using stashbox.org instead. Or do they all just show the white rectangles on different OSes?

Have you tried reproducing this in safe mode on a computer that exhibits the problem? That should narrow down the search.

I also haven't asked the obvious - does this happen with any other dialogs or programs?

engine
15th May 2007 06:53 UTC

There must be something wrong with my blog server these days.
Yeh, those pictures show the issue on different OSes,
they have been reuploaded to stashbox.org.

one picture at #6 & two pictures at #8

Comm@nder21
15th May 2007 18:23 UTC

what about switching makensisw to wxwidgets, like nsismenu? :)

it needs some work anyway, because of the lack of support for the new /p switch.

kichik
15th May 2007 18:25 UTC

Try the attached version. It may have redrawing issues with resizing.

engine
16th May 2007 03:48 UTC

Hi, kichik.

Yeah, thanks.
However, this version still has redrawing issues on that settings dialog.

Intercept the WM_MOVE message in SettingsProc() and SymbolSetProc(), and do once-redrawing works.
This will be a solution of the very problem.

engine
16th May 2007 03:57 UTC

And...the compiled makesisw.exe.

kichik
16th May 2007 18:12 UTC

Responding to WM_MOVE with a redraw is not an acceptable solution. It only masks the real problem of improper drawing.

Try this one.

engine
17th May 2007 00:55 UTC

I'm sorry. No improvement.:weird: