Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У нее есть ToolTip, а при показе рамки он меняется на пояснение, отчего и для чего стоит нажать кнопку. Думаю, этого должно быть достаточно.

Можно ещё завести таймер и "трясти" кнопку ±3 пикселя вверх-вниз, вправо-влево

Здравствуйте, CEMb, Вы писали:

CEM>Можно ещё завести таймер и "трясти" кнопку ±3 пикселя вверх-вниз, вправо-влево

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, CEMb, Вы писали:

CEM>>Можно ещё завести таймер и "трясти" кнопку ±3 пикселя вверх-вниз, вправо-влево

ЕМ>Подозреваю, что это скорее насторожит и создаст опасение перед нажатием кнопки, нежели побудит ее нажать.
Как вариант есть еще два фокуса привлечь внимание
Вариант первый: Блинковать пару-тройку раз. Скрыть — показать. С каким нить таймаутом в 400 мс примерно.

Вариант второй: Тоже блинковать элементом, если он с текстом. Менять ему шрифт: стандартный (который был изначально), этот же но полужирный (FW_BOLD).

Помогает привлечь внимание пользователя.


Как-то так примерно

//функция потока блинкования элемента UI 
DWORD __stdcall BlinkProc_ByVisible(LPVOID lp)
{
    //const std::auto_ptr<BLINK_BY_VIS_PARAM> pParam((BLINK_BY_VIS_PARAM*)lp);

    //const HWND hwnd=(HWND)lp;
    //const HWND hwnd =pParam->hwnd;
        const HWND hwnd=(HWND)lp;
    ASSERT(IsWindow(hwnd));
    if (!IsWindow(hwnd))
        return 1;

    //if (pParam->nSleepBefore)
    //    Sleep(pParam->nSleepBefore);

    //if (!IsWindow(hwnd))
    //    return 1;
    
    enum {TMT_AFTERHIDE=100, TMT_AFTERSHOW=400};

    for(int i=0; i < 3; i++) {
        ::ShowWindow(hwnd,SW_HIDE);
        Sleep(TMT_AFTERHIDE);

        ShowWindow(hwnd,SW_SHOW);
        Sleep(TMT_AFTERSHOW);

        if (!IsWindow(hwnd))
            return 1;
    } 

    return 0;
}

//ну и запуск как-то так
void DoBlinkCtrl(const HWND hwnd)
{
DWORD tid;
const HANDLE hThread=CreateThread(NULL,0,BlinkProc_ByVisible,(LPVOID)hwnd,0,&id);
ASSERT(hThread);
if (hThread)
    CloseHandle(hThread);

}

PS: половина закоментирована, ибо код из реального проекта, там много чего добавляется по сути. Таймауты задержки, возможность дергать через сообщения внешний код перед блинковкой, способы отрисовки и после и.т.д.

Ну это детали и нюансы, суть та же.

Здравствуйте, Carc, Вы писали:

C> enum {TMT_AFTERHIDE=100, TMT_AFTERSHOW=400};

Хм, а какой смысл пару обычных констант с явными значениями определять через enum?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Carc, Вы писали:

C>> enum {TMT_AFTERHIDE=100, TMT_AFTERSHOW=400};

ЕМ>Хм, а какой смысл пару обычных констант с явными значениями определять через enum?
Code Style. Стив Макконнел.

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

Код яснее и понятнее.

Константы определены в одном месте, а не размазаны где-то по коду ниже. Такой код легко сопровождать\модифицировать. Не нужно копаться в кишках кода ниже, где суть вся. (SendMessage, Sleep). В моем случае ведь "кишки" и могут меняться: PostMessage вместо Send***, WaitForObject***, вместо Sleep и.т.д Но это детали. Они где-то там внизу кода. Суть вверху — все сразу ясно и понятно.

И потом: вот enum это RVALUE. Причем жесткий такой RVALUE. Здесь не получатся танцы с бубном, вроде const_cast, или взять адрес.

Простой пример: допустим такой таймаут должен передеваться как in параметр еще в какую функцию. Ок! Все передается, все зер-гут. Даже если мы забыли объявить нашу константу как const UINT наш_таймаут...

Дальше сосед по цеху, слегка по пьяни, меняет объявление своей функции. Теперь это не in, а in\out параметр.
И функция получает уже не константную ссылку на const UINT&, а просто ссылку UINT&.

