При работе с многопоточностью в Delphi и Pascal, особенно с использованием TTask из модуля System.Threading, разработчики могут столкнуться с неожиданной ошибкой "RunError(103) file not found" в GUI-приложениях. Эта статья рассмотрит причины возникновения этой ошибки и предложит несколько способов ее решения, а также затронет связанные с этим проблемы и альтернативные подходы.
Причина ошибки "RunError(103) file not found"
Ошибка 103, как выяснилось, связана с отсутствием стандартного потока вывода (stdOut). Модуль System.Threading может использовать WriteLn для отладочного вывода (особенно при включенной директиве DEBUGTHREADPOOL). В GUI-приложениях по умолчанию консоль не создается, и попытка записи в stdOut приводит к ошибке.
Решение 1: Добавление директивы {$APPTYPE CONSOLE}
Самый простой и быстрый способ решить проблему – добавить директиву {$APPTYPE CONSOLE} в файл проекта вашего GUI-приложения. Это заставит компилятор создать консоль для приложения, даже если оно имеет графический интерфейс.
program MyGUIApp;
{$APPTYPE CONSOLE} // Добавляем директиву для создания консоли
uses
Forms,
Unit1 in 'Unit1.pas' {Form1};
{$R *.res}
begin
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.Run;
end.
Этот подход является обходным путем, так как он создает консоль, которая может быть не нужна для основной функциональности приложения. Однако, если отладочный вывод необходим, это может быть приемлемым временным решением.
Решение 2: Перенаправление stdOut в GUI-компонент
Более элегантным решением является перенаправление стандартного потока вывода в какой-либо GUI-компонент, например, в TMemo или TRichEdit. Это позволит видеть отладочный вывод непосредственно в окне приложения, без необходимости держать открытой отдельную консоль.
Пример перенаправления stdOut в TMemo:
uses
...,
Classes,
SysUtils;
type
TForm1 = class(TForm)
Memo1: TMemo;
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
FOldOutput: Text;
procedure MyOutputProc(const S: string);
public
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;
end;
implementation
{$R *.dfm}
constructor TForm1.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FOldOutput := Output; // Сохраняем оригинальный поток вывода
Assign(Output, 'NUL'); // Отключаем оригинальный поток вывода
Rewrite(Output);
SetTextBuf(Output, nil, 0); // Убираем буферизацию
Application.OnMessage := MyOutputProc; // Перехватываем сообщения
end;
destructor TForm1.Destroy;
begin
Application.OnMessage := nil; // Отключаем перехват сообщений
Output := FOldOutput; // Восстанавливаем оригинальный поток вывода
inherited Destroy;
end;
procedure TForm1.MyOutputProc(const S: string);
begin
Memo1.Lines.Add(S); // Добавляем вывод в TMemo
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
TTask.Run(procedure
begin
ShowMessage('test'); // ShowMessage требует Dialogs unit
writeln('Отладочное сообщение из TTask');
end);
end;
end.
Этот код перехватывает все сообщения, отправляемые в stdOut, и добавляет их в TMemo. Обратите внимание, что ShowMessage требует подключения модуля Dialogs.
Решение 3: Отключение DEBUGTHREADPOOL
Если отладочный вывод не требуется, можно просто отключить директиву DEBUGTHREADPOOL в модуле System.Threading:
{$UNDEF DEBUGTHREADPOOL}
Это предотвратит использование WriteLn внутри TTask и, следовательно, избавит от ошибки 103.
Альтернативные подходы и связанные проблемы
Использование TThread вместо TTask: В некоторых случаях использование классического TThread может быть более подходящим, особенно если требуется более тонкий контроль над потоком. Однако, TTask предоставляет более современный и удобный интерфейс для работы с параллельными задачами.
Проблема с Async/Await и захватом ссылок на функции: Как было упомянуто в исходном контексте, при использовании паттерна Async/Await могут возникать проблемы с захватом ссылок на функции, приводящие к ошибкам доступа. Эта проблема требует более глубокого анализа и, возможно, исправления в компиляторе или RTL. Рекомендуется следить за issue на GitLab (https://gitlab.com/freepascal.org/fpc/source/-/issues?show=eyJpaWQiOiI0MTI5NyIsImZ1bGxfcGF0aCI6ImZyZWVwYXNjYWwub3JnL2ZwYy9zb3VyY2UiLCJpZCI6MTY5MzEyMzQ1fQ%3D%3D) и использовать обходные пути, пока проблема не будет решена.
Необходимость ReadLn в консольных приложениях: В некоторых случаях, особенно в Windows, для корректной работы TTask в консольных приложениях необходимо добавить ReadLn в конце программы. Это связано с тем, что основная программа может завершиться до того, как задача, выполняющаяся в отдельном потоке, успеет завершить свою работу.
Заключение
Ошибка "file not found" при использовании TTask в GUI-приложениях является распространенной проблемой, вызванной попыткой записи в stdOut при отсутствии консоли. Предложенные решения, такие как добавление {$APPTYPE CONSOLE}, перенаправление stdOut или отключение DEBUGTHREADPOOL, позволяют обойти эту проблему. При использовании Async/Await следует учитывать возможные проблемы с захватом ссылок на функции. Выбор конкретного решения зависит от требований проекта и необходимости отладочного вывода. Важно помнить о необходимости ReadLn в консольных приложениях для предотвращения преждевременного завершения программы.
Данный текст описывает проблему "file not found" при использовании TTask в GUI-приложении на Delphi и Pascal, а также предлагает различные решения и альтернативные подходы к ее устранению.
Комментарии и вопросы
Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS
Telegram-канал