Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 03 апр 2020, 23:23

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




Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: 28 авг 2013, 23:59 
Не в сети
Аватара пользователя

Сообщения: 994
Откуда: Днепропетровская обл.
Интересно, Олег. :)

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

Откроем текст модуля, внесём ошибку и скомпилируем. В тексте появится маркер (или маркеры), указывающий на ошибку. Прекрасно. Теперь выделим часть ключевого слова и "вырежем" (мышью или с помощью комбинации Ctrl+X). Конечно же никакого вырезания не произошло, но мне показалось, что маркер ошибки немного увеличился в размере. Но главное — он стал "хорошим". Теперь можно неограниченное количество раз вырезать часть ключевого слова, и будет сделана нормальная перекраска подсветки. Будет работать и копирование, и вообще кажется, это — именно то, что нужно. Но только до следующего сеанса компиляции, который опять внедрит в текст "плохие" маркеры.

Значит нам просто надо понять как сделать из "нехороших" маркеров "хорошие". Правда, фиг их знает чем они отличаются. :) И всякий раз после трансляции текста Ofront'ом если встретились ошибки — исправлять маркеры на "хорошие". Это можно сделать средствами подсистемы XDev (которая вызывает Ofront) или же вмешавшись в исходники самого Ofront'а. И вот сейчас я вспомнил, что Ofront был спроектирован для BlackBox 1.4, так что может "неправильные маркеры" — это издержки неполной совместимости Ofront'а с более новыми версиями BlackBox'а?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 авг 2013, 06:31 
Не в сети
Администратор
Аватара пользователя

Сообщения: 269
Откуда: Россия
Цитата:
Значит нам просто надо понять как сделать из "нехороших" маркеров "хорошие".
Изменением маркеров мы устраним проблему с маркерами, но останется проблема со вставкой коммандеров, картинок и прочего. А также с изменением атрибутов текста. После всех этих операций не действуют команды связанные с выделением.
Ну или подправить вставку маркеров как временную меру. Тут надо или научить Ofront вставлять "хороший" маркер или вставлять его так, чтобы Мастер это заметил и сразу же изменил, не дожидаясь нажатия клавиш. Либо нужно научить Мастер не замечать маркеры при сканировании текста. А лучше бы Мастер реагировал вообще только на символы. Но "IF msg.op # Controllers.copy THEN" следует пока оставить, потому что копирование в буфер не меняет текста, а значит и перекрашивание незачем вызывать. Это позволяет команде Copy работать и после вставки маркера, коммандера, картинки, смены атрибутов текста и т.д.
Лучше всего устранить неверный подход Мастера к запуску перекраски. Сейчас перекраска происходит когда дана команда редактирования. Но на самом деле перекрашивать нужно когда изменился текст, потому что не все команды редактирования меняют текст, а текст может смениться не только командой редактирования. Вот только как перехватить в Мастере момент изменения текста?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 29 авг 2013, 10:22 
Не в сети
Аватара пользователя

Сообщения: 994
Откуда: Днепропетровская обл.
Saferoll писал(а):
Изменением маркеров мы устраним проблему с маркерами, но останется проблема со вставкой коммандеров, картинок и прочего. А также с изменением атрибутов текста.
Да дело в том, что (с копированием и вырезанием) глючит, похоже, модуль ColorViews. Строго говоря, этот модуль не входит в подсистему Master, он даже другого автора (Trurl). И он реализует автораскраску только чисто текстовых исходников, так что о коммандерах, картинках и ручном изменении атрибутов речь здесь не идёт (модули *.Mod и открываются из текстового файла, и записываются в него, поэтому в лучшем случае нетекстовые элементы просто будут потеряны).

Другое дело встроенные в Master автором (С.Губановым) средства раскраски. Чтобы испытать их на вкус — открываем *.odc модуль и выбираем в меню:

Мастер -> Включить автораскраску в текущем документе

Для чистоты эксперимента внесём искусственно ошибку, компильнём это дело Ofront'ом (для вставки "неправильного" маркера?) и сразу же попытаемся вырезать часть ключевого слова. Как и следовало ожидать, проблем нет.