Ну приспичило ему, рефакторинг-развитие-кода-in\out_параметр-все-дела — нужное подчеркнуть…
И упс, ранее наш работающий код летит в тартарары…

В случаем с enum такого не случится. Не скомилится и всё тут. Фига с два вы передадите enum как ссылку, или возьмете адрес ея. Ошибка компиляции. Шо гут, ибо код попросту не даст себя использовать неправильно.

PS: а вообще юзанье анонимного enum — великое дело для читабельности кода.
Яркий пример, который люблю юзать налево и направо в многопоточном коде, это ожидание на парочке-троечке-четверочке-[…,далее_везде] хендлов.

HANDLE hForWait[2];
hForWait[0]=hAppClosed;//некий внешний HANDLE, который сигналит фоновым потокам на предмет "хорош ждать", нечто вроде "пользователь закрывает приложение"
hForWait[1]=hПоСути_там_чего_то_где-то_ну_вроде_данные_с_сервера_пришли;

const DWORD dwWT=WaitForMultipleObjects(ARRAYSIZE(hForWait), hForWait,…);

//и вот тут вот уже нужно помнить, какой хендл сигналит\помер, какой хендл первый в массиве, какой второй - не дай бог ошибиться.
switch(dwWT) {
case dwWT-WAIT_FOR_OBJECT_0:
…
case dwWT-WAIT_ABANDONED_0 :
}

А можно переписать на enum именование.
Нужно всего лишь все аккуратно проинициализировать в начале, дальше код сам себя поддерживает

//в вот наш enum   для индексов массива хендлов, с говорящими названиями - какой хендл за что отвечает.
enum {H_APP_CLOSED=0, H_EVENT=1}
HANDLE hForWait[2];
hForWait[H_APP_CLOSED]=hAppClosed;//некий внешний HANDLE, который сигналит фоновым потокам на предмет "хорош ждать", нечто вроде "пользователь закрывает приложение"
hForWait[H_EVENT]=hПоСути_там_чего_то_где-то_ну_вроде_данные_с_сервера_пришли;

const DWORD dwWT=WaitForMultipleObjects(ARRAYSIZE(hForWait), hForWait,…);

//ВУАЛЯ
//все явно - и все видно!!! какой хендл просигналил
switch(dwWT - WAIT_FOR_OBJECT_0) {
case H_APP_CLOSED:
…
case H_EVENT:
}

Здравствуйте, Carc, Вы писали:

C>Следует избегать непонятных значений. В случае enum мы получаем те же же самые именнованные константы, которые явно своим именем говорят, за что они отвечают.

Так что мешает определить эти константы, как UINT const Name = Value? Для вящей каноничности можно добавить static.

C>Код яснее и понятнее.

С enum — ни разу. enum, по сути своей, предполагает именно перечислимые константы, отличающиеся друг от друга, конкретные значения которых обычно не важны. Конкретные значения обычно задаются для первой константы из какой-либо обособленной группы. enum, в котором все константы имеют конкретные значения, выглядит крайне странно.

C>И потом: вот enum это RVALUE. Причем жесткий такой RVALUE. Здесь не получатся танцы с бубном, вроде const_cast, или взять адрес.

Ну вот разве что. Но подобные ошибки крайне редки, стоит ли против них применять такие приемы?

C>Дальше сосед по цеху, слегка по пьяни, меняет объявление своей функции. Теперь это не in, а in\out параметр.
C>И функция получает уже не константную ссылку на const UINT&, а просто ссылку UINT&.

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

C>PS: а вообще юзанье анонимного enum — великое дело для читабельности кода.

Если я вижу enum, то, согласно его смыслу, предполагаю, что там будут определяться в первую очередь константы с различными значениями. То же самое будет предполагать и компилятор. Например, если две константы будут иметь одинаковые значения — он выдаст предупреждение. Другое предупреждение он выдаст, если в switch по enum-переменной обрабатываются не все определенные константы. В Вашем случае эти предупреждения придется подавить. Как предлагаете тогда бороться с кривыми руками "соседей по цеху"? По сути, Вы облегчаете отлов редких ошибок, открывая дорогу более частым.

C>//в вот наш enum для индексов массива хендлов, с говорящими названиями — какой хендл за что отвечает.
C>enum {H_APP_CLOSED=0, H_EVENT=1}

