Ответ на задачку №2, часть первая

Попробуем разобраться.

Изначально в условии задачи уточнялось - OnPaint не используем.
Правильно это или нет - за условиями задачи, цель была прояснить, понимает ли собеседник поведение VCL в данном случае или нет.
Для упорствующих, конечно, готов очередной подводный камень, к которому мы придем в процессе объяснения, но впрочем по порядку.

Что было предложено в процессе обсуждения вопроса:
1. Зависимость от версий Delphi
2. Выравнивание текста или его многострочность.
3. Смена/пересоздание DC при вызове Memo.Lines[0]
4. Нарушение очереди сообщений из-за вызова обработчика OnClick и как следствие прочие неприятности...
5. Неправильное место вызова, DC "не готов" для вывода (про готовность я не понял, честно, ибо если канва не готова - будет ошибка, все прочее для эстетов :)

Начнем с первого пункта.


Именно в изначальной постановке задачи, зависимости как таковой нет.
В неправильных вариантах кода текст будет:

1. либо не выведен;
2. либо будет выведен с искажениями, как на картинке ниже;

Но.. по всей видимости есть некоторые изменения, ибо вывод текста с уплывшим Brush/Pen/Font гарантированно можно было воспроизвести под Delphi 2007 (и даже под 2010 - если мне не отказывает память) в случае использования самого первого варианта кода под ХР и ниже:

var
  ACanvas: THandle;
  AText: string;
begin
  ACanvas := Canvas.Handle;
  AText := Memo1.Lines[0];
  TextOut(ACanvas, Button1.Left, 20, PChar(AText), Length(AText));
end;

Код под ХЕ4 такое поведение сегодня мне не показал, он просто не вывел текст. :)

На этом я заострю ваше внимание чуть ниже, а пока что второй пункт...

Выравнивание текста или многострочность.

Здесь по, всей видимости, рассматривалось то, что TextOut, в отличие от DrawText не может работать с (скажем так) навороченной строкой, ну, к примеру, выравнивание по правому краю (из-за форматирования) или то, что первая строка в Memo может представлять из себя просто sLineBreak.
Это все мимо, хотя уже даже за такое я бы лично выставил ребятам пиво - люблю тех, кто мыслит не стандартно (без шуток) :)

Поэтому перейдем к сути (пункт три):

Взяв в руки отладчик, мы сможем увидеть, что только один вариант кода (вышеозвученный из четырех) приводит к некорректному поведению.
Происходит это из-за того, что ранее полученный нами DC, не то чтобы пересоздается - он просто разрушается, и при вызове TextOut на разрушенный DC, конечно может произойти все что угодно (вплоть до некорректного вывода текста).

Происходит это по причине того, что вызов Memo1.Lines[0] осуществляется с участием вызова SendMessage, который приведет нас вот к этому участку кода:

procedure TWinControl.MainWndProc(var Message: TMessage);
begin
  try
    try
      WindowProc(Message);
    finally
      FreeDeviceContexts;
      FreeMemoryContexts;
    end;
  except
    Application.HandleException(Self);
  end;
end;

Обратите внимание на вызов FreeDeviceContexts - именно здесь и происходит разрушение ранее полученного DC.

Таким образом, понимая что любой вызов SendMessage приводит к освобождению DC, мы можем реализовать вот такой код:

procedure TForm1.Button2Click(Sender: TObject);
var
  ACanvas: THandle;
  AText: string;
begin
  AText := 'qweqweqwe';
  ACanvas := Canvas.Handle;
  SendMessage(Handle, WM_NULL, 0, 0); // << после данного вызова канвас не валиден
  TextOut(ACanvas, Button1.Left, 20, PChar(AText), Length(AText));
end;

А что с вызовом "Memo1.Text"?
А здесь все очень просто, вызов Perform внутри данного метода обрабатывается самой VCL, поэтому и нет освобождения DC.

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

Эпилог:
Что я хотел услышать от человека, который проходит данный тест - это следующее:
Первый вариант кода не верен, по причине работы с некорректным DC, после его освобождения в обработчике MainWndProc.
По сути - это все :)

А теперь перейдем к ответу на пять с плюсом и рассмотрим пятый пункт :)

Пункт пять - DC не готов, нужно рисовать в OnPaint.

Хорошо, допустим он не готов, хотя такое понятие по сути никак не может быть использовано в VCL коде, оно присуще состоянию флагов непосредственно GDI хэндла, с которыми VCL не работает.

Допустим и напишем вот такой код:

procedure TForm1.FormPaint(Sender: TObject);
var
  ACanvas: THandle;
  AText: string;
begin
  ACanvas := Canvas.Handle;
  AText := Memo1.Lines[0];
  TextOut(ACanvas, Button1.Left, 20, PChar(AText), Length(AText));
end;

Код отработает правильно и нарисует содержимое первой строки TMemo.
Возникает вопрос, почему вызов "Memo1.Lines[0]" не привел к пересозданию DC и текст вывелся правильно?
Здесь все просто, суть кроется в той же процедуре FreeDeviceContexts.
В обработчике OnPaint канвас создан, валиден и залочен, таким образом переменная ACanvas, даже после вызова "Memo1.Lines[0]" будет содержать правильный DC.

