Rambler's Top100
Российский фонд помощи
Навигация
Главная
MS ACCESS
VB
ASP
PHP
Наши друзья
Поиск
Форум
Лента новостей
Новый сайт

Online
Рассылки Subscribe.Ru
Работа с MS Access
Подписаться письмом
Реклама на сайте
 
Главная arrow MS ACCESS arrow Использование дополнительных свойств объектов
Использование дополнительных свойств объектов Печать E-mail
Автор Артем Золотинин [Баймер]   
03.12.2010 г.
Оглавление
Использование дополнительных свойств объектов
Страница 2
Страница 3

Публикуя данную статью преследую одну главную цель – раскрыть для Вас свою идею по организованному ведению собственных свойств объектов 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.
    с чем я уже успел обратиться к ее автору в комментарии в лице «Baimera ;)


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

 


Просмотров: 9636

  Коментарии (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. На вопрос: "Ради чего", - каждый должен ответить сам. Кому-то это не нужно - я не против. Кому-то понадобится - только за.  
 
Постараюсь привести в ближайшее время несколько примеров (без реализации), в которых, на мой взгляд, решение будет полезно. 
 
Отстраненно: слышал, что хороший программист решит задачу, если это возможно, используя самые простые средства и как можно меньше обращаясь к написанию своего кода (что-то такое). Так вот, в данном случае к коду обращаться вообще не надо - поменял значение свойства и все, не открывая редактор кода ;)
 3 Написал(а) AlexSyr, в 23:50 04.12.2010
Прочерк в графе "Достоинства" означает, что таковых, на мой взгляд, не обнаружено. По крайней мере по отношению к перечисленным стандартным способам решения. 
К примеру. Какой выигрыш получается у Вас по отношению к стандартному вызову паблик процедуры с передачей в нее необходимых параметров? Да никакого. Т.е. вместо того, чтобы напрямую передать в процедуру необходимые параметры, зачем то используется свойство Tag. Лишний посредник. А какой при этом выигрыш? Может пропала процедура? Нет. Быстрее начало работать? Ясно, что нет. Уменьшилось количество ошибок? Опять же нет, т.к. их теперь можно совершать и в написании передаваемых параметров и в синтаксисе. Сами попробуйте (и проверьте на ком нибудь еще) - при выборе "Масштаб" даже при громадном шрифте сможете отличить два пробела от одного (а результат при этом будет ой какой разный). Может быть стало легче управлять (модифицировать) кодом? А с чего это? Ведь кроме процедуры, выполняющей основную функцию, нужно еще следить за корректным разбором строки по передаваемым в процедуру параметрам. 
Теперь по "Недостаткам": 
1. Сколько Tag позволяет ввести считать не надо - достаточно посмотреть в Help'е - 2048 символов. 
Почему запрещается? А потому, что если будет потребность это свойство использовать, то придется писать еще один разборщик строки по параметрам (нужно же как-то отделить мух от котлет), т.е. если нужно изменить что-то в одном разборщике, то не забыть изменить и в другом, или писать совместный, что является прямым отходом от универсальности. Т.е. вроде как используй это свойство (Де-юре), но лучше не надо (Де-факто)!!! 
2. Если идея приводит к необходимости отказа от удобного инструмента, позволяющего уменьшить количество ошибок, а вследствие этого ускорить выход конечного продукта, то это дискредитирует идею. 
3. Впрочем, думаю, что достаточно уже приведенных аргументов. 
Так в чем же заключается Ваша идея? Введя посредника в виде свойства Tag отказаться от программирования в VBA? Это к слову о "...не открывая редактор кода...". Улыбнуло!!! Так это больше похоже на параметрическую настройку уже готовой и отлаженной программы. А это уже другая идея.
 4 Написал(а) Баймер, в 01:22 05.12.2010