А здесь-то зачем явные значения? Как раз в этом примере enum следовало бы использовать в его родном виде.

Здравствуйте, Carc, Вы писали:

C>Как вариант есть еще два фокуса привлечь внимание

О, я вспомнил, как быстро и легко(ну, вроде) подкрасить кнопку:
1. Снять с кнопки битмап, через HDC/CreateCompatibleDC/BitBlt
2. Покрасить побайтово с нужным цветом, нужным алгоритмом (алгоритм могу предоставить).
3. Установит кнопке стиль, что она теперь кнопка с картинкой. Навешать получившуюся картинку.
4. После возвращения в нормальное состояние, не забыть почистить битмапу

Тут есть большой минус в том, что кнопка "перестанет" реагировать на мышку, внешне. Но можно исключить из картинки-иконки 2-3 пикселя от бордера, тогда всё будет ок. Будет как та же кнопка, только с красной, например, серединой.

Здравствуйте, CEMb, Вы писали:

CEM>О, я вспомнил, как быстро и легко(ну, вроде) подкрасить кнопку:

Спасибо! Однако, перечисленными способами выходит слишком много суеты, сопряженной с риском что-то испортить в навороченных визуальных темах. Красная рамка вокруг кнопки и в глаза бросается (вряд ли в каких-то темах будет ярко-красный фон, да и в этом случае можно поменять цвет на контрастный), и порождает желание навести на кнопку курсор, а там уж ToolTip подскажет, что и как.

Здравствуйте, CEMb, Вы писали:

CEM>Здравствуйте, Carc, Вы писали:

C>>Как вариант есть еще два фокуса привлечь внимание

CEM>О, я вспомнил, как быстро и легко(ну, вроде) подкрасить кнопку:
CEM>1. Снять с кнопки битмап, через HDC/CreateCompatibleDC/BitBlt
CEM>2. Покрасить побайтово с нужным цветом, нужным алгоритмом (алгоритм могу предоставить).
CEM>3. Установит кнопке стиль, что она теперь кнопка с картинкой. Навешать получившуюся картинку.
CEM>4. После возвращения в нормальное состояние, не забыть почистить битмапу

CEM>Тут есть большой минус в том, что кнопка "перестанет" реагировать на мышку, внешне. Но можно исключить из картинки-иконки 2-3 пикселя от бордера, тогда всё будет ок. Будет как та же кнопка, только с красной, например, серединой.

Не слишком ли для задачи "просто привлечь внимание"!?!


Да еще с косяками нюансами в сторону! Хренакс, с кнопыч перестал и вовсе реагировать на мыша?
а) Нюанс са-а-а-а-авсем не очевидный.

б) Возникнуть он может банальным и таким же малоочевидным косяком, вроде сбоя в районе восстановления исходного состояния. Т.е. не просто на время на мышь перестанет откликаться, а и вовсе навсегда…

в) Ну и к тому же еще "битмапить по черному", а это значит вперед — в режим ядра…

г) Ну и вообще… Как там насчет Бритвы нашего Оккамы? Не стоит множить сущности без надобности…

Я б поостерегся… Уж больно нарваться можно с таким кодом. Ни одна, и не две недели с отладчиком наперевес обеспечены.

С той же видимостью\невидимостью контрола\дочернего окна, хоть теоретически можно подстраховаться в стиле LockResource. Какой-нить банальный класс\struct с обязательным параметром HWND в конструкторе, который соответственно в деструкторе восстанавливает видимость окна.
В случае сбоя это все равно не спасет. Но хоть что-то…. В случае досрочного завершения функции "блинкования", не нужно хотя бы постоянно помнить, что нужно восстановить видимость контрола.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Carc, Вы писали:

C>>Следует избегать непонятных значений. В случае enum мы получаем те же же самые именнованные константы, которые явно своим именем говорят, за что они отвечают.

ЕМ>Так что мешает определить эти константы, как UINT const Name = Value?

Ничто не мешает и забыть указать этот самый const при объявлении.

С точки зрения компилятора здесь более чем всё идеально. Он и не пикнет даже, если забыли указать const. И потом Ваше забытая_const, уйдет по ссылке в код, который ее таки поменяет. И опять же компилятор не пикнет. Все идеально и корректно.

В случае enum неправильное использование невозможно. Компилятор сразу даст по рукам за такое.

