Переключить использование оператора - PullRequest
2 голосов
/ 05 апреля 2009

Должен ли я использовать эту форму оператора switch:

  switch(msg)
  {
    case WM_LBUTTONDOWN:
    {
           char szFileName[MAX_PATH];
           HINSTANCE hInstance = GetModuleHandle(NULL);
           GetModuleFileName(hInstance, (LPWCH)szFileName, MAX_PATH);
           MessageBox(hwnd, (LPCWSTR)szFileName, L"This program is:", MB_OK | MB_ICONINFORMATION);
    }
    break;

    case WM_CLOSE:
        DestroyWindow(hwnd);
    break;
    case WM_DESTROY:
        PostQuitMessage(0);
    break;
    default:
        return DefWindowProc(hwnd, msg, wParam, lParam);
  }
  return 0;

или сделать функцию для первой константы регистра?

Ответы [ 10 ]

9 голосов
/ 05 апреля 2009

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

5 голосов
/ 05 апреля 2009

Кроме того, взгляните на взломщики сообщений

3 голосов
/ 05 апреля 2009

Что вы собираетесь делать, когда будет 20 или 50 оконных сообщений?
Может быть, настало время создать карту - события на функции (фукторы) и вызвать их?
Или начните использовать правило - одно сообщение = один вызов функции.


char szFileName[MAX_PATH];
HINSTANCE hInstance = GetModuleHandle(NULL);
GetModuleFileName(hInstance, (LPWCH)szFileName, MAX_PATH);
MessageBox(hwnd, (LPCWSTR)szFileName, L"This program is:", MB_OK | MB_ICONINFORMATION);

Не могли бы вы объяснить этот странный трюк с конвекцией (LPCWSTR) szFileName. Почему вы не используете массив wchar_t вместо приведения? - у вас будут большие проблемы с длинными путями (длина_пути> MAX_PATH / sizeof (wchar_t))

Один совет - избегайте использования слепков в целом и бросков в стиле C, в частности.

2 голосов
/ 05 апреля 2009

Если вы спрашиваете, следует ли превратить код в первом случае в функцию, тогда да, определенно.

1 голос
/ 05 апреля 2009

Я, вероятно, объявил бы карту и использовал бы функторы для каждого сообщения:

typedef std::map<UINT, boost::function<int (HWND, WPARAM, LPARAM) > > messageFuncs_t;
messageFuncs_t messageFuncs;

Затем, когда класс окна создан, просто добавьте новую функцию для каждого сообщения:

messageFuncs[WM_LBUTTONDOWN] = &onMouseDownEvent;

... А затем реализовать цикл сообщений следующим образом:

messageFuncs_t::iterator fun = messageFuncs.find(msg);
if(fun != messageFuncs.end())
    return (*fun)(hWnd, wparam, lparam);
else
    return DefWindowProc(hWnd, msg, wp, lp);

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

1 голос
/ 05 апреля 2009

Одной из самых важных вещей, которые я бы сказал, была последовательность. Если вы создаете функцию для LBUTTONDOWN, тогда создайте функцию для всего. Таким образом, существует предсказуемая схема, где найти материал, если он сломается.

Связанные с данной темой:

Лично я нахожу шаблон if / else if для лучшей работы, так как он устраняет проблему забытого разрыва:

if (msg == WM_LBUTTONDOWN) {
    // your code here
    return 0;
} else if (msg == WM_DESTROY) {
    PostQuitMessage(0);
    return;
} else if (msg == WM_KEYDOWN) {
    if (wp == VK_F1) {
        DoSomething();
        return;
    }
}
return DefWindowProc(hWnd, msg, wp, lp);

В конце концов, все зависит от вас.

1 голос
/ 05 апреля 2009

Ну, это будет зависеть от того, сколько других случаев у вас будет.

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

0 голосов
/ 05 апреля 2009

Я пишу довольно много взломщиков сообщений Win32, таких как эти ключи.

Мое эмпирическое правило таково: подключение поведения переходит в переключатель, поведение - в отдельную функцию. Обычно это означает, что коммутатор содержит решение о том, должна ли обрабатываться эта команда (например, проверка идентификатора отправителя), и "симпатичная" настройка параметров.

Так что в данном конкретном случае это отдельная функция.

Первоначальная мотивация заключается в том, что я часто в конечном итоге вызываю поведение в других обстоятельствах (например, «когда имя файла не указано и диалог вызывается с параметром moon, установленным в full, немедленно показывает диалог SaveAs «).

0 голосов
/ 05 апреля 2009

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

Также bb прав, в этом случае вам следует использовать массив wchar_t вместо char.

0 голосов
/ 05 апреля 2009

Вы пропускаете перерыв в первом случае . Кроме этого, я бы определенно поместил этот код в отдельную функцию.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...