That's not the latest revision. Try again.

I am sorry. I was incorrect. It was revision 7420, not 7418. I see the revision numbers in TortoiseSVN, but I don't think to mentally track them like I probably should. Also, I will give the link to the image as hypertext instead of an "image," since that didn't work. I haven't shared through Google Drive before. The channel manager does not display properly. Revision 7420.

The only time it should look like that is when closing any open modules. Please give step-by-step instructions what you do to trigger it, and confirm that you have not modified the code in any way (I cannot give support for personal modified OpenMPT versions).

Steps to reproduce:

1. Open a module (new or preexisting).
2. Navigate to the patterns tab.
3. Open the channel manager.
   I had modified the code, but removed that copy and downloaded a fresh copy of the code. I got the same result. I tested both a 64-bit release build and a 32-bit debug build. They both yielded the same result. Also, with the debug build, I heard what might have been a Windows Error sound when closing the channel manager. The debug build also creates a new XM module and promptly closes it once I dismiss the compatibility dialog. You can download the files from the debug build from here. I hope that they help you diagnose the issue.

Works just fine here.

The debug build also creates a new XM module and promptly closes it once I dismiss the compatibility dialog.

That's just the test suite running through.

Works just fine here.

Hmm, strange
I don't often use the channel mnager or rename channels, so that doesn't affect my operations. It was simply an observation based on the new implementation.

That's just the test suite running through.

Ah
That does make sense.
Thanks for trying to help. I tried to help by sending debug files.

Please try an official test bild from https://buildbot.openmpt.org/builds/ to see if it also happens there.

I tried both the 32- and 64-bit test builds from The page to which you linked (revision 7423). Here is what I found.
On my tablet PC:

1. Upon opening, the channel manager looks as I showed.
2. It returns to normal when it loses focus.
3. Upon pressing the Windows key and the down arrow key, there is a pause. After that pause, the Windows "asterisk" sound is heard and the channel manager returns to normal.
4. Pressing again the combination above minimizes the channel manager and causes OpenMPT to become unresponsive.
   On my desktop:
5. Upon opening, the channel manager looks as I showed.
6. It does not return to normal upon losing focus.
7. Upon pressing the Windows key and the down arrow key, the channel manager minimizes. There is no pause (that I could detect) and I do not hear the Windows "asterisk" sound.
8. The application does not become unresponsive upon minimizing the channel manager. Performing minimize-maximize operations multiple time in succession works with no problems.
9. While the channel manager is in the unstable / "looks weird" state, there is a noticeable performance drop.
   Side note: Opening the channel manager multiple times in succession (at least, quick succession) doesn't work. (This occurs on both machines.)

It sounds like some assumption somewhere does not hold but MFC catches an error for us (and handles it badly) rather than passing it on.

Here are two more things to do:

1. Can you confirm that the latest revisions before r7418 do not have this issue?
2. Launch a debug build in Visual Studio, go to Debug -> Windows -> Exception Settings and enable "All C++ exceptions not in this list", ATL::CATLException and CException in that list. Then open the channel manager again and see if the IDE shows you which exception is thrown, and where.

I did not detect the issue in revision 7417.
It seems to occur first in revision 7418.

Program: ...\vs2015\..\..\bin\debug\vs2015-static\x86-32-win7\mptrack.exe
File: c:\users\caleb\saved games\modplug tracker source code (revision 7418)\mptrack\channelmanagerdlg.cpp
Line: 627

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
Debug Assertion Failed!

That is what I saw in the Output box. Incidentally, while the channel manager is open, the Windows Critical Stop sound continuously plays. It plays one last time when I stop debugging.

Can you try the same with r7426?

...or even better, try r7427 which should fix the minimized window issue.

Things that might help you:

1. 
   Program: ...\vs2015\..\..\bin\debug\vs2015-static\x86-32-win7\mptrack.exe
   File: c:\software\modplug tracker\source code\mptrack\channelmanagerdlg.cpp
   Line: 623

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
Debug Assertion Failed!

