OberonCore

Может быть надо вызывать не Update, а UpdateList? По крайней мере для списков и деревьев вызывать надо как раз именно UpdateList...

Для стандартных Sql-таблиц действительно надо вызывать UpdateList. Но это потому, что в них стоит своя обработка NotifyMsg. Возможно, что вы кусок кода взяли оттуда.

Если хотите, скиньте код мне на мыло: ermakov@metasystems.ru, постараюсь посмотреть, в чем проблема.

Конечно хочу! Скинул. Код ниоткуда не брал. Сам писал по документации.

Попробовал. Никакой разницы.

Для наглядности переписал 2-е процедуры, чтобы размер таблицы побольше был.


Далее создал меню:


Дальше делаю Controls/New Form/Empty.
Потом Sacred/Insert Table Control
Потом Tools/AddScroller.
Потом захожу в свойства таблицы и устанавливаю линк на SacredTables.test, нажимаю Apply.
Прорисовывается таблица (причём она не влазит в скроллер) В Message Spy отчётливо видно, что посылаются только 2 сообщения:
Properties.PollMsg и Properties.ResizePref
Естественно полосы прокрутки не появляются....

Можно пойти другим путём и присвоить линк программно, через Dialog.Update. Результат аналогичный.

Однако если после этого сделать двойной (или 2 двойных, точно не понял) щелчок мышой по таблице, она обрамляется штрихованной рамкой и скроллеры появляются! И прокрутка работает нормально. Но без этого интерактивного действия, прокрутка появляться не желает. Сообщение PollSectionMsg мне увидеть ни разу не удалось...
В чём подвох?

Возможно, в режиме Layout сообщения посылаются не сразу. В режиме маски все нормально?

В режиме маски добиться полос прокрутки не удаётся вообще никакими действиями. Вы не подскажете, что вы делали, чтобы у вас начали посылаться сообщения PollSectionMsg? Если не трудно, приведите, пожалуйста последовательность ваших действий.

Сначала я для эксперимента исправил обработку PollSectionMsg:
IF msg.vertical THEN
msg.wholeSize := 20;
msg.partPos := 10;
msg.partSize := 7

Потом нажимал на командер внизу вашего файла. Копировал из текста - вставлял на форму. Настраивал Link. Вызывал AddScrollers. После этого вертикальная полоса прокрутки появлялась мгновенно.

Это не показательный случай. На самом деле мне надо добиться, чтобы при изменении данных, таблица сама перерисовывалась и если надо менялись бы полосы прокрутки. Делаем так:
Меняем окончание модуля на:


На пустую форму кидаем таблицу, присоединяем её к SacredTables.test, обворачиваем в скроллер. Полосы прокрутки не появляются, это правильно, т.к. таблица пустая. Далее добавляем командную кнопку, свяываем её с SacredTables.SetLink.
Открываем окно As Tool Dialog. Нажимаем кнопку, которая на форме.
Что имеем - ничего. Таблица не перерисовывается, скроллеры не появляются. Если окно чем-нибудь перекрыть, таблица перерисуется, но скроллеров всё равно не будет...

Проблема оказалась проста:

1) процедура Update должна выглядеть вот так:

PROCEDURE (c: Control) Update- (f: Views.Frame; op, from, to: INTEGER);
BEGIN
Views.Update(c, Views.keepFrames)
END Update;

Как раз эта процедура определяет, как ваше отображение будет реагировать на Dialog.Update.

Или можно так определить UpdateList - это уже в зависимости от того, хотите ли вы реагировать на Update или UpdateList. Вообще говоря, для "объемных" элементов лучше UpdateList (хотя StdTables почему-то сделаны под Update).

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

2)в HandlePropMsg2:

| msg: Properties.FocusPref DO
msg.setFocus := TRUE (* Обязательно, иначе прокрутки не будет! *)
- эта обработка действительно нужна, чтобы обертка-скроллер нормально обновлялась.
Сами же написали - обязательно, а потом зачем-то закомментировали!


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

Действительно. Спасибо огромное.
Однако как выяснилось вчера, проблема на этом не умерла. Как только я вставил свою таблицу в TabView, всё стало работать как прежде: то есть не работать. Я даже сделал 2 таблицы: одну вставил в форму, а вторую в tabview на форме. Та, что на форме сразу показывает скроллеры (естественно, при наведении мыши), а в TabView - молчит как партизан.

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

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



Ну, отлаживать-то здесь ничего не надо. Я лично разбирался во всем, сначала прочитав документацию, а потом внимательно изучая исходники. От прогонки на отладчике в большинстве случаев польза сомнительная. Конечно, помогает увидеть граф управления для конкретного случая, но это можно сделать и остановкой по HALT.

Скинул по почте.
Исходники и документация - это супер полезно, не спорю, было бы время.
А как можно в нужном месте остановить программу по HALT?

>А как можно в нужном месте остановить программу по HALT?
Ну, вставляете HALT(номер). В результате - принудительный треп, с выбросом дампа.

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

P.S. Внутри меня всё противится исправлению исходных кодов ББ ТОЛЬКО для целей отладки.

Исходники Ваши получил, погляжу сегодня!


Выбрасывать дамп HALTом из какой-нибудь внутренней процедуры ББ приходится часто. Главное - все возвращать на место.
Вчера боролся с интересной вещью: если текст открыт в режиме маски, и в нем есть вложенные блоки, то PageUp, PageDown, стрелки будут крутить не весь текст а самый вложенный блок! Такова политика Containers.Controller - сообщение EditMsg проходит насквозь до самого фокуса, каковым является вложенный текст. Решение казалось простым - на уровне своего собственного Scroller (а такой у меня есть) отловить это сообщение (а StdScroller пропускает насквозь) и крутить принудительно наружный текст. Но почему-то это работало только в половине случаев! Пришлось долго ставить HALT в Containers и изучать поведение среды. Оказалось, что поведение зависит от того, сфокусирован ли уже текст на форме или нет. В первом случае посылается сообщение EditMsg - а во втором PgUp обрабатывается прямо на уровне оконной процедуры приложения - а дальше шлется уже готовый ScrollMsg. Ну, дальше отловить ScrollMsg на уровне скроллера уже не составило труда.
Но разбирался часа четыре - "без поллитры", как говорится, фиг поймешь!


А смысл? Breakpoint в других средах - это тот же HALT, специальная машинная инструкция, которую отладчик ставит в код в точке останова. И зачем нам делать еще один скрытый HALT?

А вас лично не запаривает:
Тоскую без отладчика...

Здравствуйте, Святослав!

Посмотрел ваш пример - обновление на табе происходит нормально, но только когда таб переведен в Mask Mode. Переключите в свойствах таба All Tabs In Mask Mode - а потом запустите Open As Tool Dialog - Update будет отрабатывать нормально, строчки появляться сразу по наведению мышки. А если открываете со вкладкой, находящейся в режиме разметки, то для этой вкладки и сообщения отрабатывают не сразу.

Аааа!! Идиотто я!
Спасибо большое от тупого чайника!

Я тоже вот захотел, и даже сделал интерактор расширяемой записью (из-за двух пустых методов пришлось). И мой контрол вообще перестал что-либо отображать. Убрал EXTENSIBLE и пустые методы - рисует ОК. И кажется мне, что нельзя делать интерактор типа расширяемой записи (и динамической POINTER TO RECORD тоже лучше не делать, кстати).