Способ гарантировать, что значок системного лотка удален гарантируемый …
Если мы забудем все остальные соображения и сконцентрируемся на этом конкретном ракурсе, как вы предложили, то я бы сказал, что если ваш клиент собирался сделать N вызовов для возврата тех же данных в любом случае (скорее чем разбить на страницы и запрашивать следующую страницу только тогда, когда этого требует пользователь), то в большинстве случаев предпочтительнее сделать один вызов, но не во всех случаях (т. е. когда полезные нагрузки очень велики).
Насколько большой очень большой? Среди прочих факторов, это зависит от того, находятся ли ваши потребители в одной сети с внешней сетью.
Факторы , поддерживающие большую полезную нагрузку:
- Уменьшает сетевой трафик и задержку (т. Е. Туда и обратно, связанные с «N» вызовами).
- Потребителям не нужно беспокоиться о слиянии и обработке данных.
- Обычно легче обрабатывать ошибки, так как потребители будут иметь дело с одним ответом, а не с несколькими вызовами, которые могут оказывать влияние друг на друга.
Факторы против больших полезных нагрузок:
- Если время отклика для большой полезной нагрузки считается медленным, то вы заставите своих потребителей ждать просмотра результатов. С помощью вызовов «N» вы можете начать отображать результаты, пока вы все еще загружаете данные. Это может повлиять на пользовательский опыт.
- Если вызов не выполняется на полпути, и у вас нет встроенной отказоустойчивости и непрерывности, вам придется воспроизводить большую полезную нагрузку, что заставляет потребителя ждать дольше. Это может быть важным фактором, если ваша полезная нагрузка очень велика.
- Опять же, если ваша полезная нагрузка очень велика, тогда вызовы «N» имеют смысл, поскольку потребители могут одновременно инициировать несколько запросов и быстрее получать данные.
Как я уже упоминал выше, нужно учитывать множество факторов, и мой ответ, вероятно, слишком ванильный, но, надеюсь, он даст вам представление о том, как к этому можно подойти.
6 ответов
Другая вещь, на которую большинство программистов забывает проверять, состоит в том, если проводник перезапускает/разрушает. Его хорошее, если дескриптор приложения это и воссоздают его собственный значок.
Просто проверьте на сообщение WM_TASKBARCREATED и воссоздайте значок.
У Вас могли быть отдельное, более простое (и таким образом по-видимому, более устойчивый) программа, которая контролирует Ваше приложение. Эта программа могла на самом деле запустить Вашу программу и затем контролировать процесс. Да, это - очень ужасное решение.
Лично я использовал бы Векторный обработчик исключений. Да, это основано на SEH, но Вы не должны иметь дело со всем другим стеком, который Вы, возможно, должны были бы раскрутить.
TerminateProcess (), должен более разрушительный. Вы действительно не можете охранять себя против этого; когда это происходит, Ваш процесс мертв. Никакие инструкции по руде не обрабатываются, таким образом, не имеет значения, какой код там находится в Вашем приложении.
Внешнее приложение действительно не помогло бы, не так ли? Это также могло отказать или быть уничтожено.
Хм, у Вас может всегда быть вызов процесса внешнего монитора SendMessage с сообщением WM_PAINT к окну системного лотка (который необходимо было бы сделать на основе класса окна). Это должно удалить значок, который больше не действителен.
Необходимо обработать выход приложений при катастрофическом отказе некоторого пути, или другой или значок не исчезнут.
Проверьте это, если это может быть какая-либо справка: http://www.codeproject.com/KB/shell/ashsystray.aspx
Можно использовать SetUnhandledExceptionFilter для ловли катастрофического отказа. Я обычно использую его для создания файла дампа катастрофического отказа так, чтобы катастрофический отказ мог быть отлажен, но нет никакой причины, Вы не можете так некоторая простая очистка как удаление значков панели задач.