Причиной текущих разногласий являются как минимум 2 момента: 1) я смотрю разрабочиком, разработчиком выходящим за рамки устаканившихся принципов, а Ваш взгляд скорее кодера(программиста), корректно реализующего код. Отсюда недопонимание с Вашей стороны. 
>Какой выигрыш получается у Вас по отношению к стандартному вызову паблик процедуры с передачей в нее необходимых параметров? 
- А что Вы понимаете под параметрами? А какая проверка параметров в функции без обращения к редактору кода (например сразу указывать в строке обработчика события)? 
Попробуйте посмотреть на этот вопрос шире. Я ведь даже не отрицал паблик функции, более того она необходима. 
> при выборе "Масштаб" даже при громадном шрифте сможете отличить два пробела от одного 
-А кто говорит о пробеле? Можно сделать любой символ, более того, о чем указывал в комментне 2, можно сделать намного более интеллектуальное решение. 
>Почему запрещается? А потому, что если будет потребность это свойство использовать, то придется писать еще один разборщик строки по параметрам  
- С чего вдруг?  
Придется, видимо подробнее пояснить. 
Создается набор паблик фукнций, работающий с доп. свойствами (свойствами и(или) параметрами, если копать глубже). Остальные функции, обработчики и т.д., которые были, остаются. Вот только параметры они получают через эти паблик функции. Теперь не нужно открывать код и править там значение - все рядом, под рукой. Я не сомневаюсь, что натасканный человек не сможет сделать это очень быстро, но это не определяет скорость. 
Так почему теперь вдруг придется отказаться от tag? Куда он денется?  
>Если идея приводит к необходимости отказа от удобного инструмента, позволяющего уменьшить количество ошибок, а вследствие этого ускорить выход конечного продукта, то это дискредитирует идею.  
- А чем инструкмент удобнее? Тем что он привычен? Тут я не согласен. Я боюсь даже оценивать удобство, так как все зависит от ситуации. 
А где Вы предлагаете хранить свойства объектов, которых нет в системе? В функциях? Если мне нужно посмотреть, что лежит в коробке - я просто смотрю в нее, а не расспрашиваю других. Если мне нужно поменять содержимое коробки - я меняю, а не ищу того, кто это сделает. 
Некоторые свойства принадлежат сугубо объекту и удобно хранить их непосредсвенно в нем. Вы же не храните ширину поля, цвет шрифта в функции, затем применяя при загрузке - это неудобно. 
В общем, нужно таки привести пару примеров. Не смотря на то, что конкретика портит философию, иногда к ней приходится обращаться. Но это позже. 
>Это к слову о "...не открывая редактор кода...". Улыбнуло!!! 
Много желающих забивать машинный код? А использовать ассемблер? Думаю сказать "нет навсегда" макросам тоже будет глупо. 
 
AlexSyr, попробуйте все-таки выйти за рамки, из которых Вы пуляете критикой из одних недостатков. В статье раскрыта идея, но не ее полная реализация. Пример сугубо показательный, и я изначально признавал его примитивность. Реализаций может быть много.
 5 Написал(а) Баймер, в 01:29 05.12.2010
ПС 
а) Не указал 2 момент в первом обзаце. Так вот, я не программист. Отсюда свежий взгляд. 
б) Чтоб опять не возникла путаница. Говоря в одном из абзацев о паблик функциях, работающих с доп свойствами, я говорю о реализации функции НЕ работающих с доп. свойствами, а управляющих ими. Т.е. чтение свойства, изменение свойства и пр. 
 
Не хватает еще нескольких аппонентов... В разносторонней беседе идея раскроется быстрее.
 6 Написал(а) Дглфы, в 07:46 05.12.2010
Почитал, посмотрел. 
Ужас. 
Вместо абсолютно понятной единственной строчки в обработчике события кнопки веер из макроса и внешних функций весьма сомнительного содержания. 
Не дай боже кому достанется такое \"творчество\" в сопровождение. 
 
Баймер, вам бы Гетца почитать, для начала, (у него есть знатный класс для работы с тегом),  
затем что-нибудь про инкапсуляцию и ООП. 
Па доброму.
 7 Написал(а) AlexSyr, в 14:30 05.12.2010
