ReScanPanel

Программирование на Атлантисе (VIP, FCOM, ARD), FastReport

Модераторы: m0p3e, edward_K, Модераторы

Juve
Постоянный гость
Сообщения: 60
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва
Контактная информация:

ReScanPanel

Сообщение Juve »

Здравствуйте все!

Есть фейс, в нем куча вьюх. На экран попадают только те таблицы, которые описаны в первой (по счету) вьюхе. (По другому у меня не получается).
Подход следующий: процедура использует одну вьюху для модификации записей в таблице t1, при этом , эта же таблица входит в состав "главной" вьюхи, которая отображает её на экране. Таких таблиц (обновляемых таким образом) у меня много, и все они выводятся в главной вьюхе на экран. Загвоздка в том, что некоторые нормально обновляют данные после модификации, а некоторые нет. Для того чтобы данные , скажем, в browse стали актуальны приходится подергать мышкой за scrollBar. Понятно - все дело в обновлении, но само обновление сделано везде одинаково:

Код: Выделить всё

 _try { VMain.getFirst tpFirstGuiltyDep;} _except on ExDataBase: {}
       reScanPanel(tntpFirstGuiltyDep);
и для некоторых таблиц работает всегда, для некоторых иногда, а для некоторых вообще не работает!!! Это лечится? :-?

P.S. ReReadRecord тоже не всегда спасает, кроме того, его использование нежелательно.
Goblin
Местный житель
Сообщения: 474
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Сибирь-матушка
Контактная информация:

Сообщение Goblin »