ЕМ>Для вящей каноничности можно добавить static.
На кой фиг здесь static? Эти enum`ы — в моем варианте, или те же const — в Вашем. Определены внутри функции. И никак и никогда не смогут торчать наружу…

Я это вёл всё к тому, что ошибки делает в 999 из 1000 — человек, программист. Люди ошибаются — ничего не попишешь. В случае с enum — не даст компилятор ошибиться, и всё тут. Либо редизайнить код, и понимать что делаем и зачем. Либо использовать код только так, как задумано. Не выйдет использовать его криво, неправильно просто по невнимательности, спешки, рефакторинга или еще каким причинам.
Либо код работает правильно, либо не собирается.

Здравствуйте, Евгений Музыченко, Вы писали:


C>>И потом: вот enum это RVALUE. Причем жесткий такой RVALUE. Здесь не получатся танцы с бубном, вроде const_cast, или взять адрес.

ЕМ>Ну вот разве что. Но подобные ошибки крайне редки, стоит ли против них применять такие приемы?

Стоит! Еще как стоит…
Забыли указать const для нашего UINT. Ну бывает, всяко оно бывает. Стажер правил, все дела. Прогнали тесты, всё зер гут. И забыли. Ибо код-то, тривиальный, ну согласитесь. Кто его потом особо инспектировать будет, работает, и хорошо. Да и ломаться там (вроде бы) нечему.

А потом порефакторили, изменили какой-абстрактный код вовне, который изменит эту переменную с забытой const. И ку-ку… Выявлять этот косяк можно очень долго. Ибо неочевидный он очень. Сам код же явно в стиле MyUtilities, Helpers и.т.д и использоваться может откуда и когда угодно. А проблемы он создаст как раз в вызывающем коде. Ох, как можно потом покопаться, чтобы найти проблему.

И хорошо, если косячить будет через каждую секунду почти везде и всегда. А если в каком-то крайне редком случае, в крайне редкой конфигурации!?!

Здравствуйте, Carc, Вы писали:

C>Забыли указать const для нашего UINT.
C>А потом порефакторили, изменили какой-абстрактный код вовне, который изменит эту переменную с забытой const.

Сдается мне, что Вы преувеличиваете степень риска. Особенностей синтаксиса/семантики, при которых проблема возникает только при "встречных" ошибках в двух и более местах, найдется немало. Если уж заранее применять меры против гипотетических ситуаций, порожденных подобными "встречными" ошибками, то нужно делать анализ синтаксиса, перечислять все возможные сочетания, и блокировать каждое.

Здравствуйте, Carc, Вы писали:

C>Не слишком ли для задачи "просто привлечь внимание"!?!
Ну для меня этот алгоритм простой, я много с этим работал.

C> Да еще с косяками нюансами в сторону! Хренакс, с кнопыч перестал и вовсе реагировать на мыша?
C>а) Нюанс са-а-а-а-авсем не очевидный.
Не, на самом деле оно будет реагировать. Обычные кнопки с иконками делают картинке pop up, когда мышкой наводишься. Тут будет то же самое.

C>б) Возникнуть он может банальным и таким же малоочевидным косяком, вроде сбоя в районе восстановления исходного состояния. Т.е. не просто на время на мышь перестанет откликаться, а и вовсе навсегда…

C>в) Ну и к тому же еще "битмапить по черному", а это значит вперед — в режим ядра…
Нене какого такого ядра? Это же BM_SETIMAGE

C>г) Ну и вообще… Как там насчет Бритвы нашего Оккамы? Не стоит множить сущности без надобности…
Согласен. Я просто вспомнил ещё один способ. Не, кстати, вот ты смеёшься, а я когда скинил промышленный софт, мой манагер принёс новое MFC, которое умело "скинить кнопки просто". И была идея выкинуть все мои разработки и взять готовое. При внимательно рассмотрении оказалось что там ownerdraw.

C>Я б поостерегся… Уж больно нарваться можно с таким кодом. Ни одна, и не две недели с отладчиком наперевес обеспечены.
Ну у меня в этом опыт есть.

C>С той же видимостью\невидимостью контрола\дочернего окна, хоть теоретически можно подстраховаться в стиле LockResource. Какой-нить банальный класс\struct с обязательным параметром HWND в конструкторе, который соответственно в деструкторе восстанавливает видимость окна.
C>В случае сбоя это все равно не спасет. Но хоть что-то…. В случае досрочного завершения функции "блинкования", не нужно хотя бы постоянно помнить, что нужно восстановить видимость контрола.
Да, это тоже хороший вариант

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Carc, Вы писали:

C>>Забыли указать const для нашего UINT.
C>>А потом порефакторили, изменили какой-абстрактный код вовне, который изменит эту переменную с забытой const.

ЕМ>Сдается мне, что Вы преувеличиваете степень риска. Особенностей синтаксиса/семантики, при которых проблема возникает только при "встречных" ошибках в двух и более местах, найдется немало. Если уж заранее применять меры против гипотетических ситуаций, порожденных подобными "встречными" ошибками, то нужно делать анализ синтаксиса, перечислять все возможные сочетания, и блокировать каждое.

Вообще то "const UINT=…" это изначально и есть "заранее применять меры против"… Только Ваш вариант это полумеры. enum эти задачи решает полностью…

И синтаксический анализ здесь не поможет. Ибо изначально с точки зрения синтаксиса, что с const, что без — все как раз корректно.

Здравствуйте, Carc, Вы писали:

C>Вообще то "const UINT=…" это изначально и есть "заранее применять меры против"…

Добавление const лишь сообщает компилятору дополнительное свойство объекта, с какими-либо превентивными мерами оно прямо не связано.

Я не спорю с тем, что enum решает некоторые проблемы с возможными ошибками — говорю лишь о том, что непривычному глазу такие определение странно. Тогда уж лучше традиционные макросы, они понятнее, привычнее, и делают то же самое.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Carc, Вы писали:

C>>Вообще то "const UINT=…" это изначально и есть "заранее применять меры против"…

ЕМ>Добавление const лишь сообщает компилятору дополнительное свойство объекта, с какими-либо превентивными мерами оно прямо не связано.
Связано. Const объект нельзя изменить, или вызвать неконстантный его метод. По крайней мере без специальных приседаний.

ЕМ>Я не спорю с тем, что enum решает некоторые проблемы с возможными ошибками — говорю лишь о том, что непривычному глазу такие определение странно. Тогда уж лучше традиционные макросы, они понятнее, привычнее, и делают то же самое.
Какие еще макросы?
Это #define MY_VALUE наше_значение что ли?

Здравствуйте, Carc, Вы писали:

C>Связано. Const объект нельзя изменить, или вызвать неконстантный его метод.

Это следствие. Основное назначение — сообщить компилятору свойство объекта (неизменяемость).

C>Какие еще макросы?
C>Это #define MY_VALUE наше_значение что ли?

Ага.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Carc, Вы писали:

C>>Связано. Const объект нельзя изменить, или вызвать неконстантный его метод.

ЕМ>Это следствие. Основное назначение — сообщить компилятору свойство объекта (неизменяемость).
Та нет… Как раз таки неизменяемость объекта (логическая) это и есть назначение. А свойство: это как раз сообщить компилятору… Вот что компилятор с этим сообщением будет делать(или не делать) — это другой уже вопрос.

C>>Какие еще макросы?
C>>Это #define MY_VALUE наше_значение что ли?

ЕМ>Ага.
Ну да… Отличная просто идея. Вместо локальной области видимости, в данном случае функции распространить этот #define на всю единицу трансляции. Просто супер!

Никогда в библиотечном коде не видели чего-нибудь подобного?

…
#ifndef КАКАЯ_НИТЬ_WINDOWS_SDK_DEFINE_CONSTANT
enum {КАКАЯ_НИТЬ_WINDOWS_SDK_DEFINE_CONSTANT = конкретное_значение_скопипастенное_ручками_из_того_же_SDK};
#endif//#ifndef КАКАЯ_НИТЬ_WINDOWS_SDK_DEFINE_CONSTANT
…

Не осенял вопрос: почему именно анонимный enum, а не очередной #define?

Здравствуйте, Carc, Вы писали:

C>Никогда в библиотечном коде не видели чего-нибудь подобного?

Такого (через enum) — никогда. UINT const — видел.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Carc, Вы писали:

C>>Никогда в библиотечном коде не видели чего-нибудь подобного?

ЕМ>Такого (через enum) — никогда. UINT const — видел.
Это детали: enum или const UINT. Ни никаких #define