VPF::Пример простого многопоточного приложения.

Петрович

Дата 17.7.2007, 15:07 (ссылка)

(голосов:2)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 1000
Регистрация: 2.12.2003
Где: Москва

Репутация: 15
Всего: 55

Пример посторения простого многопоточного приложения.

Рожден о причине большого числа вопросов о построении многопоточных приложений в Delphi.

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

Пример не прретендует на полноту, он лишь демонстрирует наиболее простые способы взаимодействия потоков. Позволяя пользователю "быстренько слепить" (кто бы знал как я этого не люблю) правильно работающее многопоточное приложение.
В нем все подробно (на мой взгляд) прокоментированно, но, если будут вопросы, задавайте.
Но еще раз предостерегаю: Потоки - дело не простое. Если Вы не представляете как все это работает, то есть огромная опасность что часто у Вас все будет работать нормально, а иногда программа будет вести себя более чем странно. Поведение неправильно написанной многопотчной программы очень сильно зависит от большого кол-ва факторов, которые порою невозможно воспроизвести при отладке.

Короче, читайте документацию, и статью Многопоточность - как это делается в Дельфи. Не используйте потоки, не прочитав это smile

Итак пример. Для удобства поместил и код, и прикрепил архив с кодом модуля и формы

Код


unit ExThreadForm;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

// константы используемые при передаче данных из потока в форму с помощью
// отсылки оконных сообщений
const
  WM_USER_SendMessageMetod = WM_USER+10;
  WM_USER_PostMessageMetod = WM_USER+11;

type
  // описание класса потока, потомка от tThread
  tMyThread = class(tThread)
    private
      SyncDataN :Integer;
      SyncDataS :String;
      procedure SyncMetod1;
    protected
      procedure  Execute; override;
    public
      Param1 :String;
      Param2 :Integer;
      Param3 :Boolean;
      Stopped :Boolean;
      LastRandom :Integer;
      IterationNo :Integer;
      ResultList :tStringList;

      constructor Create (aParam1 :String);
      destructor  Destroy; override;
  end;

  // описание класса использующей поток формы
  TForm1 = class(TForm)
    Label1: TLabel;
    Memo1: TMemo;
    btnStart: TButton;
    btnStop: TButton;
    Edit1: TEdit;
    Edit2: TEdit;
    CheckBox1: TCheckBox;
    Label2: TLabel;
    Label3: TLabel;
    Label4: TLabel;
    procedure btnStartClick(Sender: TObject);
    procedure btnStopClick(Sender: TObject);
  private
    { Private declarations }
    MyThread :tMyThread;
    procedure EventMyThreadOnTerminate (Sender :tObject);
    procedure EventOnSendMessageMetod (var Msg: TMessage);message WM_USER_SendMessageMetod;
    procedure EventOnPostMessageMetod (var Msg: TMessage); message WM_USER_PostMessageMetod;

  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

{
  Stopped - демонстрирует передачу данных от формы к потоку.
    Дополнительной синхронизации не требует, поскольку является простым
    однословным типом, и пишется только одним потоком.
}

