Штирлиц, я не беспокоюсь о том, что фоновые процессы будут "воровать мышь". Если кто напишет такой процесс, то это будут его личные проблемы.

Познакомьтесь, пожалуйста, с процедурой Views.ForwardCtrlMsg и механизмом определения сфокусированного View. Потом посмотрите документацию про Properties.FocusPref.hotFocus. Поэксперементируйте, я же просил. Вы поймете, что SetCapture далеко не достаточно для того, чтобы оповещать View об отпущенной кнопке мыши. В том-то и проблема, что фреймворк не знает, кого оповещать. Не предусмотрено такое знание.

Если мне не верите, попробуйте перевести на раздельный режим работы хотя бы тот же DevCommanders.StdView (он использует hotFocus). Вы увидите, что никакие сообщения TrackMsg или PollCursorMsg не приходят к View, если курсор мыши не находится непосредственно над ним.

То, что вы написали по поводу SetCapture/ReleaseCaputre, совершенно верно. И это действительно необходимо будет сделать в том или ином виде. Но это только API-шная, внешняя сторона дела. Я же вам толкую о том, что внутреннее устройство фреймворка BlackBox не содержит необходимых механизмов для реализации функций, подобных API-шным SetCapture/ReleaseCaputre. Окно Windows с его процедурой обработки сообщений - это одно, а Views.View с его HandleCtrlMsg - это совсем, совсем другое.
> -- Штирлиц писал(а):
> Ничего страшного в нет в том, что процесс разбит на три части: "вход в режим", "работа в режиме" и "выход из режима"...Тысячи приложений под Windows (думаю и под Unix все обстоит примерно так же) работают с мышью по схеме "вход в режим", "работа в режиме" и "выход из режима" и ничего. Никто у них мышь при этом не вырывает.
Переписать многое придется, но хорошо, что это вас не пугает. Хотя лично мне, немного полазившему по подсистеме Text, не очень хочется там что-то усложнять. Меня беспокоит то, что поскольку состояние, например, выделения блока текста мышью, является режимом, то это состояние нужно где-то помнить между обработками сообщений мыши. И при этом еще надо иметь в виду, что все обычные операции по правке текста могут в этот режим вмешаться. Именно это я имел в виду под угрозой фоновых задач, а не какое-то непонятное "воровство мыши". Опишу подробнее.

Возьмем для примера простой чат. Пусть, есть фоновая задача, получающая данные из COM-порта или из локальной сети. Эта зачада при получении данных или команд производит соответствующие операции над текстовым документом - например, вывод полученного от удаленного пользователя сообщения. Представьте, что вы начали выделять блок текста в этом самом документе. Вы нажали кнопку мыши и объект запомнил номер символа, с которого начато выделение (пусть это будет 15-й символ). Вы переместили мышь и размер выделения стал равен 5 символам (с 15 по 19-й включительно). Документ перерисовался, отобразив указанные символы выделенными. Тут фоновая задача чата получила команду от удаленного пользователя: очистить текущий документ. Затем вы продолжаете перемещать мышь, выделяя 20-й символ. Документ пытается перерисоваться с выделенными символами с 15 по 20 и выходит за пределы доступного текста. Вы видите сообщение об ошибке.

Что демонстрирует данный гипотетический пример? То, что мало хранить переменные состояния режима в отдельном месте. Нужно еще и обеспечить адекватную реакцию этого самого режима на все возможные раздражители. Другими словами, вы должны досконально знать объект и все возможные приемы и способы работы с ним, чтобы добавлять в него новый режим, не добавляя ошибок. Для DevCommanders.StdView это достаточно просто реализовать, поскольку у него только 4 состояния. Для подсистемы Text я бы за такую работу не взялся.

Вот поэтому явный режим в виде плотного цикла с Rider.Input мне кажется куда более простым решением, чем введение полускрытых режимов с нелокальными переменными состояния в сложные объекты. Это мое мнение. Я не говорю, что это невозможно, я просто говорю, что это не тривиальная задача. И тысячи программ для Windows и Unix, написанные с использованием стандартных EDIT-контролов, тут нам ничем не помогут. Фреймворк надо дорабатывать.