Так что подсистема Мастер сейчас не очень единообразная (я её собрал из авторского кода Губанова и предложенного Трурлем модуля для раскраски текстовых исходников) и несёт в себе несколько подходов, важное уточнение заключается в том, что открывая модуль *.Mod из текстового файла — мы запускаем автоподсветку, реализованную Трурлем в модуле MasterColorViews на базе кода Губанова:

[ XDev/System/Mod/Config.odc ]
Код: "OBERON"
  1. Converters.Register("MasterColorViews.ImportText", "MasterColorViews.ExportText", "MasterColorViews.View", "mod", {Converters.importAll});
  2. Converters.Register("MasterColorViews.ImportText", "MasterColorViews.ExportText", "MasterColorViews.View", "def", {Converters.importAll});

А когда мы открываем нетекстовый (бинарный) исходник *.odc — механизмы MasterColorViews неактивны. Но мы можем здесь включить автораскраску в текущем документе:

[ XDev/Master/Rsrc/Menus.odc ]
"Включить автораскраску в текущем документе" "" "MasterViews.Wrap" "MasterViews.WrapFocusGuard"

Либо же запустить службу раскраски:

"Запустить службу раскраски MASTER+" "" "MasterService.Start" "MasterService.StartFocusGuard"

Служба MASTER+ понимает, что нужно раскрашивать не все подряд составные документы, поэтому помимо активации службы для включения раскраски требуется добрая воля пользователя — явная вставка в документ директивы (* MASTER+ *)

Так что, как мы видим, Мастер даёт нам не один механизм раскраски, а целых три. И к последним двум претензий нет, всё работает корректно (иначе я бы постарался достучаться к Сергею Губанову). А ошибка, похоже, в коде Трурля. Том, который в модуле MasterColorViews.

А вот ссылочка, откуда я поживился кодом Трурля (за что ему огромная спасиба):
http://www.hardforum.ru/t55803-2/#post398440

P.S. Кстати, я заметил за Трурлевским кодом ещё глючок, связанный с попыткой напечатать текстовый документ *.Mod (с автораскраской) — лезет трап. Если скопировать текст и вставить в пустой документ (уже без автораскраски) — печатает. Будет желание поковырять эту ошибку — можно тестить на виртуальном принтере типа PDF Creator (чтобы не переводить бумагу).


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 30 авг 2013, 13:39 
Не в сети
Администратор
Аватара пользователя