2. 

'mptrack.exe' (Win32): Loaded 'C:\Windows\SysWOW64\iertutil.dll'. Cannot find or open the PDB file.
'mptrack.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sxs.dll'. Cannot find or open the PDB file.
'mptrack.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ninput.dll'. Cannot find or open the PDB file.

3.

c:\software\modplug tracker\source code\mptrack\inputhandler.cpp(587): + 33459 debug: Changing command set. [CInputHandler::SetEffectLetters]
c:\software\modplug tracker\source code\mptrack\inputhandler.cpp(587): + 1248 debug: Changing command set. [CInputHandler::SetEffectLetters]

4.

c:\software\modplug tracker\source code\mptrack\inputhandler.cpp(587): + 69978 debug: Changing command set. [CInputHandler::SetEffectLetters]
c:\software\modplug tracker\source code\mptrack\inputhandler.cpp(587): + 3611 debug: Changing command set. [CInputHandler::SetEffectLetters]
c:\software\modplug tracker\source code\mptrack\inputhandler.cpp(587): +552029 debug: Changing command set. [CInputHandler::SetEffectLetters]
Debug Assertion Failed!

5.

Program: ...\vs2015....\bin\debug\vs2015-static\x86-32-win7\mptrack.exe
File: c:\software\modplug tracker\source code\mptrack\channelmanagerdlg.cpp
Line: 623

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
Debug Assertion Failed!

6. 

Exception thrown at 0x00007FF81DE57788 (KernelBase.dll) in mptrack.exe: 0x0EEDFADE (parameters: 0x0000000001D0A30E, 0x0000022B82470D50, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).

I saw all of those errors with both builds, aside from the exception, which I saw only in the 64-bit build. I do not remember seeing it in the 32-bit build, even though the anomalous behavior occurred in both builds.

That's strange. That failing assertion implies that the channel manager "sees" a different active document than the application itself, which really shouldn't be possible if you just open one document to reproduce this issue as you say.

Can you try adding the following line right before the MPT_ASSERT in line 623 and paste its debug output?

Log("[ChannelManager] %p, %p", m_ModDoc, CMainFrame::GetMainFrame()->GetActiveDoc());

When I debugged with that line inserted, I saw the lines below and several more lines that looked similar to them.
From the 32-bit build: ..\..\mptrack\channelmanagerdlg.cpp(623): + 57 debug: [ChannelManager] 08871040, 08871040 [CChannelManagerDlg::OnPaint]
From the 64-bit build: ..\..\mptrack\ChannelManagerDlg.cpp(623): + 57 debug: [ChannelManager] 0000025092D16070, 0000025092D16070 [CChannelManagerDlg::OnPaint]

So the two values are equal and yet the assertion in the line after them fires? Are the two values in the debug output always identical to each other?

I did find a mismatch in the each build.
From the 64-bit build: ..\..\mptrack\ChannelManagerDlg.cpp(623): + 1 debug: [ChannelManager] 0000026A4BDC7070, 0000000000000000 [CChannelManagerDlg::OnPaint]
From the 32-bit build: [code]....\mptrack\channelmanagerdlg.cpp(623): + 1 debug: [ChannelManager] 087EB040, 00000000 [CChannelManagerDlg::OnPaint]

Please test r7429.

Upon performing a subversion update operation, TortoiseSVN returned that ChannelManager.cpp had a conflict. Downloading a fresh batch of code worked with no problems.
In the solution from the update, line 623 of ChannelManager.cpp is blank. With the new batch of code, it reads int chnSizeY = client.Height() / (int)nLines;.
I looked for the assertion line (so I can put the Log line before it, as you had me do before), but it isn't found.
With the fresh batch of code, the 64-bit build throws the exception mentioned prior. But, along with the exception, I see a line that reads The thread 0x32d8 has exited with code 0 (0x0). and other lines similar to it while debugging is in progress. The 32-bit build also returns thread lines similar to the one in the previous statement. But, the exception line is not found in the debug output.