Так работает VCL, но мы попробуем ее обойти и все-же вывести текст в обход залоченого канваса.

Сделаем это следующим кодом:

type
  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    procedure FormPaint(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    ACanvas: THandle;
    AText: string;
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.dfm}
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  ACanvas := Canvas.Handle;
  AText := Memo1.Lines[0];
  Repaint;
end;
 
procedure TForm1.FormPaint(Sender: TObject);
begin
  if ACanvas <> 0 then
    TextOut(ACanvas, Button1.Left, 20, PChar(AText), Length(AText));
end;

Итак по порядку, как мы уже рассмотрели:
1. В обработчике кнопки мы получаем валидный DC формы
2. Вызовом "Memo1.Lines[0]" мы его разрушили
3. Через Repaint вызвали отрисовку формы где..
4. Через уже невалидный DC вывели текст на форму.

Работает?
Да еще как, но ведь не должен.
А где ж засада, ведь по логике мы хэндл канваса уже разрушили (что и было ранее объяснено), причем под обработчик OnPaint внутри VCL было создано новое DC и залочено, но почему же текст выводится через старое DC?

А давай-те ка поизучаем.

Пишем:

procedure TForm1.Button3Click(Sender: TObject);
var
  FakeDC: HDC;
  AText: string;
begin
  AText := 'Некий текст';
  // Создаем DC
  FakeDC := GetDC(Handle);
  // Сразу его релизим
  ReleaseDC(Handle, FakeDC);
  // Проверочка
  if WindowFromDC(FakeDC) <> 0 then
    ShowMessage('FakeDC не разрушен');
  TextOut(FakeDC, Button1.Left, 20, PChar(AText), Length(AText));
end;

Здесь, выкинув лишнее и взяв суть из VCL кода демонстрируется что происходит с DC при выполнении всех вышеописанных строчек кода. Вдогонку мы проверяем - действительно ли DC не валиден вызовом WindowFromDC.

А теперь.... Магия :))

Пишем:

procedure TForm1.Button3Click(Sender: TObject);
var
  FakeDC: HDC;
  AText: string;
  PS: TPaintStruct;
begin
  AText := 'Некий текст';
  // Создаем DC
  FakeDC := GetDC(Handle);
  // Сразу его релизим
  ReleaseDC(Handle, FakeDC);
  // Проверочка
  if WindowFromDC(FakeDC) <> 0 then
    ShowMessage('FakeDC не разрушен');

  // Оживляем разрушенный DC
  InvalidateRect(Handle, 0, True);
  BeginPaint(Handle, PS);
  // Проверка, привязан ли разрушенный DC к нашей форме?
  if WindowFromDC(FakeDC) = Handle then
    // оппа - привязан, а давай-ка выведем на нем текст...
    TextOut(FakeDC, Button1.Left, 20, PChar(AText), Length(AText));
  EndPaint(Handle, PS);
end;

А вот это уже крайне интересно, работая с заведомо разрушенным DC, мы все же имеем возможность вывода текста на форму, именно поэтому и работает вариант с отложенной отрисовкой через OnPaint.

Впрочем... здесь я пока что и остановлюсь.

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

Но не раньше, чем будут предложены варианты, объясняющие такое поведение, или хотя бы предположения о таком поведении :)
Думаю после НГ - всех с наступающим, кстати :)

UPD:
Здесь я постараюсь дать развернутый ответ на вопросы - зачем давать такие примеры кода на собеседовании? :)

Итак, начнем с того, что IT отдел у нас достаточно маленький (8 человек) а объем работы категорически большой/
Поэтому при отборе сотрудников мы пользуемся старым шаблоном - нам не нужны ваши дипломы/пол/возраст/вес/социальный статус/связи и прочее, нам нужны только ваши знания и мы за них готовы платить ну очень хорошие деньги, даже для Москвы :)
Но знания должны быть хорошие, ибо как правило мы берем разработчика один раз и навсегда, попрыгунчики нам не нужны, поэтому только квалификация и еще раз квалификация.
Текучка очень маленькая - на коммерческом коде ушел всего один человек за последние 10 лет и то по семейным обстоятельствам, о чем кстати до сих пор жалеем, уж очень был хорош.

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

Второй этап: IT отдел выдал вердикт - нам он нравится, после которого идет небольшое согласование у начальства и соискатель вызывается на допрос к техническому директору.
Если он его проходит (а как правило проходит, ибо мы стараемся чтобы технический не тратил свое время на совсем уж студентов), то он приглашается на беседу с Генеральным, после чего происходит принятие на работу.

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

И вот тут уже доходит очередь и до меня, где я прогоняю человека через несколько тестов (их сейчас 19 - если не ошибаюсь) на основании которых я понимаю в каких областях человек наиболее силен и где его применение будет наиболее выгодно для компании.
Грубо резюмы выглядят примерно так:
отличные знания VCL с углубленкой - рекомендую двинуть на него объем работ по разработке компонент. Или - практическое абсолютное понимание работу служб и сетевого транспорта, предлагаю двинуть его на наши сервера. Очень редко бывает и такое - отличное знание ассемблера, системных документированных и не очень структур, его я забираю себе - он будет помогать мне писать ядро защиты.

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