procedure TForm1.btnStartClick(Sender: TObject);
begin
  Randomize(); // обеспечение случайнсти в последовательности по Random() - к потоком отношения не имеет

  // Создание экземпляра объекта потока, с передачей ему входного параметра
    {
    ВНИМАНИЕ!
    Конструктор потока написан таким образом что поток создается
    приостановленным, поскольку это позволяет:
    1. Контролировать момент его запуска. Это почти всегда удобнее, т.к.
    позволяет еще до запуска настроить поток, передать ему входные
    параметры, и т.п.
    2. Т.к. ссылка на созданный объект будет сохранена в поле формы, то
    после самоуничтожения потока (см.ниже) которое при запущенном потоке
    может произойти в любой момент, эта ссылка станет недействительной.
    }
  MyThread := tMyThread.Create(Form1.Edit1.Text);

  // Однако, поскольку поток создан приостановленным, то при любых ошибках
  // во время его инициализации (до запуска), мы должны его сами уничтожить
  // для чегу используем try / except блок
  try

    // Назначение обработчика завершения потока в котором будем принимать
    // результаты работы потока, и "затирать" ссылку на него
    MyThread.OnTerminate := EventMyThreadOnTerminate;

    // Поскольку результаты будем забирать в OnTerminate, т.е. до самоуничтожения
    // потока то снимем с себя заботы по его уничтожению
    MyThread.FreeOnTerminate := True;

    // Пример передачи входных параметров через поля объекта-потока, в точке
    // создания экземпляра, когда он еще не запущен.
    // Лично я, предпочитаю делать это через параметры переопределяемого
    // конструктора (tMyThread.Create)
    MyThread.Param2 := StrToInt(Form1.Edit2.Text);

    MyThread.Stopped := False; // своего рода тоже параметр, но меняющийся во
                               // время работы потока
  except
    // поскольку поток еще не запущен и не сможет самоуничтожиться, уничтожим его "вручную"
    FreeAndNil(MyThread);
    // а дальше пусть исключительная ситуация обрабатывается обычным порядком
    raise;
  end;

  // Поскольку объект потока успешно создан и настроен, настало время запустить его
  MyThread.Resume;

  ShowMessage('Поток запущен');
end;

procedure TForm1.btnStopClick(Sender: TObject);
begin
  // Если экземпляр потока еще существует, то попросим его остановиться
  // Причем, именно "попросим". "Заставить" в принципе тоже можем, но это будет
  // исключительно аварийный вариант, требующий четкого понимания всей этой
  // потоковой кухни. Поэтому, здесь не рассматривается.
  if  Assigned(MyThread) then
    MyThread.Stopped := True
  else
    ShowMessage('Поток не запущен!');
end;

procedure TForm1.EventOnSendMessageMetod(var Msg: TMessage);
begin
  // метод обработки синхронного сообщения
  // в WParam адрес объекта tMyThread, в LParam тек.значение LastRandom потока
  with  tMyThread(Msg.WParam)  do begin
    Form1.Label3.Caption := Format('%d %d %d',[IterationNo,LastRandom,Msg.LParam]);
  end;
end;

procedure TForm1.EventOnPostMessageMetod(var Msg: TMessage);
begin
  // метод обработки асинхронного сообщения
  // в WParam тек.значение IterationNo, в LParam тек.значение LastRandom потока
  Form1.Label4.Caption := Format('%d %d',[Msg.WParam,Msg.LParam]);
end;

procedure TForm1.EventMyThreadOnTerminate (Sender :tObject);
begin
  // ВАЖНО!
  // Метот обработки события OnTerminate всегда вызывается в контексте основного
  // потока - это гарантируется реализацией tThread. Поэтому, в нем можно свободно
  // использовать любые свойства и методы любых объектов

  // На всякий случай, убедимся что экземпляр объекта еще существует
  if  not Assigned(MyThread) then Exit; // если его нет, то и делать нечего

  // получение результатов работы потока экземпляра объекта потока
  Form1.Memo1.Lines.Add(Format('Поток завершился с результатом %d',[MyThread.IterationNo]));
  Form1.Memo1.Lines.AddStrings((Sender as tMyThread).ResultList);

  // Уничтожение ссылки на экземпляр объекта потока.
  // Поскольку поток у нас самоуничтожающийся (FreeOnTerminate := True)
  // то после завершения обрабтчика OnTerminate, экземпляр объекта-потока будет
  // уничтожен (Free), и все ссылки на него станут недействительными.
  // Что бы случайно не напороться на такую ссылку, затрем MyThread
  // Еще раз замечу - не уничтожим объект, а только затрем ссылку. Объект
  // уничтожится сам!
  MyThread := Nil;
end;

{ tMyThread }