Сообщения: 269
Откуда: Россия
Saferoll писал(а):
Лучше всего устранить неверный подход Мастера к запуску перекраски. Сейчас перекраска происходит когда дана команда редактирования. Но на самом деле перекрашивать нужно когда изменился текст, потому что не все команды редактирования меняют текст, а текст может смениться не только командой редактирования.
Если в модуль MasterColorViews добавить процедуру PROCEDURE (v: View) HandleModelMsg для отслеживания событий обновления текста и убрать слежение за событиями редактирования, то не будет проблем с буфером обмена и прочими командами редактирования.
Заодно внесем, предложенные Takun исправления, устраняющие мерцание при прокрутке и засорение буфера Undo.
Код: "OBERON"
  1. PROCEDURE (v: View) HandleCtrlMsg* (f: Views.Frame; VAR msg: Controllers.Message; VAR focus: Views.View);
  2. VAR
  3. scrlMsg: Controllers.ScrollMsg;
  4. BEGIN
  5. WITH (*
  6.   | msg: Controllers.EditMsg DO
  7. IF (msg.op # Controllers.copy) & (msg.op # Controllers.cut) THEN
  8.   v.Colorize(); v.needRefresh := TRUE
  9. END *)
  10. | msg: Controllers.TickMsg DO
  11. IF v.needRefresh THEN
  12. v.needRefresh := FALSE;
  13. Views.BeginModification(Views.invisible, v.inner);
  14. v.Colorize();
  15. Views.EndModification(Views.invisible, v.inner)
  16. END
  17. | msg: Controllers.WheelMsg DO
  18. msg.done := TRUE;
  19. scrlMsg.op := msg.op; scrlMsg.vertical := TRUE;
  20. v.inner.HandleCtrlMsg(f,scrlMsg,focus)
  21. ELSE
  22. END;
  23. focus := v.inner;
  24. END HandleCtrlMsg;
  25.  
  26. PROCEDURE (v: View) HandleModelMsg- (VAR msg: Models.Message);
  27. BEGIN
  28. WITH msg: Models.UpdateMsg DO
  29. v.needRefresh := TRUE
  30. ELSE
  31. END
  32. END HandleModelMsg;


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 30 авг 2013, 19:14 
Не в сети
Администратор
Аватара пользователя

Сообщения: 269
Откуда: Россия
Zorko писал(а):
P.S. Кстати, я заметил за Трурлевским кодом ещё глючок, связанный с попыткой напечатать текстовый документ *.Mod (с автораскраской) — лезет трап. Если скопировать текст и вставить в пустой документ (уже без автораскраски) — печатает. Будет желание поковырять эту ошибку — можно тестить на виртуальном принтере типа PDF Creator (чтобы не переводить бумагу).
В модуле MasterViews есть процедура
Код: "OBERON"
  1. PROCEDURE (v: View) CopyFromModelView- (source: Views.View; model: Models.Model);
  2. BEGIN
  3. WITH source: View DO
  4. IF model = NIL THEN
  5. v.inner := Views.CopyOf(source.inner, Views.deep)(TextViews.View)
  6. ELSE
  7. v.inner := Views.CopyWithNewModel(source.inner, model)(TextViews.View)
  8. END
  9. END
  10. END CopyFromModelView;
Если добавить в MasterColorViews в точности такую же, то проблем с печатью не будет.
Кстати, увидел, что в MasterViews уже применен патч о мерцании мыши, о котором писал выше.
Может быть еще что-то стоит перенести из MasterViews в MasterColorViews? Вот, например,
Код: "OBERON"
  1. PROCEDURE (v: View) Internalize- (VAR rd: Stores.Reader);
  2. BEGIN HALT(20)
  3. END Internalize;
  4.  
  5. PROCEDURE (v: View) Externalize- (VAR wr: Stores.Writer);
  6. BEGIN HALT(21)
  7. END Externalize;
  8.  
  9. PROCEDURE (v: View) ExternalizeAs- (VAR s1: Stores.Store);
  10. BEGIN s1 := v.inner
  11. END ExternalizeAs;
, описанные здесь. Может перенести и их, или они конфликтуют с юникодностью?
А вот еще полезный патч от Takun, устраняющий проблемы со ссылками из TRAP. Его тоже стоит добавить.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 13 сен 2013, 21:05 
Не в сети
Аватара пользователя

Сообщения: 994
Откуда: Днепропетровская обл.
Saferoll писал(а):
Может перенести и их, или они конфликтуют с юникодностью?
Без понятия. :) Но если брать современное состояние ColorsViews, то пока что юникодность ему особо не грозит. Слишком много направлений надо доработать, так что пока оставим так.

Внёс все патчи и очень удовлетворён их действием. Глюки с вырезанием и копированием исчезли, печать работает. Вобщем, всё замечательно. Огромная благодарность Takun'у и Saferoll за их работу! Сам бы я уж точно с этим долго ковырялся, если вообще бы осилил.

Если говорить о доработках в этом направлении, то нужно будет сделать новую процедуру для обработки File -> Open. Это нужно, чтобы при открытии исходника по умолчанию там была бы задана группа фильтров, вместо текущего *.odc:

*.Mod; *.ob2; *.cp; *.odc

А то открывание исходников в форматах, отличных от *.odc, превращается в лишние клики для опытных юзеров и в полную непонятку и незамечание части исходников для новичков. Сделаю на днях, а если забуду, то этот пост и будет напоминанием. :)


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 16 сен 2013, 01:59 
Не в сети
Аватара пользователя

Сообщения: 994
Откуда: Днепропетровская обл.
Сделал фильтр расширений по умолчанию: *.Mod;*.Def;*.odc Сильно помог пост Ильи Ермакова.