You were not supposed to re-insert that log line. The question is, does the channel manager display as intended now or not?
Threads exiting during execution are completely normal and irrelevant.

The issue does persist, to answer your question.

To hopefully get a clue about the exception in the win64 build, enable the exceptions from 0000894:0002768, and in addition to that also the "All Win32 exceptions not in this list" further down in the list.

Upon doing as you requested and debugging again, a dialog appears with the thrown exception. the code also navigates to line 478 of wincore.cpp. It reads: lResult = CallWindowProc(oldWndProc, hWnd, nMsg, wParam, lParam);

The line alone is not very interesting, since there are several possible paths leading to it - I need the complete call stack up to a function that's inside CChannelManagerDlg.

    KernelBase.dll!00007ff81de57788()   Unknown
    aimemb64.dll!0000000001d09a06() Unknown
    aimemb64.dll!0000000001d09a3c() Unknown
    aimemb64.dll!0000000001d0a30e() Unknown
    aimemb64.dll!0000000001d0a551() Unknown
    aimemb64.dll!0000000001ed9a2c() Unknown
    [External Code] 
>   mptrack.exe!_AfxActivationWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 478   C++

There is the call stack up to a white arrow (line 478 of ChannelManagerDlg.cpp).
KernelBase.dll!00007ff81de57788() Unknown: There is a yellow arrow on this line.

mptrack.exe!_AfxActivationWndProc(HWND * hWnd, unsigned int nMsg, unsigned int64 wParam, __int64 lParam) Line 478 C++: There is a white arrow similar to those seen on Enter keys on this line.

I need the part below _AfxActivationWndProc, not above. I already knew we are in there. Just post the full stack trace, I will pick out the interesting stuff then.
However, that part of the stack trace is also interesting. It suggests that you use a tool named "Actual Window Manager" and it might be why I cannot reproduce those problems. Can you confirm that you use that tool?

    KernelBase.dll!00007ff81de57788()   Unknown
    aimemb64.dll!0000000001d09a06() Unknown
    aimemb64.dll!0000000001d09a3c() Unknown
    aimemb64.dll!0000000001d0a30e() Unknown
    aimemb64.dll!0000000001d0a551() Unknown
    aimemb64.dll!0000000001ed9a2c() Unknown
    [External Code] 
