Публикуя данную статью преследую одну главную цель – раскрыть для Вас свою идею по организованному ведению собственных свойств объектов Access (контролов, форм и т.д.).

Задачи, решаемые при реализации идеи:

1. Расширение свойств объекта с быстрым к ним обращением.
   Медленная альтернатива – создание таблицы [Тип объекта][Расположение объекта][Наименование объекта][Наименование свойства][Значение свойства].

2. Быстрое и удобное изменение переменных, используемых при отрабатывании событий объекта. Обращение производиться через панель «Окно свойств».
   Обычно приходится открывать код vba и изменять данные. Мы можем использовать альтернативу из п.1 или создавать спец поля на форме, но это часто неудобно.

3. Другие.

Область применения:

1. Универсализация часто используемых объектов (групп объектов).
   Пример1 Вы сделали кнопку [=] (см. Пользовательские свойства.accde), которая приравнивает значение одного поля к другому. Теперь не надо создавать ее повторно на другой форме, копировать код обработчика vba (при копировании vba обработчик не наследуется), не надо подстраивать код обработчика в редакторе vba. Достаточно изменить собственное поле панели «Окно свойств».
   Пример2 Совершенствование функций ведения справочников http://hiprog.com/index.php?option=com_content&task=view&id=251661641&Itemid=35

2. Обработка особых сиуаций
   Пример2 в бухгалтерской очетности в столбце с балансом нужно выделять отрицательные значения цветом шрифта или фона, например. Тогда RGB код цвета для обычно и такой ситуации можно хранить с своем поле, а при вычислении значения поля (обработчик события) копировать в свойство цвета текста или фона значение своего поля.

3. Другие.

Как реализуется:

У всех объектов access есть свойство Tag (Дополнительные сведения). Свойство создано для ведения комментариев, но некоторые его используют в других целях, как и я.

Предлагаю разбить логически (через разделитель) свойство tag на массив элементов, которые будут выступать значениями собственных свойств, например через пробелы, запятые, фразы типа «Свойство1:»

Примечание: последнее решение более наглядно, но потребует доработки кода функции. Т.е. строка Tag= «Свойство1: , 123 , Свойство: , Текст» будет читаться функцией как 4 значения 4 свойств, но программно мы выкидываем нечетные, т.е. названия свойств. Соответсвенно функция чтения свойства GetParametr(2) должна обратиться к 4-му элемент Tag.

Таким образом пример 1 области применения реализуется путем указания через разделитель (в моем accde это пробел) в свойстве объекта Tag названия полей «txt1 txt2». При нажатии на кнопку значение txt2 копируется полю txt1.
Примечание: пример ценности такого примера – копирование значения Поставщика счета Получателю средств по платежу на обстрактной финансовой форме исходящего счета.

А для того, чтобы копировать кнопку на другие формы достаточно реализовать обработчик в виде макроса, выполняющего функцию. Функция – фактический обработчик на vba с применением своих свойств в виде функцию. Теперь кнопка легко копируется с формы «Мои контролы для форм» на другие формы.

Комментарии автора:

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

Спасибо.

© Артем Золотинин [Баймер]

Приложение. Мысли по развитию:

1. Реализовать ведение «Tag= «Свойство1: , 123 , Свойство: , Текст» (см. статью)

2. Реализовать возможность задания используемого разделителя на спец форме для параметров функции.

3. Реализовать код функции, изменяющей заданное свойство.

4. Реализовать таки использование идеи в авторской реализации функции ведения справочников http://hiprog.com/index.php?option=com_content&task=view&id=251661641&Itemid=35.
   с чем я уже успел обратиться к ее автору в комментарии в лице «Baimer”a ;)

Пример реализации.

Коментарии (26)

1  Написал(а) AlexSyr, в 03:48 04.12.2010 На мой взгляд - высказанная идея более чем спорная.  Достоинства: ---  Недостатки:  1. Фактически запрещается работать с Tag\'ом, т.к. будет использоваться в других целях и вероятность ошибок использования этого свойства значительно возрастет.  2. Пропадает возможность пользоваться IntelliSense, вследствии чего значительно возрастут ошибки одинакового начертания символов в разных раскладках клавиатуры (сc, оo, eе,Il1, ...).  3. Код усложняется. Через полгода опять придется разбираться откуда же берутся параметры, правильно ли указаны разделители (попробуйте вместо пробела набрать комбинацию Alt+255 ), ...  И масса чего еще, что как правило с избытком подкидывает практика. А ради чего????  Если уж прямо так хочется (а иногда и требуется) унифицировать код, то есть стандартные способы: паблик функция с передачей в нее необходимых параметров; или свой класс. Думаю, что если бы Вы стукнулись в форум с этой идеей, то Вам бы спецы еще много чего нибудь присоветовали.