Баймер! 
> взгляд скорее кодера (программиста) 
Для справки. Кодер (кодировщик) - сотрудник, пишущий исключительно код программы на основе предоставленного ТЗ. Его задачей является исключительно качественно/оптимизированно/... написанный код. Это своеобразная каста узкоспециализированных профессионалов. 
Технолог - сотрудник, занимающимся вопросами адаптации программ к нуждам пользователей (интерфейса; удобства и качества ввода данных; ...), определяющим необходимость/целесообразность/дальнейшее развитие/... того или иного решения. Его задачей является исключительно грамотно/всееобъемлюще/... составленное ТЗ. К данной категории причисляют себя все кому не лень - ведь управлять государством может даже кухарка. Хотя по сути это должны быть высокообразованные люди, свободно разбирающиеся в направлениях развития процессов автоматизации, маркетинга, психологии (да-да) и многом чего еще. 
Программист - сотрудник, выполняющий функции не только кодировщика, но и технолога, пусть немного и менее эффективно, чем делал бы отдельный узконаправленный специалист, но именно это и позволяет получать готовый продукт в разы быстрее и качественнее. 
Программист с БОЛЬШОЙ буквы - человек (может и не быть сотрудником :)), выполняющий функции не только кодировщика, но и технолога, в идеальном понимании этих двух функций. 
Пользователь (ламер/чайник/манагер :)/...) - сотрудник, который должен бы учиться пользоваться предоставленным ему инструментом (программой), а вместо этого любит все охаивать на предмет непрофессионализма, давать глупые советы как надо а как не надо, ..., при этом, зачастую плохо владеющий элементарной арифметикой (проверено на практике). 
Так вот. Если бы я посмотрел на Вашу публикацию взглядом \"кодера\", то я бы и не стал даже ввязываться в полемику (надеюсь понятно почему :)). Я же пытался Вам привести аргументы и со стороны кодировщика и со стороны технолога и даже со стороны пользователя (каковыми все и являемся по отношению к Access). 
Моей целью не стоит переубедить именно Вас (порой трудно отказываться от вредных привычек и стереотипов), а донести до тех, кто в дальнейшем может наткнуться на данную публикацию - не стоит, ради непонятно чего, так усложнять задачу. Люди!!! Задумайтесь над тем, что написал Дглфы(Lukas) по поводу \"сопровождения\". :)
P.S. Личный совет. Для сравнения со своими идеями выбирайте достойные альтернативы (хотя бы стандартные).
 8 Написал(а) Баймер, в 15:58 05.12.2010
Комментарий Дглфы пропускаю, так как он не имеет отношения к данной теме. Вы не читали, а смотрели. 
 
AlexSyr дает наиболее аргументированные ответы. Одно НО - Вы таки не понимаете где и как можно применить идею, неверно понимаете ее цель.  
Я, не являясь спецом в области программирования,но могу и соглашаюсь с Вашими опытными высказываниями. Я не соглашаюсь с Вашей попыткой свои высказывания противопоставлять предложенной идее, т.к. пока нечего было сравнивать и получать противопоставления. 
 
Пока я не привел примеры, видимо Ваше направление в этом вопросе будет непоколебимо.  
 
Все, что пока могу предложить, так это обратить к Вам вопрос. А для чего Вы используете св-во Tag? Ответ "просто для поменток типа комментов" прошу опустить.
 9 Написал(а) Баймер, в 22:44 05.12.2010
Пример 1. 
 
http://am.rusimport.ru/MsAccess/f2.aspx?id=5435 
 
Некий Андрей столкнулся с ситуацией, которую с легкостью можно разрешить путем использования описанной идеи. В то время, как АлексейЕ предлагает создать строку прямо в коде обработчика события, я предлагаю использовать для этого свойство Tag.
 10 Написал(а) Баймер, в 22:48 05.12.2010
http://am.rusimport.ru/MSAccess/topic.aspx?ID=94 
 
IgorM описал возможный вариант ведения в строке именованвых свойств(параметров) и чтения их. Можно, конечно еще доработать, а так же добавить функцию изменения свойства(парамтера) - необходимо, когда свойство меняется кодом, что может потребоваться.


 
Реклама на сайте
HiProg.com - Технологии программирования
Rambler's Top100 TopList