#583 MESSAGEBOX has repainting problems when scrolling after 8.1.0

[David Costanzo]

MESSAGEBOX adds a vertical scrollbar if it is given more text than can be shown on the screen at a time. As of FMSLogo 8.2.0, if you scroll down, there are repainting problems and the text becomes garbled.

How Reproducible:
Every Time

Steps to Reproduce:
1) Run MESSAGEBOX with a message body that has more lines of text than can be shown on the screen. For example

MESSAGEBOX [MessageBox Repro] MAP [ WORD ? CHAR 10 ] ISEQ 1 100

2) Slide the vertical scrollbar downward to the bottom.

Expected Result:
You see the text of the scrollbar at the bottom. In this case, the last part of the sequence of numbers from 1 - 100. See "expected-result-8.1.0.png".

Actual Result:
You see the text of the scrollbar at the bottom. In this case, the last part of the sequence of numbers from 1 - 100. See "actual-result-8.1.0.png".

[David Costanzo]

This seems to have been introduced by disabling UAC Virtualization in [r5749]. I don't know why disabling UAC Virtualization would cause this, but disabling UAC Virtualization is the right thing for FMSLogo, so I'd rather find a way to fix wxWidgets to be not require UAC Virtualization than to re-enable it.

[David Costanzo]

After some experimentation, simply adding a manifest to fmslogo.exe causes the problem, not disabling UAC Virtualization (which happens to be done by adding a manifest). Adding a manifest might implicitly opt-in to other behavior, but I haven't figured out the manifest syntax for opting-out of everything except UAC Virtualization.

[David Costanzo]

I have committed a fix for this in [r5899]. It will be fixed in whatever version follows 8.3.1. I expect to release this as a micro-version (8.3.2) since it was a recent regression.

The problem seems to have been that, by adding a manifest to disable UAC Virtualization, I implicitly said "I don't care what version of my dependent DLLs you use". However, wxMessageBox cares very much, as it modifies the dialog box that Windows shows, removing a STATIC control and replacing it with an EDIT control, if the dialog box is too large. If I had known it had this sort of dependency on undocumented behavior of ::MessageBox(), I would not have used it.

The fix was to add a <dependency> element within the manifest. This was copied from the manifest which the wxWidgets samples use:

  <dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="X86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
  </dependency>

This bug may return if FMSLogo a 64-bit version of FMSLogo is released, in which case the fix would either be to rewrite lmessagebox to not use wxMessageBox or to use whatever manifest wxWidgets uses for x64.