Mercury13

Простейший способ — взять несколько TPanel, которые align по вертикали, а в них TImage, которые align по горизонтали.

Если к тому же нужно сделать правильное поведение при увеличении-уменьшении окна — надо по OnResize налаживать свою расстановку.

Думаю, ваша задача более высокого уровня такова. Пользователи разрисовывают свои имена всякими там картинками, задача — убрать их.

Немного непонятно, с какой версией Delphi вы работаете, но, предположим, с 2010+.
Там string эквивалентно UnicodeString, 16-битной строке неограниченной длины, управляемой подсчётом ссылок средствами Delphi.
Юникод очень велик и будет расширяться, в идеале там может быть 1,15 млн. символов. Из них 120 тыс. уже занято.
Поэтому лучшим решением будет делать не чёрный список символов, а белый.

Качаем базу символов Unicode (есть где-то на unicode.org).
Делаем из неё фильтр по каким-нибудь признакам: например, буква/цифра/знак/комбинирующий/пробел и направление письма — либо слева направо, либо адаптирующееся.
Также для простоты исключаем символы с кодом 65536+ (с дополнительных плоскостей, они кодируются двумя WideChar).
Вот этим белым списком и пользуемся. Проходимся по строке и убираем все лишние.

Вариантов много, какой-то да и подойдёт.
1. Просто и грязно. Периодически делать Application.ProcessMessages. Сделать, чтобы во время работы ни одна кнопка не срабатывала.
2. Лучше подходит для законченного продукта. Наладить поток. Внимание, сеть в основном потоке в принципе нехорошее дело, если она там есть — айда пиши второй!
3. Оптимизировать алгоритм.
4. Избавиться от левых перерисовок. Гугли сообщение WM_SETREDRAW. Не забудь в конце Invalidate.

1. Стандартный Паскаль — без классов и прочих ништяков — даст определённое понимание об аскетизме Си. Недостаток Си именно в том, что там нет автодеструкторов — фирменной фишки C++. Даже в строках. А обработка ошибок с корректным уничтожением созданных объектов — в C++ автоматом, в Delphi/C#/Java try/finally — может намотать немало нервов.
2. Хороших UI-библиотек с визуальным редактированием, как VCL в Delphi и WinForms в C#, на Си нет. Во многом это связано с тем, что на Си нет простого и стандартного способа хранить строки. Разумеется, невизуально никто не мешает делать интерфейс, WinAPI (кроме COM, который ориентирован под устройство класса Microsoft C++) рассчитан именно на Си.

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

