Использование манифеста приводит к тому, что окно остается частично пустым - PullRequest
Новая
       50

Использование манифеста приводит к тому, что окно остается частично пустым

0 голосов
/ 24 сентября 2010

Я пытаюсь сделать так, чтобы приложение, большая часть его разработки выполнялась в Visual C ++ 6.0, соответствовало тематике Windows, или, если быть точным, его аспект визуальных стилей.Рассматриваемое приложение является приложением MFC с набором символов MBCS.Прежде всего, для того, чтобы начать игру, потребовался трюк InitCommonControlsEx(...); в сочетании с соответствующими манифестами для Common Controls 6.0.Пока ничего особенного.

После всего этого у меня есть тонны окон, на которых видны некоторые глюки рисования - белые прямоугольники на фоне, где раньше был серый, как в остальной части окна, но они не мешают.

Самый большой источник проблем - потомок CDialog, который реализует (архаичный) диалог подсказки «знаете ли вы ...».Он отказывается рисовать что-либо кроме кнопок, флажков и декоративной рамки в тот момент, когда манифест находится на месте.Однако, если я возьму манифест OUT, все будет нормально.

Сравнение изображений сразу после вызова диалога

Я уже прошел через код OnPaint (которыйрисует значок и текст «Знаете ли вы», и все функции возвращают разумные и успешные значения. Я также попытался удалить целые биты, выбранные пользователем (закомментировал отображения для сообщений WM_PAINT и WM_CTLCOLOR), но даже это вызвалонечего показывать или действовать иначе.

После того, как я нажму кнопку «Следующий совет», он будет правильно нарисовать следующий совет в списке. Однако заголовок customdrawn сзначок лампочки по-прежнему отсутствует.

Код на самом деле не делает ничего особенного, что я могу заметить, и я в растерянности. Поскольку я подозреваю, что определение диалога наиболее полезно, я добавлю это, хотя я могупубликуйте другие вещи, если у людей есть идеи о том, где скрываются проблемы. 

IDD_TIP DIALOG DISCARDABLE  0, 0, 231, 164
STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Tip of the Day"
FONT 8, "MS Sans Serif"
BEGIN
    CONTROL         "",IDC_STATIC,"Static",SS_BLACKFRAME,12,11,207,123
    LTEXT           "Some String",IDC_TIPSTRING,28,63,177,60
    CONTROL         "&Show Tips on StartUp",IDC_STARTUP,"Button",
                    BS_AUTOCHECKBOX | WS_GROUP | WS_TABSTOP,13,146,85,10
    PUSHBUTTON      "&Next Tip",IDC_NEXTTIP,109,143,50,14,WS_GROUP
    DEFPUSHBUTTON   "&Close",IDOK,168,143,50,14,WS_GROUP
    CONTROL         "",IDC_BULB,"Static",SS_BITMAP,20,17,190,111
END

Машина, на которой я тестирую это, - это 64-битная машина W7 с VS2010,Само рассматриваемое приложение является 32-битным.

Редактировать:

Новый день предоставляет новые идеи.Почему-то проблема связана с обработкой сообщения WM_CTLCOLOR.Когда я установил его на возвращение NULL_BRUSH, я наконец увидел, что что-то нарисовано (это, конечно, размыто поверх другого после первоначального рисования).Прибавляя это еще дальше, кажется, что когда nCtlColor == CTLCOLOR_STATIC, если я верну NULL_BRUSH, вещи будут отображаться.Однако, в тот момент, когда я делаю это WHITE_BRUSH, ничто не обращается снова.

Оригинальный код: 

HBRUSH CTipDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
    if (pWnd->GetDlgCtrlID() == IDC_TIPSTRING)
        return (HBRUSH)GetStockObject(WHITE_BRUSH);
<b>    else if (nCtlColor == CTLCOLOR_STATIC)
        /* Visual styles enabled causes the things we draw in our WM_PAINT
         * to get cleared (and not redrawn) if we do not use a hollow brush here.
         * Likely the default behaviour differs when using theming. */
        return (HBRUSH)GetStockObject(HOLLOW_BRUSH);
</b>        
    return CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
}

Проблема решена!Жирные строки - это то, что я изменил, чтобы исправить мою проблему, включая обязательные комментарии.:)

1 Ответ

1 голос
/ 24 сентября 2010

Насколько я знаю, версия 6 Common Controls официально поддерживает только Unicode.

Согласно записи в блоге Раймонда Чена , эти элементы управления работают с набором символов ANSI до определенной степени, но только по причинам обратной совместимости. Никто не должен использовать это намеренно.

Если вы используете приложение ANSI и создаете элементы управления из библиотеки общих элементов управления, вы можете столкнуться со странным поведением. В основном это сработает, но на периферии все может быть странно.

...

И это означает, что все вы, люди, которые используют версию 6 общих элементов управления, но не конвертировали в Unicode, полагаются на лазейку совместимости. Поддержка ANSI существует для старых программ, которые думали, что общаются с общим контролем версии 5; это не для вас.

Я никогда не пытался делать такие вещи, поэтому не могу сказать наверняка, но вы можете столкнуться с некоторыми из этих "странных действий". Если это так, то единственными официально поддерживаемыми вариантами будет либо преобразование в Unicode, либо возврат к использованию версии 5 элементов управления. В противном случае вам придется искать обходные пути для любого странного поведения, которое вы можете найти, и это не похоже на хорошую ситуацию.

...