OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 18:56

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Операции в открываемых окнах
СообщениеДобавлено: Вторник, 09 Май, 2023 08:20 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
задумался, что надо бы для 2.0 делать какой-то механизм выполнения действий после того, как окно (именно окно) было активировано и отрисовано.

зачем надо? потому что раньше окна можно было открывать и рисовать без ухода обратно в event loop. поэтому менюшки полны командами типа: «открыть документ; найти текст в сфокусированом документе». это, естественно, работало.

в 2.0 же окна окрываются довольно хитро, через отложеные действия. неважно, почему, Так Надо. но это поломало все поиски. сейчас в коде оно обходится просто пинанием поиска через Action, чтобы отложеный Action открытия окна успел отработать. это хак, хак кривой, и работает оно не всегда стабильно.

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

среда пусть запоминает документ (и/или View), который был использован для открытия recent window. помнит она это пусть до следующего оборота event loop. также в среду вводится API для задания действия, которое должно выполниться, когда последнее открытое окно в первый раз отрисуется (по типу Action, только не по таймеру, а по условию).

таким образом, надо будет поменять только `TextCmds.FindFirst()` и прочие, и не лепить везде хаки с отложеными Actions: `FindFirst()` проверит, открывалось ли окно, и если да, то само действие отложит.

чистить запомненые окна на каждой итерации event loop надо затем, что это самый простой способ отличить исполнение коммандера (или пункта меню, или кнопки, или ссылки…) типа «открыть-найти» от просто «найти». интерпретатор выполняет действия по порядку без возврата в event loop, поэтому если переменная «последний открытый view» установлена — то мы можем быть более-менее уверены, что это именно тот view, который имелся в виду как фокусная цель для команд. а потом цикл переменную почистит, и можно как раньше брать нормальный фокус.

я пока это не сделал, только обдумываю. попробую реализовать в LC и посмотреть, что получится. кидаю идею сюда, а не в тему 2.0, потому что надо на практике обкатать. но я считаю, что в принципе это должно пойти в 2.0 как можно быстрее, потому что любой код с вызовом поиска в 2.0 безнадёжно сломан, и его весь надо хачить. а с моим предложением старый код сможет более-менее работать: ну, если сам ничего с фокус-документом не делает, а просто поиск вызывает. а если делает — то у нас хотя бы будет стандартный механизм для того, чтобы починить код надёжно, а не полагаться на хак с задержками.

хотелось бы (пока я делаю свой хак) услышать мнения коллег: может, у кого-то есть идея лучше? приветствую как идеи с Более Красивыми Хаками, так и идеи по изменению интерфейсов вообще. первые для mainline, вторые могут пригодиться для LC. потому что даже Величайшему Гению Всех Времён И Народов Мне иногда не грех украсть чужую идею и выдать за… неважно, в общем, делитесь вашими идеями!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Май, 2023 10:28 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Желание открывать окна с кадрами на старый блокирующий манер. Сейчас, как я понимаю обновление окна по открытии идет через Views.Update, поэтому откладывается. И из-за этого кадра текстового вида нет в момент поиска активного контроллера, сообщения о показе выделенной области тоже не приходят и т.п. Однако почему бы не сделать блокирующее обновление дерева фреймов в момент открытия нового окна в плитках? Как я понял для этого есть Views.ValidateRoot. Это мысли вслух, я глубоко в эту тему не вникал. Антон быстро добавил поиск через отложенные действия (он сам говорил про то, что это быстрохак), но потом мы сфокусировались на других вещах, и к сожалению, эта проблема осталась в подвешенном состоянии. Было бы здорово коллективным разумом это додумать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Май, 2023 14:04 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
проблема в том, что в тайлере окна — это вложеные фрэймы. которые — по правилам среды — можно добавлять только внутри Restore. вдобавок к этому grid должен ещё и кучу внутренних фрэймов создать в этот момент: таб, закрывашку на табе, возможно ещё какие-то служебные штуки, если grid продвинутый. в общем, там может происходить очень много всякого, что в оригинале делает host OS. а в нашем случае оно затрагивает стандартные механизмы среды, и поэтому для безопасности должно происходить не в любой момент, а в цикле обработки сообщений.

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

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

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

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

p.s.: я в процессе разработки LC довольно глубоко ковыряюсь в кишках среды, так что это не просто спекуляции, а более-менее educated guess. я не к тому, что не могу ошибаться, а к тому, что я сейчас более-менее понимаю внутреннюю механику (не полностью, но довольно глубоко). замечу кстати, что одна из прелестей BBCB в том, что один человек — в принципе — может путём чтения исходников (и небольшого количества экспериментов) составить представление о том, как всё работает. с дельфийским VCL у меня в своё время такой финт не прошёл, я сломался намного раньше. к тому же пересобирать VCL с нуля, когда хочется поэкспериментировать… ну, кто пробовал — тот знает, что это близко к нереальной задаче. ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Май, 2023 14:26 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
p.p.s.: засаммоньте в тему Антона Александровича, если возможно, пожалуйста. просто чтобы он подтвердил (или опровергнул) моё понимание дизайна тайлера.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Май, 2023 07:58 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
проблема в том, что в тайлере окна — это вложеные фрэймы. которые — по правилам среды — можно добавлять только внутри Restore.