constructor tMyThread.Create (aParam1 :String);
begin
  // Создаем экземпляр ПРИОСТАНОВЛЕННОГО потока (см.коментарий при создании экземпляра)
  inherited Create(True);

  // Создание внутренних объектов (если необходимо)
  ResultList := tStringList.Create;

  // Получение исходных данных.

  // Копирование входных данных переданных через параметр
  Param1 := aParam1;

  // Пример получения входных данных из VCL-компонентов в конструкторе объекта-потока
  // Такое в данном случае допустимо, поскольку конструктор вызывается в контексте
  // основного потока. Следовательно, здесь можно обращаться к VCL-компонентам.
  // Но, я такого не люблю, поскольку считаю что плохо когда поток знает что-то
  // о какой-то там форме. Но, чего не сделаешь для демонстрации.
  Param3 := Form1.CheckBox1.Checked;
end;

destructor tMyThread.Destroy;
begin
  // уничтожение внутренних объектов
  FreeAndNil(ResultList);
  // уничтожение базового tThread
  inherited;
end;

procedure tMyThread.Execute;
var
  t :Cardinal;
  s :String;
begin
  IterationNo := 0; // счетчик результатов (номер цикла)

  // В моем примере тело потока представляет собой цикл, который завершается
  // либо по внешней "просьбе" завершиться передаваемый через изменяемый параметр Stopped,
  // либо просто совершив 5 циклов
  // Мне приятнее такое записывать через "вечный" цикл.

  while  True  do begin

    Inc(IterationNo); // очередной номер цикла

    LastRandom := Random(1000); // слючайное число - для демонстрации передачи параметров от потока в форму

    t := Random(5)+1; // время на которое будем засыпать если нас не завершат

    // Тупая работа (зависящая от входного параметра)
    if  not Param3 then
      Inc(Param2)
    else
      Dec(Param2);

    // Сформируем промежуточный результат
    s := Format('%s %5d %s %d %d',
                 [FormatDateTime('hh:nn:ss:zzz',Now) // время записи
                 ,IterationNo                        // номер цикла
                 ,Param1                             // то что было в параметре
                 ,Param2                             // текущий результат работы
                 ,t                                  // время на которое предполагаем заснуть
                 ]);

    // Добавим промежуточный результат к списку резуольтатов
    ResultList.Add(s);

    //// Примеры передачи промежуточного результата на форму

    //// Передача через синхронизируемый метод - классический способ
    //// Недостатки:
    ////   - синхронизируемый метод - это обычно метод класса потока (для доступа
    ////     к полям объекта-потока), но, для доступа к полям формы, он должен
    ////     "знать" про нее и ее поля (объекты), что обычно не очень хорошо с
    ////     точки зрения организации программы.
    ////   - текущий поток будет приостановлен до завершения выполнения
    ////     синхронизированного метода.
    ////   - требует существенных затрат процессорного времени на каждый вызов
    ////     (на переключение потоков) поэтому нежелателен очень частый вызов
    //// Достоинства:
    ////   - стандартность и универсальность
    ////   - в синхронизированном методе можно пользоваться
    ////     всеми полями объекта-потока.
    //
    // сначала, если необходимо, надо сохранить передаваемые данные в
    // специальных полях объекта объекта.
    SyncDataN := IterationNo;
    SyncDataS := 'Sync'+s;
    // и затем обеспечить синхронизированный вызов метода
    Synchronize(SyncMetod1);

    //// Передача через синхронную отсылку сообщения (SendMessage)
    //// в этом случае, данные можно передать как через параметры сообщения (LastRandom),
    //// так и через поля объекта, передав в параметре сообщения адрес экземпляра
    //// объекта-потока - Integer(Self).
    //// Недостатки:
    ////   - поток должен знать handle окна формы
    ////   - как и при Synchronize, текущий поток будет приостановлен до
    ////     завершения обработки сообщения основным потоком
    ////   - требует существенных затрат процессорного времени на каждый вызов
    ////     (на переключение потоков) поэтому нежелателен очень частый вызов
    //// Достоинства:
    ////   - как и при Synchronize, при обработке сообщения можно пользоваться
    ////     всеми полями объекта-потока (если конечно был передан его адрес)
    ////   - в отличии от синхронизированного вызова, обработчиком сообщения
    ////     является метод формы, который должен иметь знания об объекте-потоке,
    ////     или вовсе ничего не знать о потоке, если данные передаеются только
    ////     через параметры сообщения. Т.е., поток может ничего не знать о форме
    ////     вообще - только ее Handle, который может быть передан как параметр до
    ////     запуска потока.
    SendMessage(Form1.Handle,WM_USER_SendMessageMetod,Integer(Self),LastRandom);

    //// Передача через асинхронную отсылку сообщения (PostMessage)
    //// Поскольку в этом случае к моменту получения сообщения основным потоком,
    //// посылающий поток может уже завершиться, передача адреса экземпляра
    //// объекта-потока недопустима!
    //// Недостатки:
    ////   - поток должен знать handle окна формы;
    ////   - из-за асинхронности, передача данных возможна только через параметры
    ////     сообщения, что существенно усложняет передачу данных имеющих размер
    ////     более двух машинныхх слов. Удобно применять для передачи Integer и т.п.
    //// Достоинства:
    ////   - в отличие от предыдущих методов, текущий поток НЕ будет
    ////     приостановлен, а сразу же продолжит свое выполнение
    ////   - в отличии от синхронизированного вызова, обработчиком сообщения
    ////     является метод формы, который должен иметь знания об объекте-потоке,
    ////     или вовсе ничего не знать о потоке, если данные передаеются только
    ////     через параметры сообщения. Т.е., поток может ничего не знать о форме
    ////     вообще - только ее Handle, который может быть передан как параметр до
    ////     запуска потока.
    PostMessage(Form1.Handle,WM_USER_PostMessageMetod,IterationNo,LastRandom);



    //// Проверка возможного завершения

    // Проверка завершения по параметру
    if  Stopped  then  Break;

    // Проверка завершения по случаю
    if  IterationNo >= 10 then  Break;



    Sleep(t*1000); // Засыпаем на t секунд
  end;