Что я могу сказать как человек, немало имевший дело с Delphi?
1. Форменное начхательство Borland до передачи продукта Embarcadero. Delphi перестал быть дойной коровой компании (деньги приносит вроде какая-то СУБД) — и его перестали совершенствовать. Кажется, что между версиями 7 и 2010 — пустота. Только в 2010 году сделали что-то для поддержки Юникода. «Амбаркадебра», конечно, работает, да время упущено: x64 появился около 2011, полная поддержка C++11 на всех платформах — не знаю, как в XE10, но в XE8 на x86 только явно устаревший компилятор Borland…
2. Странная ценовая политика Embarcadero. Самодельщик — не их аудитория, они пишут для тех, кто автоматизирует какие-то бизнес-процессы, у них и денежки водятся…
3. По моему личному ИМХО, поставили не на тот кроссплатформенный фреймворк — FireMonkey. Этот фреймворк грубо имитирует внешний вид стандартных компонентов Windows, а когда начинаются нюансы — локализация с автоподгонкой, или просто ClearType не нравится — начинается ад. А один из компонентов — TeeChart — ухитряется на FireMonkey попадать точно между пикселями, причём в редакторе это дело обойти можно, а в рабочей проге — нет.
4. Появление в этой же нише бесплатного WinForms (да и у «мусорного» языка C# порог входа пониже будет). Да, как я забыл про это! — хоть ухитрился «на шару» пройти начальное обучение по C#, никогда с ним не работал, ни профессионально, ни «так просто».

Что я пока вижу.
1. В любой высокоуровневой библиотеке CreateThread использовать ЗАПРЕЩЕНО, вместо этого используй beginthreadex (или что-то ещё, предоставленное библиотекой). Или, раз уж ты по-чёрному используешь VCL, особо не убудет, если будешь использовать TThread.
2. Lock и Unlock — это обыкновенный мьютекс. Все конкурирующие потоки, кому захочется рисовать на холсте, ждут и курят, ничего не делая.
3. Самое-то главное ты упустил. Если ждёшь помощи, не нужно так секретничать, что не поймёшь, в чём дело. Где — хотя бы примерно — тело потока, и что делается в главном потоке?
4. А как надо работать? Есть некая структура данных, в которой мы возвращаем из потока обработанные картинки, и volatile bool isWorking, который отвечает за то, работает поток или нет. Когда этот флажок false, главный поток имеет право работать с нашей структурой. Он переключается в true — в структуре может быть любой мусор, обращаться к ней запрещено! Если ещё и надо предупредить, когда поток закончился и можно забирать информацию — TThread.Synchronize или PostMessage. То и другое работает только в GUI-программах, если консольная — то через события (CreateEvent).
5. А почему «нельзя этого делать»? Если партия приказала, значит, надо. Просто многопоточность — это тяжёлое дело, ошибки на каждом шагу, но «принципиально нельзя» — нет такого.

1. Что принимает система: PCHAR или PCHAR*?
2. Если версии Delphi достаточно новые, PCHAR — это, скорее всего, wchar_t* и надо просто передавать «широкую» строчку L"usb3000".
3. Постарайся, чтобы reinterpret_cast не было; это признак того, что ты делаешь что-то неверно. Единственное, где он в подобных API допустим — это в callback’ах для передачи замыкания (информации о том, какая подпрограмма и при каких обстоятельствах запустила функцию, вызвавшую callback). P.S. Надумал и второе назначение reinterpret_cast — функция, которая может принимать данные разных типов (вроде SendMessage из Win32).

Пока без возможности запустить программу вижу у тебя две проблемы.
1. Две ошибки в повороте. а) неверная матрица вращения; б) во второй строке поворота имеет дело с новым X, а не старым.
2. Подобные операции с целыми числами приводят к накоплению погрешностей; через несколько итераций кораблик быстро станет кособоким. С дробными, вообще-то, тоже, только не так быстро и есть шансы, что задачу выполним раньше, чем проблемы будут мало-мальски заметны.

По поводу качества кода — я бы сделал функцию

function RotateAround(const source, pivot : TPoint) : TPoint;

Если она так нужна — в настройках компиляции отключи оптимизацию.

Если я не ошибаюсь, особенность системы безопасности Windows Vista+. Так что никак.

1. Нужен ActiveX-компонент PowerPoint.
Как-то не доводилось делать, поэтому точный рецепт сказать не могу.
2. WinExec — разве эта функция не deprecated в пользу CreateProcess и ShellExecuteEx?

Прямые причины этого отрезка.
1. В первом MoveTo ты спутал реальные и экранные координаты. И в первом графике, видимо, тоже, только там линия уходит влево за край.
2. У тебя нет никакой логики поведения на разрывах. В простейшем случае — в первую точку MoveTo, а не LineTo.

И прочие ошибки.
3. Не инициализирован y.
4. Ты рисуешь не на том холсте. Видимо, ты хотел забуферизировать графики — но графики не отпечатываются на картинке, а рисуются на холсте формы. Как только ты минимизируешь-восстановишь прогу, графики исчезнут. Надо рисование либо в событие OnPaint (тогда график будет перестраиваться каждый раз при перерисовке), либо отпечатать на Picture.Bitmap (график останется отпечатанным на картинке). Во втором случае не забудь image2.Invalidate (отложенно перерисовать, когда это станет возможным);
5. Шаг слишком мал. Это должен быть эквивалент одного или двух пикселей.

ПРИМЕЧАНИЕ ПО ПОВОДУ 4. В WinVista+ с включенным Aero может быть всё в порядке (Aero буферизирует окна, чтобы работал Aero Flip и прочее). Выключи Aero, и будет обычный «хардкор» Windows: ничего не запоминает, а когда потребуется, перерисовывает.

Включён градиент? Есть там такое: градиент включается по любому чиху (правда, на точках — впервые вижу).