2  Написал(а) Баймер, в 17:16 04.12.2010 Спасибо за комментарий.    Некоторые достоинства перечислены в статье. Может "---" как раз это и обозначало.  По недостаткам:  1. Не понял, почему запрещается с ним работать? Tag позволяет ввести огромное кол-во символов (не считал), полностью которые, предполагаю, мало кто использует. Отсюда вывод: то, для чего его использовали, продолжает действовать в качестве одного из параметров.  2. Почитал немного по указанному термину. В коде, согласен, удобная вещь. НО на идею никак не влияет, т.к. это просто разные предметы разговора.  3. Повторюсь - указана лишь идея. Для простых случаев можно обойтись разделителями, для сложных идею можно реализовать лучше (см . мысли по развитию п.1). Для свойства Tag можно выбрать "Масштаб", тогда все отображается крупно и наглядно.   Можно написать функцию, при которой можно будет вводить в Tag параметры с именем, ну и читать по имени. Например для приведенного ПРОСТЕНЬКОГО примера: Source, txt1, Receiver, txt2.  Где для tag не требуется вести доп. параметры, то используем как обычно, а где нужно, то для коммента можно в таком случае сделать параметр Comment и расположить его первым   4. На вопрос: "Ради чего", - каждый должен ответить сам. Кому-то это не нужно - я не против. Кому-то понадобится - только за.     Постараюсь привести в ближайшее время несколько примеров (без реализации), в которых, на мой взгляд, решение будет полезно.    Отстраненно: слышал, что хороший программист решит задачу, если это возможно, используя самые простые средства и как можно меньше обращаясь к написанию своего кода (что-то такое). Так вот, в данном случае к коду обращаться вообще не надо - поменял значение свойства и все, не открывая редактор кода

7  Написал(а) AlexSyr, в 14:30 05.12.2010 Баймер!  > взгляд скорее кодера (программиста)  Для справки. Кодер (кодировщик) - сотрудник, пишущий исключительно код программы на основе предоставленного ТЗ. Его задачей является исключительно качественно/оптимизированно/... написанный код. Это своеобразная каста узкоспециализированных профессионалов.  Технолог - сотрудник, занимающимся вопросами адаптации программ к нуждам пользователей (интерфейса; удобства и качества ввода данных; ...), определяющим необходимость/целесообразность/дальнейшее развитие/... того или иного решения. Его задачей является исключительно грамотно/всееобъемлюще/... составленное ТЗ. К данной категории причисляют себя все кому не лень - ведь управлять государством может даже кухарка. Хотя по сути это должны быть высокообразованные люди, свободно разбирающиеся в направлениях развития процессов автоматизации, маркетинга, психологии (да-да) и многом чего еще.  Программист - сотрудник, выполняющий функции не только кодировщика, но и технолога, пусть немного и менее эффективно, чем делал бы отдельный узконаправленный специалист, но именно это и позволяет получать готовый продукт в разы быстрее и качественнее.  Программист с БОЛЬШОЙ буквы - человек (может и не быть сотрудником ), выполняющий функции не только кодировщика, но и технолога, в идеальном понимании этих двух функций.  Пользователь (ламер/чайник/манагер /...) - сотрудник, который должен бы учиться пользоваться предоставленным ему инструментом (программой), а вместо этого любит все охаивать на предмет непрофессионализма, давать глупые советы как надо а как не надо, ..., при этом, зачастую плохо владеющий элементарной арифметикой (проверено на практике).  Так вот. Если бы я посмотрел на Вашу публикацию взглядом \"кодера\", то я бы и не стал даже ввязываться в полемику (надеюсь понятно почему ). Я же пытался Вам привести аргументы и со стороны кодировщика и со стороны технолога и даже со стороны пользователя (каковыми все и являемся по отношению к Access).  Моей целью не стоит переубедить именно Вас (порой трудно отказываться от вредных привычек и стереотипов), а донести до тех, кто в дальнейшем может наткнуться на данную публикацию - не стоит, ради непонятно чего, так усложнять задачу. Люди!!! Задумайтесь над тем, что написал Дглфы(Lukas) по поводу \"сопровождения\". )  P.S. Личный совет. Для сравнения со своими идеями выбирайте достойные альтернативы (хотя бы стандартные).