end;

procedure tMyThread.SyncMetod1;
begin
  // этот метод вызывается посредством метода Synchronize.
  // Т.е., не смотря на то что он является методом потока tMyThread,
  // он выполняется в контексте основного потока приложения.
  // Следовательно, ему все можно, ну или почти все :)
  // Но помним, здесь не стоит долго "возиться"

  // Переданные параметры, мы можем извлечь из специальных поле, куда мы их
  // сохранили перед вызовом.
  Form1.Label1.Caption := SyncDataS;

  // либо из других полей объекта потока, например отражающих его тек.состояние
  Form1.Label2.Caption := Format('%d %d',[IterationNo,LastRandom]);
end;

end.

А вообще, примеру предшествовали следующие мои рассуждения на тему....

Во первых:
ВАЖНЕЙШЕЕ правило многопоточного программирования на Delphi:
В контексте не основного потока нельзя, обращаться к свойствам и методам форм, да и вообще всех компонентов которые "растут" из tWinControl.

Это означает (несколько упрощенно) что ни в методе Execute унаследованного от TThread, ни в других методах/процедурах/функциях вызываемых из Execute, нельзя напрямую обращаться ни к каким свойствам и методам визуальных компонентов.

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

Если коротенько на пальцах:

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

В первом случае, реализация работы внутри основного потока приводит к «торможению» пользовательского интерфейса – пока делается работа, не выполняется цикл обработки сообщений. Как следствие – программа не реагирует на действия пользователя, и не прорисовывается форма, например после ее перемещения пользователем.

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