>   mptrack.exe!_AfxActivationWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 478   C++
    [External Code] 
    mptrack.exe!CWnd::SetWindowPos(const CWnd * pWndInsertAfter, int x, int y, int cx, int cy, unsigned int nFlags) Line 317    C++
    mptrack.exe!CSplashScreen::OnInitDialog() Line 1553 C++
    mptrack.exe!AfxDlgProc(HWND__ * hWnd, unsigned int message, unsigned __int64 __formal, __int64 __formal) Line 28    C++
    [External Code] 
    mptrack.exe!CWnd::DefWindowProcA(unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 1094  C++
    mptrack.exe!CWnd::Default() Line 299    C++
    mptrack.exe!CDialog::HandleInitDialog(unsigned __int64 __formal, __int64 __formal) Line 721 C++
    mptrack.exe!CWnd::OnWndMsg(unsigned int message, unsigned __int64 wParam, __int64 lParam, __int64 * pResult) Line 2420  C++
    mptrack.exe!CWnd::WindowProc(unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 2078   C++
    mptrack.exe!AfxCallWndProc(CWnd * pWnd, HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 265 C++
    mptrack.exe!AfxWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 418  C++
    [External Code] 
    mptrack.exe!IsolationAwareCreateDialogIndirectParamA(HINSTANCE__ * hInstance, const DLGTEMPLATE * lpTemplate, HWND__ * hWndParent, __int64(*)(HWND__ *, unsigned int, unsigned __int64, __int64) lpDialogFunc, __int64 dwInitParam) Line 547    C++
    mptrack.exe!CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate, CWnd * pParentWnd, HINSTANCE__ * hInst) Line 358  C++
    mptrack.exe!CDialog::CreateIndirect(const DLGTEMPLATE * lpDialogTemplate, CWnd * pParentWnd, void * lpDialogInit, HINSTANCE__ * hInst) Line 260 C++
    mptrack.exe!CDialog::CreateIndirect(void * hDialogTemplate, CWnd * pParentWnd, HINSTANCE__ * hInst) Line 237    C++
    mptrack.exe!CDialog::Create(const char * lpszTemplateName, CWnd * pParentWnd) Line 219  C++
    mptrack.exe!CDialog::Create(unsigned int nIDTemplate, CWnd * pParentWnd) Line 585   C++
    mptrack.exe!StartSplashScreen() Line 1571   C++
    mptrack.exe!CTrackApp::InitInstance() Line 1137 C++
    mptrack.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 37    C++
    mptrack.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 26   C++
    [External Code]

There is the full stack Trace for you.

That stacktrace suggests that you already get the exception while the splash screen is showing, not the channel manager. But since the program does not actually crash, maybe it's not relevant. Maybe it is. It's hard to tell. I think it all boils down to this "Actual Window Manager" thing though. Can you please confirm that you are using this software? If so, can you check if running Windows without "Actual Window Manager" shows the channel manager as expected?

In addition to what I wrote above, try the following:
In ChannelManagerDlg.cpp, right after the line that says "// Window height is not sufficient => resize window", insert this:
ValidateRect(nullptr);

Prior to adding the suggested line: With Actual Window Manager exited, the exception is not thrown and the channel manager behaves as expected. Upon launching Actual Window Manager, the exception is thrown immediately. Even with Actual Window Manager paused, the exception is thrown. Actual Window Manager must be exited before the exception is not thrown.
After adding the suggested line: This did not change the behaviors mentioned above.

So we have found the culprit, it's just not clear yet why it does not like the changes. Try adding the following line instead:
CDialog::OnPaint();

And if that still doesn't work, try this instead:

PAINTSTRUCT pDC;
::BeginPaint(m_hWnd, &pDC);
::EndPaint(m_hWnd, &pDC);

I assume that, by "instead," you mean replace the line that didn't help.

it's just not clear yet why it does not like the changes.

I agree completely.
With the single line: The exception is still thrown.
With the 3 lines: I assume that all 3 lines need to go just below the comment (instead of the first 2 going there and the third line (EndPaint…) going just before the return). I debugged with EndPaint just before the return as well as all of the lines being together. The exception is still thrown in both cases.

At this point I am pretty much out of ideas. Even if we find a solution, I think you should try sending the executable to the Actual Window Manager developers and tell them that their program is messing up other programs that run just fine otherwise (with included steps how to reproduce the issue with and without their software running). It's not our job to work around software that hijacks our window procedure.

I have installed Actual Window Manager into a virtual machine. What I have found is that it seems to intercept the SetWindowPos call in CChannelManagerDlg::OnPaint and immediately causes the window to re-paint before even setting the intended window size. This causes an infinite loop and as a consequence probably a stack overflow, which is why you heard the constant error sound.
Only by lucky coincidence this did not happen before, and while OpenMPT does something suspicous here (resizing the window while it is being drawn), it's clearly an sisue in AWM that needs to be fixed.

r7430 should hopefully fix the issue even with AWM enabled. Still, you should send one of the faulty EXE files to them as their code is broken.

Thank you for trying to help. It seems that, as you allude to in your note, the issue is out of your control and unrelated to your code. You have probably done as much troubleshooting as you can with your code. I guess that it is time to close this case. I will try something within Actual Window Manager to see if it helps (that is: make an exception for the channel manager and, perhaps, ModPlug Tracker entirely). But, there is probably nothing more that you can do. Thank you, again, for trying to help.

I tested a 64-bit release build and the channel manager worked with no problems. You can disregard my previous note. I submitted it before I saw your 2 notes before it. The issue is resolved in revision 7430.