Views.ValidateRoot так то вызывает все Restore.

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

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

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

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

Ещё идея, почему бы не построить сразу это всё в некой безопасной среде не откладывая. А после открытия окна разместить где надо в окне ББ, и уже сразу с выделенным текстом?

В общем, я топлю за то, чтобы ничего не надо было менять в логике ББ по возможности. Уже вот с диалогами открытия файлов история, что Views.OpenView переделывать на колбэки как-то надо из-за отсутствия модального диалога выбора файлов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Май, 2023 10:59 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
arisu писал(а):
проблема в том, что в тайлере окна — это вложеные фрэймы. которые — по правилам среды — можно добавлять только внутри Restore.

Views.ValidateRoot так то вызывает все Restore.
в этом и проблема.

Иван Денисов писал(а):
Среда не гарантирует, что старые кадры должны жить ни в какой момент времени, в цикле обработки сообщений или нет. Среда имеет право в любой момент перестроить кадры. По крайней мере я так понял Антона, может и неверно.
вот тут неверно: дерево кадров нельзя перестраивать в процессе обработки сообщений. именно поэтому, например, из цикла `f.Input()` не рекомендуется вызывать зафорсеные рисовалки: в большинстве случаев дерево фрэймов не изменится, но никакой жёсткой гарантии этого нет. если вдруг изменится — всё может трапнуться или вообще случится UB.

Иван Денисов писал(а):
Если наше окно перекрылось новым, то лучше остановить обход кадров, где бы мы там не были. Довольно предсказуемое поведение.
это невозможно: мы можем находиться где угодно в глубине кода в этот момент, и код этот свою работу ещё не закончил.

Иван Денисов писал(а):
Ещё идея, почему бы не построить сразу это всё в некой безопасной среде не откладывая. А после открытия окна разместить где надо в окне ББ, и уже сразу с выделенным текстом?
по двум причинам: во-первых, такой возможности просто нет. во-вторых, на данном этапе мы не обязательно знаем размер окна: его определит и зафорсит grid, когда будет добавлять новую вкладку.

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

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

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

Иван Денисов писал(а):
В общем, я топлю за то, чтобы ничего не надо было менять в логике ББ по возможности.
увы, так не выйдет: отложеное создание окна вызвано технической необходимостью, его никак нельзя обойти без полного переписывания всей механики рисования и распространения событий. и тогда у нас уже получится совсем не тот BBCB. наименее интрузивный вариант — это возможность задавать выполнение неких действий после первой отрисовки окна.

ну, или другой вариант, не менее неприятный: тайловый менеджер надо полностью выводить из-под контроля BBCB. то есть, переписывать тайловый менеджер (StdGrids, StdMenus, и частично StdTiles) так, чтобы там вообще не использовались ни Views, ни стандартные механизмы отрисовки BBCB. по сути, лепить эмулятор host OS внутри BBCB. и мы теряем единообразность среды, и все приятные фичи типа реализации менюшек как обычных View, грида как обычного View, и так далее. в общем, пишем рядом с уже существующей системой Frame/View ещё одну, свою, полностью от неё независимую. а это, как я понимаю, именно то, чего А.А. хотел избежать, когда создавал тайлер.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Май, 2023 20:47 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
окей, у меня появилось подозрение, что можно сделать абстрактный интерфейс для тайлера, который будет получать предполагаемые размеры нового окна, и реализовать его в гриде. это решит проблему размеров. и второе подозрение — что можно сделать первую отрисовку в невидимой области, чтобы появилось дерево фрэймов.

но остаётся большая проблема: сделать `Select()` с таким окном нельзя, потому что технически его ещё нет. то есть, оно никуда не «приписано». а та же `TextCmds.FindFirst()` работает именно с текущим выбраным окном. я нутром чую, что это можно решить, сделав апи для reparenting корневого кадра (вроде бы несложно), и скомандовав гриду «усыновить» это окно потом (через action).

короче, вот такая механика:
1. создаётся новое окно-сиротинушка (на этом этапе оно принадлежит ultimate root), сдвигается в невидимую область, пинается процедура (тоже новая) восстановления корневого кадра этого окна. рисоваться ничего не будет, но правильная структура фрэймов создастся. (тут же мы спрашиваем у грида через API его будущие размеры.)
2. это окно-сиротинушка добавляется в список окон, и теперь с ним можно сделать Select.
3. гриду поступает команда усыновить это окно когда-нибудь потом.
4. на этом этапе визуально ничего не поменялось, текущая структура фрэймов не нарушена, но у нас уже есть новое активное окно с правильной структурой фрэймов, поэтому `TextCmds.FindFirst()` и прочие спокойно отрабатывают без всяких хаков.
5. рано или поздно выполняется action у грида, и грид усыновляет это новое окно.

