такой вопрос: есть ли какой-то штатный способ получить главное окно BBCB? ну, то, в котором меню живёт и всё остальное? предполагаем, что оно у нас точно есть.

задуманы-то они задуманы, но штатного способа создать «главное» окно минуя StdConfig нет, а поэтому оно особенное. мне кажется, надо или экспортировать процедуру создания главного окна (и чтобы она его возвращала), или автоматически его регистрировать где-нибудь, чтобы можно было получить стандартными средствами.

кстати, ещё было бы неплохо иметь штатное средство определить статус «detached» у окна, чтобы не импортировать повсюду патченый тайлер. мало ли, вдруг другой тайлер будет, с другим докингом? тогда можно будет просто перебрать все окна и пнуть перерисовываться только те, что detached.

ужасно, кстати, неудобно, что в неактивных окнах выделение текста просто прямоугольничком. не знаю как вы, а я при поиске и замене иногда этот прямоугольничек тупо не вижу, приходится переключаться на окно с текстом и обратно. по какому поводу предлагаю завести специальный код для `MarkRect()`, и в неактивных окнах тоже делать полную инверсию, но цветом Ports.grey75. будет такое грустно-серенькое, но заметное. я себе так сделал, и получилось намного, намного лучше. я, в принципе, себе опцию приделал, чтобы можно было вернуть старый вариант, если кому охота.

p.s.: и, кстати, вынести `focusSel` в Ports. всё равно его надо реализовывать, потому что ним механизмы пользуются — ну так пусть уже будет всем доступно тогда.

Так может в StdConfig и вынести в глобальную переменную это окно?

но ведь и не мешает!

я сделал так: ввёл в StdWindows.Window булеву переменную `isRoot`. она делает ровно ничего, просто существует. API позволяет назначить какое-то окно главным (у всех остальных окон тогда этот флажок сбрасывается). чисто информационная штука, кроме как посмотреть на неё и установить StdWindows больше с ней ничего не делает, всё остальное — на усмотрение кода приложения. можно использовать флажок, можно не использовать. соответственно, StdConfig для рут-окна этот флажок ставит апи-вызовом, и дальше я могу его проверять. а если кто-то не поставит — ну, не поставит, ничего страшного. надо бы документировать будет его потом, да и всё. впрочем, StdWindows вообще не документированы, увы. (это не претензия, это сожаление. я может постараюсь как-нибудь скелет документации сделать.)

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

продублирую и здесь:

мой компилятор, кстати, можно (и нужно, я считаю) полностью утаскивать в mainline, достаточно поменять `inCP := FALSE;` на `inCP := TRUE;` в `DevCPP.Module`. совместимость почти полная, исключение ровно одно: проверка на отсутствующие RETURN более строгая. утаскивать затем, что у меня точно есть багфиксы к оригиналу, которых в mainline нет (а какие точно — я уже не помню). заодно в майнлайне появится ассемблер для X86, приятная фича.

для утаскивания надо будет `UP.` поубирать, просто заменой на пустые строки, а также перевести обратно с моего SubsManager на StdLibrarian. в общем, мелочи.

DevAnalyzer тоже, с теми же изменениями (и я там докинул пару опциональных фич — типа не квакать про обращение к «неинициализированым глобалам» — это обычно false alarm).

а вот выборочно лучше оттуда ничего не переносить, если брать — то всё вместе. форматы ocf/osf я не менял, так что оно безопасно.

а! если соберётесь забирать — то мне надо будет вернуть поддержку COM обратно. лучше, в общем, если согласны — скажите мне, я тогда начну адаптацию к mainline сам. просто если нет, то я не буду париться.

эм... ребят, вы клёво прикололись, прямо как классическое сишное `#define TRUE FALSE`, только наоборот. в хидерах gtk (Gtk2GLib):
нет, серьёзно? клёвая шутка, я чуть не лопнул хохотаючи.

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