Существуют и другие случаи, но реже. Впрочем, это и не важно. Сейчас не об этом.

Теперь, как все это пишется. Естественно рассматривается некий наиболее частый случай, несколько обобщенный. Итак.

Работа, выносимая в отдельный поток, в общем случае имеет четыре сущности (уж и не знаю как назвать точнее):
1.    Исходные данные
2.    Собственно сама работа (она может зависеть от исходных данных)
3.    Промежуточные данные (например, информация о текущем состоянии выполнения работы)
4.    Выходные данные (результат)

Чаще всего для считывания и вывода большей части данных используются визуальные компоненты. Но, как было сказано выше – нельзя из потока напрямую обращаться к визуальным компонентам. Как же быть?
Разработчики Delphi предлагают использовать метод Synchronize класса TThread. Здесь я не буду описывать то, как его применять – для этого есть вышеупомянутая статья. Скажу лишь, что его применение, даже правильное, не всегда оправдано. Имеются две проблемы:

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

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

Причем, обе проблемы взаимосвязаны, и вызывают противоречие: с одной стороны, для решения первой, надо «размельчать» методы вызываемые через Synchronize, а с другой, их тогда чаще приходится вызывать, теряя драгоценный процессорный ресурс.

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

Исходные данные
Все данные которые передаются в поток, и не изменяются во время его работы, нужно передавать еще до его запуска, т.е. при создании потока. Для их использования в теле потока, нужно сделать их локальную копию (обычно в полях потомка TThread).
Если есть исходные данные которые могут меняться во время работы потока, то доступ к таким данным нужно осуществлять либо через синхронизируемые методы (методы вызываемые через Synchronize), либо через поля объекта-потока (потомка TThread). Последнее требует определенной осторожности.

Промежуточные и выходные данные
Здесь, опять же есть несколько способов (в порядке моих предпочтений):
-    Метод асинхронной отсылки сообщений главному окну приложению.
Используется обычно для отсылки основному окну приложения сообщений о состоянии протекания процесса, с передачей незначительного объема данных (например, процента выполнения)
-    Метод синхронной отсылки сообщений главному окну приложению.
Используется обычно для тех же целей что и асинхронная отсылка, но позволяет передать больший объем данных, без создания отдельной копии.
-    Синхронизируемые методы, по возможности, объединяя в один метод передачу как можно большего объема данных.
Можно использовать и для получения данных с формы.
-    Через поля объекта-потока, обеспечением взаимоисключающего доступа.
Подробнее, можно почитать в статье.

Эх. Коротенько опять не получилось

Это сообщение отредактировал(а) Петрович - 17.7.2007, 15:12

Присоединённый файл ( Кол-во скачиваний: 239 )

ExThreadForm.rar 4,36 Kb

--------------------

Все знать невозможно, но хочется

Alexeis

Дата 17.7.2007, 15:38 (ссылка)

(нет голосов)

Загрузка ...

Амеба

Профиль
Группа: Админ
Сообщений: 11743
Регистрация: 12.10.2005
Где: Зеленоград

Репутация: 16
Всего: 459

Цитата(Петрович @ 17.7.2007, 15:07

)

ВАЖНЕЙШЕЕ правило многопоточного программирования на Delphi:
В контексте не основного потока нельзя, обращаться к свойствам и методам форм, да и вообще всех компонентов которые "растут" из tWinControl.

Означает ли это, что к наследникам TControl, TComponent, TPersistent можно обращаться без опаски?

--------------------

Vit вечная память.

Обсуждение действий администрации форума производятся только в этом форуме

гениальность идеи состоит в том, что ее невозможно придумать

MetalFan

Дата 17.7.2007, 15:46 (ссылка)

(нет голосов)

Загрузка ...

Аццкий Сотона

Профиль
Группа: Комодератор
Сообщений: 3815
Регистрация: 2.10.2006
Где: Moscow

Репутация: 16
Всего: 128