один corner case: окно могут закрыть до того, как его усыновит грид. это надо предусмотреть. ничего сложного, просто не забыть о такой возможности.

итого: исполняется мечта о том, чтобы весь код для прежних BB работал, и не надо особо ничего переписывать.

я пока не уверен, что такой финт получится, но скорее всего получится. попробую реализовать в LC, если удастся — то тогда портирую реализацию на mainline. а если не получится — то получу массу полезного опыта, как обычно. ;-)

в общем, Иван Андреевич, вашу идею про «создать в безопасном месте, потом засунуть куда надо» похоже, таки, можно реализовать. спасибо за то, что заставили меня над ней подумать плотнее. ;-)

p.s.: потенциально получаем механизм для создания всяких popup-нотифиакторов и прочего подобного (включая тултипы): ведь не обязательно, чтобы окно усыновлял грид. тут придётся немного поработать, сделав у окон флажок "on top", так что это как-нибудь потом. но в принципе — можно, и встроеные тултипы для views можно будет сделать не пользуясь механизмами host OS.


Последний раз редактировалось arisu Среда, 10 Май, 2023 20:57, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Май, 2023 20:56 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Очень круто, что вы уловили и развили ход этой мысли,
Буду ждать результаты ваших экспериментов!
В целом такой приём с "буферизацией фреймов" может быть весьма полезен, а в этом случае — спасителен.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 12:10 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
часть идеи работает: при создании нового окна, даже если оно не принадлежит никому (то есть, у него нет хозяина-RootFrame) — можно инициировать создание дерева фрэймов. оно создаётся, там появляется тектовый документ, из него можно добыть контроллер, и выбрать там текст (то есть, и `TextControllers.SetSelection()` тоже работает, но надо ж мне текстовую модель для него добыть откуда-то!). после чего окно будет нарисовано уже с выбраным текстом. правда, текст отчего-то выбран, но при отрисовке окна до него не скроллит, он выбран где-то там, внизу. с этим надо разбираться ещё.

тем не менее, начало мне нравится: идея про то, что можно создать правильное дерево фрэймов без отрисовки окна, очень похожа на рабочую. теперь надо смотреть, что происходит с активацией окна через `Select()` — когда именно оно попадает в нужный путь, и можно ли совсем «бесхозное» окно сделать активным, и что от этого сломается.

выглядит по логам это примерно так:
Код:
TILERBACK: SELECT
TILERBACK: SELECT: OK: <lament_whatsnew.odc>
  HAS ROOT FRAME; unit: 9630; l: 0; t: 0; r: 844; b: 894
  STATE: 1
  NO OWNER!
  HAS VIEW: StdDocuments.Document
  HAS PORT!
  HAS RIDER!
  HAS CONNECTED RIDER!
  OBSCURED!
  BUILDING FRAME TREE...
    Views.RootFrame[B62ACC20H]; view: StdDocuments.Document[B62AC850H]; state: 1; level: 0; l: 0; t: 0; r: 844; b: 894
  NEW FRAME TREE
    Views.RootFrame[B62ACC20H]; view: StdDocuments.Document[B62AC850H]; state: 1; level: 0; l: 0; t: 0; r: 844; b: 894
      Views.StdFrame[B62AD120H]; view: TextViews.StdView[B62AC210H]; state: 1; level: 0; l: 0; t: 0; r: 832; b: 882
  HAS TEXT CONTROLLER!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 15:23 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
итак. имею сказать, что со странным адовым хаком я таки добился, чтобы `TextCmds.FindFirst()` (и компания) работали без необходимости впиливать отложеное действие.

с построением фрэймов особо проблемы нет. окно тоже правильно становится активным. но есть другая проблема: отчего-то нифига не возвращается правильный фокус (хотя ставится правильно). то ли от того, что окно в очень странном «ничейном» состоянии, то ли что-то ещё. я впилил хак в `Views.ForwardCtrlMsg()`, который для «ничейных» окон форсит фокус — и поиск заработал. даже показывает правильно, если найденая строка где-то глубоко внизу.

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

по ходу, кстати, если включить режим «Separate new windows», то с ними точно такая же ерунда: там поиск тоже не работает, потому что фрэймов нет. пока что я сделал перестройку только для тайл-окошек, остальное потом буду смотреть.

кто мне пояснит, каким вообще образом `Controllers.PollFocusMsg` то работает, то не работает — тому подарю конфетку самовывозом.