RescanPanel(#<Имя таблы для панели>)
Питаю патологические отвращение и ненависть в особо тяжелой и крайне запущенной формах к семейству программ Microsoft Business Solution !
Восславим господа Кришну за то, что у нас есть ГАЛАКТИКА !
Juve
Постоянный гость
Сообщения: 60
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва
Контактная информация:

Сообщение Juve »

Goblin писал(а):RescanPanel(#<Имя таблы для панели>)
полный эквивалент тому что я написал
Трещин
Сообщения: 10
Зарегистрирован: 08 фев 2006, 11:53
Контактная информация:

Сообщение Трещин »

panel pn1;
browse br1;
table tablename;
fields
.
.
.
end;
end;

tablename - ветка выборки, по которой будет перерисовываться
панель
Привет семье! :-)
Juve
Постоянный гость
Сообщения: 60
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва
Контактная информация:

Сообщение Juve »

Трещин, все так и делается.
Да, и по Maverick`у табла описывается не в browse а в panel.
Только вот не работает как надо.
Maverick
Абориген
Сообщения: 943
Зарегистрирован: 29 мар 2005, 17:49
Откуда: External Developer
Контактная информация:

Сообщение Maverick »

Вся фишка в том, что RescanPanel действует только для корневой таблицы панели.
У Вас же вьюха одна а ресканите вы таблу из другой вьюхи.. естественно ничего не будет происходить...
Изображение
Знающий людей разумен.
Знающий себя просветлён.
Побеждающий людей силен.
Побеждающий самого себя могущественнен
Juve
Постоянный гость
Сообщения: 60
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва
Контактная информация:

Сообщение Juve »

Вот в том то и дело: операция "заполнение view1.t1 - reScan view2.t1" происходит на cmInit соответствующего окна.

С некоторыми таблицами (видимо это связано со звездами) все работает. То есть окно появляется с уже корректно отображенными данными в browse. А в некоторых случаях, browse ,видимо, прорисовывается позже чем идет вызов reScan, и в итоге на эране имеем устаревшие данные.

Если я теперь нажму на кнопку, в обработчике которой будет ReScan - все исправится. То есть reScanPanel таблы одной вьюхи, заполненной данными с использованием другой - работает. Дело в очередности возникновения событий. Может мои размышления натолкнут all на нужную мысль? Я бы повесил эту операцию на событие типа onShow, но увы...
coolibin
Постоянный обитатель
Сообщения: 151
Зарегистрирован: 29 мар 2005, 17:49

Re: ReScanPanel

Сообщение coolibin »

Juve писал(а):Здравствуйте все!

Есть фейс, в нем куча вьюх...
Уважаемый Juve, извините за любопытство, а зачем в фейсе делать "много вьюх"? Я пробую себе предстваить ситуацию, когда это бы было полезно, и не могу. За все время общения с Галой я часто видел, как люди сами себе создавали кучу проблем подобными приемами.
Рекомендую - НЕ ДЕЛАЙТЕ В ИНТЕРФЕЙСЕ МНОГО ВЬЮХ. И у вас будет больше времени для полезного общения на этом форуме :)
Juve
Постоянный гость
Сообщения: 60
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва
Контактная информация:

Сообщение Juve »

coolibin,
На одном экране надо отобразить данные из 20 связанных между собой таблиц. Во время просмотра данных в одном броузе, в другом(их) данные тоже меняются. Если предположить, хотя это не возможно (!) в данной ситуации, что мы обходмся одной вьюхой, то все работает настолько медленно, что галка как система становится не нужна.

Выход - создаются временные таблицы в количестве 3-5 штук. И заполняются только необходимыми из бывших 20 данными. Все летает.
coolibin
Постоянный обитатель
Сообщения: 151
Зарегистрирован: 29 мар 2005, 17:49

Сообщение coolibin »

Juve, вы мыслите в правильном направлении - временные таблицы действительно могут помочь с быстродействием. А особенно еще с такими фичами, как автопоиск в поле (он работает только по полям корневой таблицы)
НО. Причем здесь МНОГО ВЬЮХ. Кто мешает поместить временные таблицы в ту же вьюху? Вам нужно серьезно позаниматься с логическими таблицами в Галактике. Судя по всему вы уже делаете достаточно сложные интерфейсы, но не до конца понимаете принцип построения галактических логических таблиц.
Логическая таблица интерфейса (вьюха) в атлантисе может быть многокорневая, необязательно разные подзапросы раскидывать по разным вьюхам.

И еще:
_try { VMain.getFirst tpFirstGuiltyDep;} _except on ExDataBase: {}
reScanPanel(tntpFirstGuiltyDep);
зачем сразу так уж радикально?

if( VMain.getFirst tpFirstGuiltyDep <> tsOk)
reScanPanel(tntpFirstGuiltyDep);

я надеюсь что сама getfirst уже делает все нужные проверки.
Juve
Постоянный гость
Сообщения: 60
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва
Контактная информация:

Сообщение Juve »

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

По поводу
if( VMain.getFirst tpFirstGuiltyDep <> tsOk)
reScanPanel(tntpFirstGuiltyDep);
я надеюсь что сама getfirst уже делает все нужные проверки.
вариант хороший, но в том то и дело что не всегда. Опытным путем выяснил, что максимальная надежность обновления достигается только в этой паре :) Использовать reScan без getFirst тоже смысла нет - система еще не перечитала данные в dataSet`е.

В любом случае, спасибо что тратите на меня время
coolibin
Постоянный обитатель
Сообщения: 151
Зарегистрирован: 29 мар 2005, 17:49

Сообщение coolibin »

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

Во-вторых - есть переключаемые подцепки. Можно таблицу переподцепить,сделать что нужно и вернуть обратно (PushBounds/PopBounds)

В третьих, если при модификации использовать where(()) с указанием ограничений на таблицу, то подцепки, заданные во вьюхе отдыхают в это время. Если таким способом обновляется одна запись, то подцепить ее по нреку
update t1 where ((123==nrec)) set трали-вали...
в момент апдейта никакие другие подцепки на таблицу не действуют


По поводу
if( VMain.getFirst tpFirstGuiltyDep <> tsOk)
reScanPanel(tntpFirstGuiltyDep);
я надеюсь что сама getfirst уже делает все нужные проверки.
вариант хороший, но в том то и дело что не всегда. Опытным путем выяснил, что максимальная надежность обновления достигается только в этой паре :) Использовать reScan без getFirst тоже смысла нет - система еще не перечитала данные в dataSet`е.
[/quote]

RereadRecord - перечитает весь броуз из источника плюс обновит все подчиненные панели (хотя я давно мануалы не читал, могу и приврать малость). Но у меня с getfirst и rescan траблов никогда не встречалось никаких.
Juve
Постоянный гость
Сообщения: 60
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва
Контактная информация:

Сообщение Juve »

Во-первых, в одной вьюхе можно открывать любое количество экземпляров...
согласен. Может я чего-то не так делал, но у меня файсы написанные таким образом работали медленно и глючили.
Во-вторых - есть переключаемые подцепки...(PushBounds/PopBounds)

этим активно пользовался но капитально замучался. Надо не забывать их включать/выключать (ситуций море) и у меня с этим вечные проблемы. :???:

А вот "про третьих" очень кстати, - попробую!
поЧитатель
Посетитель
Сообщения: 44
Зарегистрирован: 27 янв 2006, 14:21

Сообщение поЧитатель »

Я однажды делал такой вариант
В событии открытия фейса можешь написать:
cmInit:{
RunInterFace( 'Add2Tmp');
}
и создать новый интерфейс Add2Tmp, в котором нет фильтров. Он удалит содержимое времменных файлов, добавит или модифицирует нужные записи и закроет сам себя.
Кстати, Я заметил, что когда в фейсе пишешь
cmInit:{
Insert Pick where ((... )) set wList := ....;

Abort;
Exit;
}
то он конечно же не показывается на экране, но он не передает выходные параметры, а только получает их.
все-таки был вынужден писать так:
Parameters cOut;
cmInit:{
Insert Pick where ((... )) set wList := ....;
cOut := ...;
CloseInterface(cmDefault);
}
Он мелькнет на экране, зато Переменные не нулевые.

Но в любом случае придерживаюсь правила:
1 интерфейс= 1 вьюха, так спокойнее спится по ночам.

to coolibin
после
update t1 where ((123==nrec)) set трали-вали...
На каком месте останется текущщий курсор
:-? :-? ?
А если комманду Delete надо запустить не корневой таблицы?
А проверку как запустить, есть Такая запись или нет?
Все-таки фильтр во вьюхе - он и в африке фильтр.
Juve
Постоянный гость
Сообщения: 60
Зарегистрирован: 29 мар 2005, 17:49
Откуда: Москва
Контактная информация:

Сообщение Juve »

На каком месте останется текущщий курсор
?
А если комманду Delete надо запустить не корневой таблицы?
А проверку как запустить, есть Такая запись или нет?
Все-таки фильтр во вьюхе - он и в африке фильтр.
Вот и я поглядел на это...и решил оставить в сторонке :shock:
Ответить