Если программа содержит, скажем, 100 форм - в каждой из которых так или иначе требуется похожий функционал из этих модулей - в чём смысл вручную прописывать в каждой форме в USES кучу одинакового мусора для каждой формы - который кроме того требуется ещё прописывать в определенном порядке иначе будут несовместимости типов с одинаковыми названиями (такое даже в VCL есть!) из разных модулей? Если можно просто написать USES {$I AllVcl.pas}?

Кроме того, в проекте присутствуют переписанные модули Forms.pas, Grids.pas, DBGrids.pas и т. д. - которые теперь используют функционал из других моих модулей - поэтому USES должен быть в строго определённом порядке.

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

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

Как я понимаю, вывод текста ещё зависит от используемого шрифта. В общем, надо определиться и желательно использовать во всей программе один шрифт. Потому что с MS Sans Serif одни особенности (и алгоритмы перехвата), с Arial другие, чтобы тексты отображались нормально и т. д. В моем случае во всей программе Arial, RUSSIAN_CHARSET, SetThreadLocale(1049) - но в некоторых местах может оказаться и MS Sans Serif или что-то другое.

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

Почему нет - очень даже рассматриваю такой вариант. Причем даже до размещения вопроса на этом форуме. Просто очень не хочется так делать - очень уж удобно и красиво модули сгруппированы в Delphi 7 и никаких проблем.

В Delphi 2010, кстати, исходники VCL в комплекте есть если сборка нормальная - тот кто говорил про мою кривую сборку - был прав.

Разве что если только вне зависимости от исходного формата строки - пытаться распознать строку, в каком она формате и всё равно пытаться выполнять преобразование. А в случае неудачи преобразования - оставлять тот формат, что был. Например, преобразовываем UTF-8 в ANSI а если в процессе преобразования произошла неудача - оставляет результат в ANSI т. к. скорее всего строка и так в ANSI.

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

Как я понимаю, гораздо надёжнее и стабильнее - перехватывать свойства Text, Caption и прочие у объектов и писать свои наследники стандартных объектов. По мере обнаружения крякозябр в разных местах программы - добавляем перехватчики для разных компонентов и свойств. Например, аналогично Text перехватываем обращения к Hint, аналогично Button перехватывает обращения к Edit и т. д.

И разумеется, у всех компонентов указать одинаковый шрифт (например, Arial) и RUSSIAN_CHARSET. Чтобы поведение перехватчиков было не случайным, а предсказуемым.

Как мне кажется, это единственный способ обеспечить более-менее стабильную работу программы без перехода на юникодный Delphi (написать такой модуль, который подключать ко всем формам программы в секции INTERFACE после USES всех стандартных VCL-модулей и до USES своих модулей (чтобы они - если работают с VCL - использовали уже новые обёртки)):

Не нужно. Нужно только чтобы тот код, который уже есть - продолжал нормально работать и ни в коем случае не стал хоть на 1% менее стабильным. Хорошо, что пока у большинства пользователей эта опция отключена и вообще многие вообще на Windows 7. С TntComponents если на него переходить стабильность программы может пострадать и у основной категории пользователей да и зачем на них переходить уж лучше сразу тогда наи новую версию Delphi, да и вообще любой компонент в том числе TntComponents это тоже дополнительный костыль, который также затруднит переход на новые версии Delphi в дальнейшнем.

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

Кажется, еще один сторонний компонент - то есть костыль. Который затруднит переход на новые версии Delphi и дополнительно привяжет к Delphi 7. Как мне кажется, при переходе на новые версии Delphi сам по себе появляется доступ ко многим новым стандартным компонентам - которых нет в Delphi 7 и в новых версиях Delphi придётся изобретать меньше велосипедов, тк в комплекте больше возможностей "из коробки".

Использую для распознавания JSON велосипед под названием OLE-объекта MSScriptControl.ScriptControl. Как вариант, можно еще использовать Node.js как внешнюю программу для разбора JSON - вызывая скрипт на Node и возвращая ответ в виде файла.

В общем, и так понятно - надо уходить с Delphi 7 - иначе с каждым годом количество вынужденных велосипедов будет расти и проблема велосипедов ещё в том, что зачастую менее эффективны, чем стандартные решения - в итоге дойдет до того, что программа для своей работы будет требовать Intel Core i7, да ещё и работать при этом неспешно.

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

Со своими бы велосипедами разобраться они хоть и с квадратными колёсами, зато обкатаны и работают предсказуемо. А стандартным компонентам и программам вроде Node.js я по умолчанию больше доверяю, чем разным сторонним решениям.

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

Кстати, с переходом на Delphi 2010 гадость обнаружилась. Не даёт собака писать длинные процедуры.

Выдаёт ошибку

E2283 Too many local constants. Use shorter procedures

приходится разбивать длинную процедуру на несколько более коротких

Конечно я всё понимаю, писать несколько тысяч литералов в одной процедуре это не есть хорошо. Но с другой стороны зачем выдавать ошибку достаточно предупредить, что так делать нехорошо. Чем-то напоминает глупое ограничение еще из Турбо Паскаль - размер кода не должен превышать 64 килобайта. Смешно - но изучая Турбо Паскаль в свой время - столкнулась с этим ограничением (не более 64 Кб кода) буквально на 7-й день изучения. Используя многократно Copy&Paste это совсем даже не удивительно.