tl;dr: в принципе, можно оставить на месте хак, и все команды, которые открывают окно и потом сразу пытаются получить контроллер в фокусе, будут работать. но хочется понять и сделать красиво.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 15:49 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
вот вам даже видео. смотрите, завидуйте: я мегахакер, а не какая-то там…


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 16:46 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
всё, понял. поскольку у ничейного окна нет фрэйма выше, то `ForwardCtrlMsg()` не вызывает для документа `ConsiderFocusRequestBy()`, и его надо звать руками после форсированого построения дерева фрэймов. тогда запрос фокуса работает безо всяких хаков.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 17:53 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
в общем, я интегрировал фикс в LC и поубирал все (вроде бы) хаки из Dev. everything seems to work so far. погоняю несколько дней, и если всё будет нормально — портирую на mainline. изменения получились на удивление локализованые, и их совсем немного.

режим «открывать сразу в отсоединённых окнах» я пока не починил: хочу сначала погонять фикс. если не забуду — потом и его попробую пофиксить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 20:18 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
а чтобы я не один мучился — вот пересаженый на mainline вариант. пересаживал на скорую руку, но вроде бы работает. там же файлы с убраными хаками для поиска. можно погонять вместе со мной.


Вложения:
Комментарий к файлу: апдейт
_betteropen_v00.7z [61.58 КБ]
Скачиваний: 88
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 20:23 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Супер, скачал, попробую сегодня.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 21:36 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
да, имею покаяться: я там выше в попытках пояснить, почему нельзя сделать то, что я сделал (хех), довольно много ерунды написал. про то, что дерево фрэймов нельзя трогать в процессе обработки сообщений — это правда. а остальное вмеремешку правда и чушь. простите, так бывает. если соберусь с силами — потом напишу правильно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 21:45 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Большое улучшение получилось! Уже и содержанием справки возможно пользоваться удобно. Работает показ цели.

Что пока не работает. Если запустить проверку ссылок, то вот на нужную ссылку он не перепрыгивает.

Получается, что вот эта процедура не отрабатывает v.ShowRange(pos, pos + 1, TextViews.focusOnly) корректно.
Код:
   PROCEDURE Open* (path, file: ARRAY OF CHAR; pos: INTEGER);
      VAR loc: Files.Locator; v: Views.View; bug: Files.Name; c: TextControllers.Controller;
   BEGIN
      ASSERT(file # "", 20); ASSERT(pos >= 0, 21);
      PathToLoc(path, loc); ASSERT(loc # NIL, 22);
      bug := file$;
      v := Views.OldView(loc, bug);
      IF v # NIL THEN
         WITH v: TextViews.View DO
            (* v.DisplayMarks(TextViews.show); *)
            Views.Open(v, loc, bug, NIL);
            c := v.ThisController()(TextControllers.Controller);
            c.SetCaret(pos);
            v.ShowRange(pos, pos + 1, TextViews.focusOnly)
         ELSE
            HALT(23)
         END
      END
   END Open;

Я не знаю, возможно ли это исправить в рамках этого исправления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 21:50 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Очень радует возвращение работоспособности вот этих волшебных кнопок! Очень не хватало.


Вложения:
wokring.png
wokring.png [ 28.54 КБ | Просмотров: 5474 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Май, 2023 22:19 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
Я не знаю, возможно ли это исправить в рамках этого исправления.
по какой-то мне не очень понятной причине (видимо, всё-таки связано с режимом «окно в окне» или чем-то ещё) попытка показать область через view не работает. надо примерно так теперь:
Код:
TextControllers.SetCaret(c.text, beg);
TextViews.ShowRange(c.text, beg, end, TextViews.focusOnly)

если пройдёт через сообщения — то обычно работает. если напрямую через view — то нет. мне такой же код в DevDebug пришлось заменить на то, что я выше показал, а то не работало.

Иван Денисов писал(а):
Очень радует возвращение работоспособности вот этих волшебных кнопок! Очень не хватало.
а вот это я точно специально не делал! ;-) скорее всего, это потому что в принципе любой код, который контроллер из фокуса берёт, теперь должен работать. а может и просто случайность. честно говоря, не помню, что там конкретно. но если заработало что-то, что раньше не — то это здорово! ;-)
(примечание: а, да, они ж на текст прыгают той же механикой, что и все остальные. все такие штуки теперь будут работать, если делают это не напрямую через методы view, а через публичные процедуры модуля.)

p.s.: я постараюсь на днях разобраться, почему через view сломалось. может, получится и это починить. но на всякий случай не обещаю. ;-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Май, 2023 00:24 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Спасибо подправил на такой же манер. Проблема была крайне острая, поэтому отправил ваше решение в сборку. Так вероятнее могу выявиться какие-то проблемы. Но я пока ничего не обнаружил. Проверил и MDI сборку для Windows.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB