вот собственно и весь вопрос. Ранее поднимал его здесь http://www.sql.ru/forum/1111845/kak-programmno-otsledit-izmeneniya-v-konstruktore-form-i-otchetov

Это сделано - неудобно по ряду причин. Хочется чтобы именно в момент когда вызываю конструктор конкретной формы - зафиксировать этот факт в какой-то таблице. А еще более расширенный вопрос - как пребываючи в конструкторе формы программно фиксировать изменения свойств ее элементов?

Вакшуль Сергейgarvy,

перечитал предыдущую ветку, вы пишите:
garvyОстается маленькая деталь - все выше предыдущее обсуждение опускаем вплоть до самого первого вопроса - сформулирую его по другому: Есть ли в объектной модели ACCESS событие, к которому можно прикрутить программу, сохраняющую изменения, внесенные в форму или отчет в режиме конструктора при выходе и/или сохранении в специальную таблицу базы данных?
...
Как я понял, вам нужен факт сохранения макета формы.
А такого события нет.
Есть свойство 16472719 :
Анатолий ( Киев ) CurrentProject.AllForms(i).DateModified возвращает дату последнего изменения макета формы.
И, похоже, это все, что есть из полезного.

Я было подумал, что табличным макросом на обновление записи таблицы MSysObjects можно выкрутится(триггер, что ни на есть), но на системную таблицу такой триггер не навесишь, да и от поля DateUpdate таблицы MSysObjects тоже толку мало. Не смотря на название, сути своей оно больше не отражает.
https://support.microsoft.com/en-us/kb/299554
Additionally, you may have noticed that the Database window (in versions prior to Access 2007) and the Navigation Pane in Access 2007 or Access 2010 displays the correct date and time for an object's last modification. This is because Microsoft Access uses its own internal mechanism for storing the date created and date modified, independent of the database engine. Unfortunately, Microsoft Access does not expose this information in its object model; therefore, there is no programmatic way to get to this information in Microsoft Access.


Я вот чего не пойму. Зачем это нужно делать в режиме онлайн? Ну, сели вы работать над какой-то задачей. Ну потратили полдня. А сколько форм отчетов вы изменили? Ну до десяти, не больше. Сравнение дат CurrentProject.AllForms(i).DateModified даст вам точное число измененных вами форм. Вот и запустите в конце дня для этих форм ту программу, что вы написали. Съем новых данных займет от силы полминуты.
Я потратил немало времени на создание описания всех форм системы и описания элементов управления форм. Хэлп так сказать. Немало - это слабо сказано. Пошел пока что по простому пути - файл word, который пользователь может вызвать прямо из формы. В нем описываются назначение и свойства самой формы и ее элементов. Учитывая что форм несколько сотен и в каждой по несколько десятков элементов управления, процесс описания растянулся почти что на год. Но я же все время добавляю/удаляю, изменяю функциональность форм их элементов управления, да, в день не более десятка думаю. Программа, которая по расписанию или по вызову фиксирует изменение свойств написана, но вот как раз запускать ее надо только для изменившихся форм и только для изменившихся элементов управления. Иначе речь идет не о минутах обновления информации, а о часах в лучшем случае. Я уже писал - если запустить программу, которая шерстит все формы и все элементы управления в форме и все свойства каждого элемента формы - получается дикое время ее выполнения. У меня создана таблица, куда по результатам работы этой программы сброшены все свойства. Всю систему она шерстила 3 суток. В результате таблица с более чем миллионом записей. Хочется в режиме реального времени - изменилось свойство - установил флаг в этой таблице. Зафиксировал изменение в описании системы - флаг снял. Самый распространенный недостаток всех описаний систем - отставание ее описания от ее реального состояния. Мне хочется хотя бы отчасти автоматизировать отслеживание описания изменений. Конечно - word это лишь начало. Самое сладкое было бы если при изменении свойства Z элемента Y в форме X (в момент его сохранения) программа сама находила описание этого элемента в хэлпе и по крайней мере ставила метку о его неактуальности. Хочу вот до такого состояния систему описания системы довести. А с DateModified такая беда, что при сжатии приложения у всех форм устанавливается новая дата! А у меня при выкладке обновления для пользователей каждый раз происходит сжатие. От разработки файл пухнет где-то с 40 до 100 с лишком мегабайт. Я его потом по сети рассылаю в несколько мест, поэтому лучше сжимать.

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

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

зачем бить - я хочу отслеживать вносимые собственноручно мной изменения, дабы поддерживать актуальность описания системы. Описание выстроено от бизнес процессов, с пользовательской точки зрения. Т.е. там нету того, что у кнопки такой то свойство цвета такое-то. Это пользователю и не надо. Но вот что при нажатии этой кнопки будет запущена программа, которая делает то-то и то-то. А потом в какой-то момент я переделываю логику программы, а описание остается старое. А потом добавляю еще кнопку, еще функциональность, а описания на нее вообще нету. А заниматься по принципу - поменял программу - сразу же садись за переписку описания не получается совершенно. А через пол дня я уже не то что логику, я уже и не вспомню что именно и где я изменял. Все это примеры конечно. Если совсем уж предельно просто выражаться хочу: 1) Иметь таблицу хэлпа в базе данных ко всей системе (одно любое свойство, элемент, форма, отчет, модуль - одна строка), где одно из полей и будет тот текст, который видит пользователь в описании. Как я уже писал - такую таблицу я уже завел. 2. От момента выпуска нового релиза до момента выпуска следующего релиза иметь сводку с полным списком измененных с момента прошлого релиза свойств системы. Сейчас чтобы завершить создание и ведение такой таблицы мне не хватает только одного - программно отслеживать факт изменения свойств элементов формы (и свойств самих форм, отчетов) на лету, дабы ввиду множественности этих свойств сразу исключить те, которые не изменялись. Все остальное в том или ином виде уже имеется. Хочется уже свести это в единую стройную систему. Сам текст для пользователя увы, но писаться должен человеком пока что. Я сам ярый противник хэлпов постоенных по принципу Сепулькарии - см. сепульки - сепульки см. сепуление - сепуление см. сепулькарии. Хотя как программист, который честно пытается это делать, должен отметить, что это крайне сложно - быть одновременно Толстым и программистом.