Я добавил альтернативную процедуру Open в MasterColorViews. Получилось не совсем то, что я хотел — при замене вызова HostDialog.GetIntSpec на Dialog.GetIntSpec в итоге все фильтры исчезли из списка (кроме *.*), но это терпимо, пускай пока будет так.

Илья Ермаков писал(а):
И будет уже пофиг, что в списке ещё и odc ниже болтается.
Да вот не совсем пофиг, там кроме *.* уже ничего не болтается. :) Хотя список конвертеров Dialog.GetIntSpec тоже вроде строит, но диалог запроса имени файла его не отображает.

Кстати, длина строки фильтра расширений — всего 16+2 символов, и когда подоспеет необходимость добавить в фильтр ещё типов (*.ob2, *.cp, *.ob7 и т.д.) — придётся всё-таки вламываться в стандартные модули, чего конечно не хотелось бы.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 сен 2013, 22:26 
Не в сети
Аватара пользователя

Сообщения: 994
Откуда: Днепропетровская обл.
По ходу использования MasterColorViews заметил, что ширина по умолчанию открываемого исходника *.Mod выглядит недостаточной (сужу по напечатанному на лист A4 исходнику плюс общему впечатлению как на десктопе, так и на ноуте с различным разрешением экранов). Поэтому решил увеличить эту ширину.

Там есть ширина самого окна и ширина текста документа, и это 2 разных параметра. По умолчанию окошко создаётся стандартной ширины, а ширина текста выбрана Tools -> Document Size... -> Fixed. Я экспериментировал с этим: менял на Windows Width (ширина показалась недостаточной), в итоге остановился на Page Width. Хотя ширина Windows Width мне показалась более естественной, но я не сумел увеличить ширину самого окна, так что остановился на Page Width, которая обеспечивает самое лучшее заполнение текстом для ширины окна по умолчанию.

Для этой модификации пришлось всего-навсего добавить такой код:
Код: "OBERON"
  1. PROCEDURE (v: View) HandlePropMsg- (VAR msg: Properties.Message);
  2. BEGIN
  3. WITH msg: Properties.ResizePref DO
  4. msg.horFitToPage := TRUE; msg.verFitToPage := TRUE
  5. ELSE
  6. END
  7. END HandlePropMsg;
Остаётся в силе вопрос: как правильно изменить ширину окна по умолчанию (тогда ширину документа, ясно, установим в FitToWin) и где она вообще задаётся? И если ответ на первый вопрос более или менее понятен, т.к. в документации есть примеры, то особенно конечно интересует последний вопрос, в каком месте исходника и как именно, в каких величинах (сантиметрах, дюймах) задана ширина по умолчанию? И хорошо бы её в итоге выравнить для оптимальной печати на листе формата A4.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 сен 2013, 22:30 
Не в сети

Сообщения: 204
Zorko писал(а):
По ходу использования MasterColorViews заметил, что ширина по умолчанию открываемого исходника *.Mod выглядит недостаточной (сужу по напечатанному на лист A4 исходнику плюс общему впечатлению как на десктопе, так и на ноуте с различным разрешением экранов).
...
И хорошо бы её в итоге выравнить для оптимальной печати на листе формата A4.

У них же там на западе принято печатать не на листы A4, а на листы Letter, которые гораздо уже, чем A4...


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 27 сен 2013, 22:41 
Не в сети
Аватара пользователя

Сообщения: 994
Откуда: Днепропетровская обл.
Ну, наверно привязка к A4 и не столь уж важна, просто более естественным практически для любого текстового редактора поведением является выравнивание текста по ширине окна: на сколько нужно — на столько и вытягивай. А BlackBox выравнивает текст до какого-то внутреннего предела, и дальше как широко не тяни окно — он перестаёт выравнивать под него текст.

А сколько уже делать знаков по ширине — это личное дело программиста. Я выравниваю под A4, кто-то под Letter. Но мне не удалось сделать ширину по умолчанию побольше. Хотя я понял как это делается — наследованием от Views.View и перекрытием стандартных обработчиков своими. :) И даже понял какой и как надо сделать обработчик, просто не хочется задавать ширину наобум, надо посмотреть как это умные люди делают. ;)


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

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


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

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


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club