Отключение визуальных диалогов об ошибках для фоновых приложений

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

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

Опасайтесь вторичных исключений

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

try
  Query.Delete; // - здесь возбуждается исключение
except
  Query.Transaction.Rollback;
  ShowMessage('Sorry, could not delete the report');
  Exit;
end;

Что происходит? Неужели EurekaLog игнорирует код пользователя?

Работа с криптографией в EurekaLog

EurekaLog - это трейсер исключений, т.е. инструмент, который устанавливает хуки и перехватывает возбуждение исключений, позволяя создать отчёт по необработанным исключениям. Тем не менее, в ней есть различного рода дополнительная функциональность, которую вы можете использовать в своих программах. И одной из таких возможностей являются функции криптографии.

Даже в пустых приложениях есть баги

С нами связался человек, который утверждал, что нашёл баг в EurekaLog. Он обосновал это утверждение следующим образом: если создать новое приложение DataSnap и добавить в него EurekaLog, то приложение вылетит с Access Violation при выходе.

Полиморфизм на практике - "как"

Товарищи, я тут нашёл в черновиках статью аж от 2013 года. Публикую.

Статья написана сразу после "Дружественность" в Delphi. Статья является логическим продолжением серии переводов Полиморфизм ad nauseum и последующего обсуждения в Delphi-блогах.

За давностью лет я уж и забыл, почему она в черновиках. Возможно, не всё сказал, что хотел. Может, творческий запал оборвался. А может, местами коряво получилось, не вычитал. Там в конце было что-то про журнал - возможно, я планировал опубликовать это в журнале. Также, материал про соединение потоков и файлов планировался в серию про сериализацию. Сырцы к статье чудом нашёл в бэкапе проектов. Короче, сделайте скидку.

---

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

Интерпретируйте результаты экспериментов правильно

К моему переводу статьи Руди о String и PChar добавили замечательный комментарий, на который мне хотелось бы ответить, но объём заблуждений не позволяет это сделать простым ответом в комментарии.

Не используйте относительные имена файлов

Доступ к файлу можно получить по абсолютному или относительному имени (пути).

Абсолютное ("полностью квалифицированное") имя начинается с имени диска или сервера и указывает все компоненты пути, например: "C:\Projects\TestProject\Data.txt" или "\\SERVER\Projects\TestProject\Data.txt". Такое имя всегда однозначно указывает на файл - вне зависимости от любых внешних факторов.

Относительное имя содержит не все компоненты пути и указывает файл относительно другого каталога, имя которого в самом имени не указано, например: "Data.txt" или "..\Data.txt". Для определения точного положения файла недостаточно одного относительного имени, необходимо ещё имя каталога, относительно которого будет трактоваться это имя. Поэтому один и тот же относительный путь может ссылаться на разные файлы. К примеру, путь "Data.txt" ссылается на C:\Projects\TestProject\Data.txt, если текущий каталог (или каталог, относительно которого происходит разрешение имени) равен C:\Projects\TestProject, но этот же путь будет ссылаться на C:\Windows\Data.txt, если текущий каталог - C:\Windows.

Подробнее о файловых именах можно почитать здесь.

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

Почему вам не следует использовать ShellExecute(Ex)

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

В этот раз я расскажу вам о том, почему вам не следует использовать функцию ShellExecuteEx.

Почему вам (никогда) не следует использовать ShellExecute и WinExec

В Интернете полно примеров кода, которые используют функцию ShellExecute (реже - функцию WinExec). Однако, суровая правда состоит в том, что вам никогда не нужно использовать эти функции.

Почему?

"Дружественность" в Delphi

Небольшое введение в то, как обстоят дела с "дружественностью" в Delphi.

Программирование на WinAPI, часть 1 - где искать информацию

Это первая часть в цикле, посвящённому "программированию на WinAPI" в Delphi.

WinAPI - он же "Windows API", он же "Win32 API", он же "Application Programming Interface", он же "Прикладной интерфейс программирования" - набор системных функций ОС; самый низкий уровень для любой прикладной программы, в том числе - программ Delphi. Именно на системных функциях основываются все другие функции прикладных программ. Программист может вызывать функции WinAPI, чтобы сделать что-то, не предусмотренное набором функций языка и его библиотеки поддержки. Как правило, работа с функциями WinAPI отличается от работы с функциями и классами языка высокого уровня.

Часто можно услышать вопросы, происходящие от отсутствия навыков работы с WinAPI. К примеру, "этот код работал на Windows XP, но не работает в Windows 7. Что делать?" (приведён совершенно ужасный код, полученный народным методом copy&paste с жёстко зашитыми константами и отсутствием даже намёка на обработку ошибок), "вот код, который получает путь к папке Мои документы, а мне надо - к рабочему столу" (человек не знает, где посмотреть описание функции, чтобы поменять "Мои документы" на "Рабочий стол") и даже просто: "подскажите функцию, чтобы сделать XYZ" - и так далее.

Не будьте беспомощными! Вы сами можете найти ответы на эти вопросы. А этот цикл постов поможет вам в этом.

Запись вебинара, декабрь 2012

Публикую запись вебинара со вторника: Обработка ошибок в Delphi (V2).

Вебинар: Обработка ошибок в Delphi (V2)

В ближайший вторник я буду проводить вебинар на тему обработки ошибок в программах Delphi.

Сериализация - налоги

Оглавление серии.

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

Этот пост будет говорить об общих подходах к правильному дизайну работы с файлами и хранилищами данных. В т.н. "книжках по Delphi" об этом обычно не пишут, поскольку такие вещи не имеют отношения к Delphi, а описываются в "книгах по Windows". По какой-то не очень понятной мне причине, "книги по Windows" читаются не так уж многими людьми. Хотя, казалось бы, как можно писать программы под какую-то ОС, не владея знаниями по этой ОС. В любом случае, если вы захотите исправить этот свой недостаток, то вот книги, которые вам стоит прочитать:

• Windows via C/C++. Программирование на языке Visual C++ (старое название: Windows для профессионалов. Создание эффективных Win32-пpилoжeний с учетом специфики 64-разрядной версии Windows)
• Защищенный код
• Защищенный код для Windows Vista
• Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP, Windows 2000. Мастер-класс

Данные книги являются обязательным чтением для любого разработчика программ под Windows.

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

Сериализация - общие сведения о файлах

Оглавление серии.

Для начала вспомним, что такое файл. Файл - это устройство с последовательным доступом, к которому можно обратиться по имени. Самый типичный файл - это файл на диске. Но в более широком смысле файлом являются и файловые устройства - вроде сетевого соединения, потоков данных, каналов pipe и т.п. Соответственно, операцию записи или загрузки данных из файлов на диске можно рассматривать в более широком смысле, применительно к любым файлам.

Сериализация - оглавление

Этот пост начинает серию статей про сериализацию данных в Delphi. Он является оглавлением, которое я буду дополнять ссылками по мере написания статей. Я начал писать эту статью, поскольку у многих начинающих программистов возникают проблемы с ведением внешних данных в их программах.

Архитектура памяти в Windows: мифы и легенды (spin-off)

Этот пост - несколько необычное ответвление (spin-off) предыдущего.

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

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

Архитектура памяти в Windows

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

Что плохого в глобальных переменных?

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

Что лучше использовать?

Как использовать справку в программах Delphi

В этом посте я попробую в подробностях разобрать подключение справки к вашим Delphi программам. Здесь не будет рассматриваться, как создаются сами файлы справки (тем не менее, в конце я дам ссылки на программы и описание).