BackgroundColor/ForegroundColor у Button, входящей в состав MenuButton

[Андре]

Добрый день.

Можно ли как-то повлиять на внешний вид Button, входящей в MenuButton? Пока этот Button выглядит как кнопка - все работает, но как только он становится menu - нет. Это ограничение WinApi?

[kashperuk]

Посмотри вот этот проект
Изображения в Popup menu

Думаю поменять задний фон попап меню таким же образом можно без особых трудностей.

[blokva]

Цитата:

Сообщение от Андре

Добрый день.

Можно ли как-то повлиять на внешний вид Button, входящей в MenuButton? Пока этот Button выглядит как кнопка - все работает, но как только он становится menu - нет. Это ограничение WinApi?

Ага я уже задавал вопрос про картинку вместо/вместе текста . Похоже это ограничение Аксапты

[blokva]

Цитата:

Сообщение от kashperuk

Посмотри вот этот проект
Изображения в Popup menu

Думаю поменять задний фон попап меню таким же образом можно без особых трудностей.

А разве вопрос про PopUp menu?

[kashperuk]

Цитата:

Сообщение от blokva

А разве вопрос про PopUp menu?

Ну, на 100% не уверен - но уж очень мне похоже то меню, которое вылазит при клике на кнопке на обычное PopupMenu. Класс этот не используется, поэтому предполагаю, что строится оно ядром.
Но это все только предположения.

[AndyD]

Это не ограничение.
Axapta 3.0 использует стандартную отрисовку меню. Система по уполчанию просто заполняет фон меню определенным цветом (COLOR_MENU).
Для рисования в меню надо организовывать OwnerDraw-меню. Для этого необходимо обрабатывать сообщения окна-владельца меню WM_MEASUREITEM и WM_DRAWITEM.
Собственно, четверка это и делает. Это-же делается в проекте по ссылке Ивана

[Андре]

Цитата:

Это-же делается в проекте по ссылке Ивана

Ага. Спасибо.
Ты конечно крут, но использовать такую штуку ради моей маленькой задачи мне не хочется. Просмотр метода _privCreateWindowProc() добил меня.

  code  = @"538B5C2410568B742418578B7C241483FF2C740983FF2B0F8582000000A1" + #SETADDR(#OFFSET(#ImageListOffset));
    code += @"85C074798D4C2414518D5424205250FF15" + #SETADDR(#OFFSET(#ImageList_GetIconSizeOffset)) + @"83FF2C751C";
    code += @"833E01755E8B44241C8B4C241489460C8D47D55F894E105E5BC21000";
/*
08591000 53               push        ebx
    if ((uMsg == WM_MEASUREITEM || uMsg == WM_DRAWITEM) && ghImageList)
08591001 8B 5C 24 10      mov         ebx,dword ptr [esp+10h]
08591005 56               push        esi
08591006 8B 74 24 18      mov         esi,dword ptr [esp+18h]
...

[AndyD]

Немного С и все Ok

А проект - просто иллюстрация: Если нельзя, но очень хочется, то можно

[Андре]

Попробую развернуть вопрос другим ребром - творческим.

Задачка по usability.

Есть стандартная форма с кучей кнопок и выпадающих менюшек. В зависимости от тучи параметров часть из них становится enabled(true), часть - enabled(false). То есть, мы имеем стандартное поведение системы - с одной стороны, мы сужаем выбор пользователя, с другой стороны это еще одно кольцо защиты, чтобы пользователь не выполнил действие, которое он не должен выполнять в данном контексте.

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

Вопрос - Как можно решить эту проблему с минимум трудозатрат в Аксапте?

Вариант 1: Клавиша активна всегда. Если действие выполнять нельзя, мы просто раскрашиваем пункт меню сереньким, а по нажатию на клавишу выдаем пользователю осмысленное сообщение - "действие невозможно потому-то и потому-то, сделайте то-то и то-то". Мне этот вариант понравился, пока я не прикинул, сколько мне будет стоить его реализация и поддержка.

Вариант 2: Поиграться со всплывающей подсказкой, которая бы сообщала пользователю о причине неактивности данного пункта. Но это уже не столь очевидное действие для пользователя (навести мышь на неакивный контрол и подержать его там), особенно с учетом того, что ни одна форма в стандартной системе ничего в ответ на это действие не произведет.

Вариант 3 - ???

[Андре]

Цитата:

Немного С и все Ok

Это не просто C, это представление WinAPI в машинном коде, если я правильно понял. Ты уверен, что данный двочный код будет работать на всех существующих (и немножко будующих) версиях Windows? Если вся система свалится из-за того, что я решил менюшки украсить мне никто спасибо не скажет

[AndyD]

Ты не прав.
Машинный код - это результат компиляции в среде VisualStudio приведенных фрагментов C-шного кода. Так что система с таким же успехом может свалиться от любой dll или exe, скомпилированных в ней

Вообще, я проверял на XP prof (eng+rus) SP1, SP2. Win2003 (eng, rus) ent/std R2.

Да и не предлагал я тебе пользоваться этим кодом Просто прокомментировал исходный вопрос.

Что касается самой задачи - а чем не устраивает информация, выводимая в статусной строке? При движении по меню оно обновляется, так что можно сообщить что угодно.

[Андре]

Цитата:

Так что система с таким же успехом может свалиться от любой dll или exe, скомпилированных в ней

Хм... согласен

Цитата:

Что касается самой задачи - а чем не устраивает информация, выводимая в статусной строке?

Тем, что среднестатистические пользователи туда никогда не смотрят.

[belugin]

Я честно, говоря не видел нормального решения этой задачи даже не в Аксапте.

Может быть стоит как-нибудь иконку менять или приписывать * к тексту кнопки... тогда при наведении можно будет получить тултип. Но:

1. Тултип ограниченного объема
2. Сомневаюсь это это работает с менюбатонами