Лично для меня чтобы полностью отказаться от форм списков в 1С стоит только одна проблема, обновление данных в режиме коллективной работы пользователей.
По началу были и другие проблемы (например редактирование элементов в немодальном режиме), но все они были решены с более или менее красивым дизайном и не "тяжелым" по времени и нагруженности режиме. данные через прямой запрос, оперирование данными через ИТЗ и в принципе все бы ничего.
Но режим автообновление....

Вот кто как решает данный вопрос, если вообще пользуется подменой форм списков на ТП...

Пока я решил таким образом, просто в панель управления ТП добавил кнопку "Обновить"... (!!!) но пользователи не всегда ею пользуются, и хотят "он-лайн".

Была идея... в какой то таблице если я не ошибаюсь 1С хранит инфу о том что "что-то в данных изменилось"... однако сам журнал регистрации событий для меня полная тайна покрытая мраком... и нужен ли он мне?

В общем ищу путь копания и реализации... для меня это последняя проблема на пути отказа от 1С-овских списков.

berezdetsky писал(а) 03. Июля 2008 :: 10:41:


Во точно так и есть, вспомнил... именно так... но зачем мне обновлять все списки? Ведь изменится мог вообще документ который даже не отображен... есть мелкие нюансы что тот же док мог двинуть периодику и что-то поменять в справочнике который счас отображен... вот от них то никак не избавится.
Я просто к чему клоню... у меня счас справочник контрагенты - это практически полбазы данных по связанным данным, там на отдельных закладках поставщики подчиненных справочников, других справочников ч/з отборы, документов по фильтру... по сути всей работой поставщика можно рулить напрямую из его карточки. Не спрашивайте зачем... так хотелось и сделалось... работает вроде 3*тьфу хорошо... но обновлять все данные из-за движения не связанного с контрагентами нет смысла.

Но полбеды уже решено, мы проверили таблицу, поняли что что-то изменилось... куда копнуть чтобы относительно быстро вычислить что конкретно произошло? 

Вот собственно теперь ситуация слегка проясняется.

Теперь вот собственно продолжение.
Счас прогнал прямым запросом журнал, Верстамп перевел в число понял что он идет на увеличение в случае изменений. Причем как минимум на +2.
Счас надо добавить туда обработчик прочтения изменений в файле _1СЮзвери... пошел смотреть.
А вообще эта тема кому-нибудь кроме меня и тов. berezdetsky интересна? 

vandalsvq писал(а) 03. Июля 2008 :: 11:51:

А ты попробуй в разделенном режиме посмотреть. В монопольном 1С-ка как-то по-другому мониторит изменения

vandalsvq писал(а) 08. Июля 2008 :: 08:54:

Это я к тому, что счетчик в 1SUSERS увеличивается только в разделенном режиме. 1С-ка, по всей видимости, раз в период опроса изменений смотрит и обновляет списки. В монопольном режиме проверка необходимости обновления списков делается как-то по-другому

Неее... Chieftain это я понял и попробовал... но тут другая "задача" возникает.

Дело в том что работать "аля 1С" я считаю нецелесообразным... т.е. проверять на наличие изменений, потом обновлять все подряд что открыто...
Смысла нет делать обновление тех объектов которые не изменились, а следовательно хорошо было бы получить информацию "кто изменился" (информация нынче дорого стоит)
Насколько я знаю ЖурналРегистрации (а я его нихрена не знаю) инфу он хранит не в таблице базы данных 1С а каким то своим способом.
Допустим я запомню время последнего просмотра, и значение последнего просмотра (пусть даже каждый полсекунды проверять буду), получив изменение значения я получу временной промежуток в который они произошли, вот как мне получить ВИД объекта который изменился, чтобы проверить имеет ли смысл его обновлять в рамках работающего поставщика?

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

А почему бы
1. Всем ТП установить ТаймаутОбновления
2. Все активные ТП запоминать в глобальном списке, при записи/перепроведении документов/справочников/и тп проходить по списку, делать ОбновитьСтроки
Или иметь несколько списков - например, тпДокПН, тпДокРН.
ТП которое хочет обновлятся например при изменении ДокПН регистрируется в списке тпДокПН
ТП которое хочет обновлятся например при изменении ДокРН регистрируется в списке тпДокРН
ТП которое хочет обновлятся при изменении ДокПН и ДокРН регистрируется в обоих списках.
ДокПН при записи/проведении обновляет все ТП, лежащие в списке тпДокПН
ДокРН при записи/проведении обновляет все ТП, лежащие в списке тпДокРН

Изменения, внесенные этим юзером - будут отображаться сразу, внесенные другими - по таймауту.

Муторно конечно, всю конфу шерстить. Зато уж точно будешь знать, когда надо ТП обновить.

orefkov писал(а) 10. Июля 2008 :: 06:34:

Тогда уж лучше в справочник записывать варианты ТП, в доках ставить флаг изменения и при обновлении по нужному элементу смотреть, тогда в многопользовательском режиме тоже работать будет.
Но это все при возможности ковырять конфу.
Если конфу не трогать - то вариант с VERSTAMP вполне приемлим