отличный пример!
все достаточно подробно расписано) буду отсылать новичков сюда
есть конечно некоторые неточности... (см пост выше)
я бы сказал так:
ВАЖНЕЙШЕЕ правило многопоточного программирования: обеспечить недопустимость одновременного обращения к одной и той же памяти (на запись и чтение) из разных потоков.

Это сообщение отредактировал(а) MetalFan - 17.7.2007, 15:53

--------------------

There are always someone smarter than you...

Петрович

Дата 18.7.2007, 10:58 (ссылка)

(голосов:1)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 1000
Регистрация: 2.12.2003
Где: Москва

Репутация: 15
Всего: 55

Цитата(Alexeis @ 17.7.2007, 16:38

)

Означает ли это, что к наследникам TControl, TComponent, TPersistent можно обращаться без опаски?

Нет не означает.

Если подробнее то так:

1. tWinControl изначально написан так что он не реентерабелен. А это значит, что его и его наследников нельзя считать потокобезопасными классами. Вообще то, отчасти, это особенность Windows GUI smile

2. tControl - реентерабельный класс, т.е. он потокобезопасен. Однако, классы которые его наследуют не обязательно являются потокобезопасными. Тут все зависит от того как написаны классы наследники. Например, есть в природе базовый клас "птицы", объектам которого вроде как положено летать. Однако, некоторые объекты наследники класса "птицы", такие как например "курица", летать не умеют. smile

Цитата(MetalFan @ 17.7.2007, 16:46

)

ВАЖНЕЙШЕЕ правило многопоточного программирования: обеспечить недопустимость одновременного обращения к одной и той же памяти (на запись и чтение) из разных потоков.

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

Кстати, в этом примере, я как раз даже не затронул вопрос защиты доступа к разделяемой между потоками памяти. Сначала вроде хотел, а потом решил что пример и так уже "здоровенный" получился. А если в него еще что-то добавить, то он сильно потеряет в прозрачности.
Просто, это была попытка помочь новичкам в решении лишь одной простейшей проблемы: обращение к методам и свойствам визуальных компонент из неосновного потока. Практика показывает что это первая проблема с которой сталкиваются программисты при написании своего первого многопоточного приложения на Delphi.
Уж слишком серьезная тема, много разных важных аспектов..... Лучше конечно если программист прочитает указанную выше статью. Там конечно затронуто гораздо больше аспектов, нюансов, и пр.

--------------------

Все знать невозможно, но хочется

Alexeis

Дата 18.7.2007, 13:12 (ссылка)

(нет голосов)

Загрузка ...

Амеба

Профиль
Группа: Админ
Сообщений: 11743
Регистрация: 12.10.2005
Где: Зеленоград

Репутация: 16
Всего: 459

Цитата(Петрович @ 18.7.2007, 10:58

)

Однако, некоторые объекты наследники класса "птицы", такие как например "курица", летать не умеют.

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

--------------------

firedanger

Дата 18.10.2014, 18:25 (ссылка)

(нет голосов)

Загрузка ...

Новичок

Профиль
Группа: Участник
Сообщений: 1
Регистрация: 18.10.2014

Репутация: нет
Всего: нет

Уважаемый коллега!
Не подскажите о тонкостях организации многопоточного консольного приложения в Delphi. Необходимо организовать параллельную работу многопоточного приложения на многоядерном процессоре (для конкретики 4 ядра) в режиме распараллеливания по данным (SPMD-модель). Алгоритм в кратце таков: корневой процесс считывает данные из файла, рассылает их по потокам. Затем каждый поток обрабатывает свою порцию данных. После чего корневой процесс собирает данные и выводит их в файл результатов.
P.S.
Был опыт параллельного программирования на вычислительном кластере параллельной архитектуры в системе MPI (Message Passing Interface). Но это было давно.
Заранее спасибо.

1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| Delphi: WinAPI и системное программирование \| Следующая тема »