5 строк кода

Как писать комерческие приложения на MS Access

Archive for the ‘архитектура’ Category

Недостатки DoCmd.GoToRecord и достоинства CodeContextObject

10 комментариев

Пара камней в огород DoCmd
Как-то мне понадобилось перейти к последней записи в подчиненной форме. Перейти к последней записи можно разными способами, простейший – это вот эта команда: DoCmd.GoToRecord , , acLast. Вот с подчиненненными формами есть нюанс – нужно вызывать ее в обработчике события или методе подчиненной формы. В моем случае события не подходили, метод было реализовывать влом и очень хотелось реализовать это на главной форме.

Поэтому пришлось написать свою функцию. Благодаря тому, что функция принимает ссылку на форму, а не имя, то можно ее использовать для любой формы, подчиненной, созданной при помощи DoCmd.OpenForm или оператора New.

Public Sub CM_FormGoToLastRecord(Optional ByRef frm As Form = Nothing)
' перейти на последнюю запись
' frm можно не передавать, в этом случае она будет получена при помощи CodeContextObject
On Error GoTo Err_

    If frm Is Nothing Then
        Set frm = CodeContextObject
    End If

    If frm Is Nothing Then Exit Sub

    Dim rst As DAO.Recordset

    Set rst = frm.RecordsetClone
    If Not rst.EOF Then rst.MoveLast
    frm.Bookmark = rst.Bookmark

Exit_:
    Exit Sub
Err_:
    mc_Log.MC_LogErr ("CM_FormGoToLastRecord()")
    Resume Exit_:
End Sub

mc_Log.MC_LogErr ("FormGoToLastRecord()") - фукнция, которая логирует ошибку в текстовом файле. О ведении лога я как-нибудь расскажу попозже.

CodeContextObject
В процедуре CM_FormGoToLastRecord() используется такая штука, как CodeContextObject, которое в справке называют свойством. Это свойство позволяет получить ссылку на объект, в рамках которого выполняется данный код. Если вызвать процедуру CM_FormGoToLastRecord() в событии подчиненной формы, то CodeContextObject выдаст ссылку на подчиненную форму. Этот же способ использует DoCmd.GoToRecord, когда не указывается имя объекта.

До встречи!

(с) Скоков Сергей

Подписаться на: RSS или e-mail рассылку или добавить в ЖЖ друзья.

Written by Сергей Скоков

Май 27th, 2009 at 3:35 пп

Стоит ли использовать временные таблицы для отчетов

Один комментарий

Здравствуйте, уважаемые читатели.

Отчет

Сегодня прочитал спорное мнение на форуме, что использовать временные таблицы при формировании отчетов это кривое решение. С этим мнением я в корне не согласен.

Мои доводы ЗА:
1. Модульность. Временные таблицы позволяют разделить между собой отчет и код расчета данных. В последующем это повышает сопровождаемость (см. п.3).

2. Удобство отладки. Если отчет перестал работать или работает как-то не правильно, то гораздо легче проверить расчет данных для него.

3. Сопровождаемость. В любой момент может возникнуть необходимость переделать либо расчет данных, либо переделать отчет, например, печатать его в word. Это все можно модифицировать по отдельности. Также пользователь может захотеть хранить рассчитанные данные, этого тоже будет просто добиться.

4. Документирование. Если разработчик укажет комментарии к полям для временной таблицы, то это можно считать документацией.

Мои доводы ПРОТИВ:
1. Увеличивается время разработки. Это происходит в том случае, если для отчета можно использовать простой запрос в качестве источника данных. Если же расчет данных не вписывается в простейшие запросы, то будет проще и надежней реализовать расчет отчета в коде.

Больше против я не вспомнил. Выбор очевиден :-) . Увлекаться данным способом естественно не стоит, каждой проблеме лучше подбирать свое решение. Этот метод подходит для отчетов со “сложными” расчетами данных.

До встречи!

(с) Скоков Сергей

Подписаться на: RSS или e-mail рассылку или добавить в ЖЖ друзья.

Written by Сергей Скоков

Март 22nd, 2009 at 5:14 пп

3 вида меню в MS Access

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

Здравствуйте, уважаемые читатели.

5codelines.net

То, что первым видит пользователь в программе – это меню. От него зависит (и не только) на сколько удобно будет работать с программой. С течением времени определенные подходы, которые я видел, классифицировались в следующие виды меню:
- формы с кнопками,
- кнопочная форма (на основе мастера),
- строка меню.

Я заметил, что «новички» начинают с форм с кнопками, затем открывают для себя кнопочные формы, а если встает задача сделать, как классическом текстовом редакторе, то переходят к строке меню или используют вместо нее панель инструментов. Конечно, бывают исключения и это только мои наблюдения.

Очень долгое время я думал, что самое лучшее и удобное меню – это строка меню. Но как показала жизнь, для каждого класса задач подходит свое меню.

1 Формы с кнопками
При этом подходе создается множество однотипных форм с кнопками или группой переключателей. Этот метод очень активно использовался в старых ДОСовских программах.

Это очень удобно использовать, когда пользователю при работе с одной из функций не нужна другая функция, которая вызывается из меню. Примером таких программ могут служить любые, в которых происходит потоковая регистрация и пользователю некогда переключаться между клавиатурой и мышкой.

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

Очень не рекомендую использовать группы переключателей в качестве кнопок, переходить клавишами по такому меню не удастся.

2 Кнопочная форма (на основе мастера)
В этом варианте существует только одна форма и мастер редактирования пунктов. Из недостатков – при открытии любая формы, форма меню будет не видна.

При ближайшем рассмотрении оказалось, что это обыкновенная форма с х кнопками и надписями и с системной таблицей в качестве источника данных.

Не знаю почему, но мне этот вариант мне не нравится. Я лучше сам его реализую при необходимости.

3 Строка меню
Это мой самый любимый способ, т.к. очень просто изменять и все время на виду. Да и очень редко мне доводится разрабатывать программы для людей, не пользующихся мышкой.

Чтобы меню выглядело при запуске программы как на картинке, придется немножко пошаманить.

При создании меню (Сервис->Настройка), по умолчанию создается панель инструментов. По этому, выбрав созданное меню, необходимо нажать кнопку свойства. Необходимо настроить его следующим образом:

Я изменил тип на «Строка меню» и убрал галочку «Отображение и скрытие», чтобы пользователь ее не мог скрыть. Снимать все галочки не рекомендую, если будет желание то после этого обязательно проверьте, что из этого получилось и подойдет ли пользователю. А то можете получить проблему из-за меню. Также можно убрать перемещение, но только после того, как закончите сами ее настраивать.

Теперь необходимо зайти в Параметры запуска (Сервис –> Параметры запуска).

Тут я выбираю свою строку меню и убираю отображение окна базы данных. В таком режиме я и работаю.

Как вы заметили можно и свое контекстное меню сделать. Или убрать панели инструментов по умолчанию. Не рекомендую этим увлекаться. Например, панель инструментов отчетов ой как нужна, чтобы напечатать. А на панели инструментов для форм есть такая полезная штуковина как сортировка.

После того, как вы перезапустите свою БД, то всегда будет отображаться ваше меню. А стандартного не будет. Чтобы его отобразить/скрыть достаточно нажать Ctrl+F11. Очень удобно.

До встречи!

(с) Скоков Сергей

Written by Сергей Скоков

Март 12th, 2009 at 1:41 пп

События

Один комментарий

Здравствуйте, уважаемые читатели.

Поговорим в этом выпуске об очень интересной штуке – события. Я очень мало где видел их использование в MS Access. Но они очень сильно облегчают жизнь при работе, особенно с формами. У событий есть маленькое ограничение. Их могут использовать только объекты. Это означает, что их можно объявлять и получать только в модулях пользовательских классов, формах и отчетах.

Чтобы объявить событие необходимо в начале модуля класса (формы, отчета или пользовательского) написать:
Event ИмяСобытия( СписокАргументов )

Для использовании события необходимо объявить в начале модуля ссылку на объект и в списке (левый список, который расположен в редакторе кода) выбрать обявленный атрибут, в правом списке можно выбрать событие, если их несколько. В результате получим следующее:
Dim WithEvents Имя As Тип

Вызвать событие можно так:
RaiseEvent ИмяСобытия( Параметры )

Где это можно применить? Рассмотрим пример из жизни. На форме заказа есть поле клиента. В этом поле отображается, допустим, УНН и название клиента. Рядом с полем кнопка. По нажатию на кнопке отображается еще одна форма – список клиентов. Задача – выбрать клиента.

Одним из решений будет открыть модальное окно и тут возникает куча разных вариантов: записать напрямую с формы списка клиентов в поле формы заказов (очень плохая идея!!!), скрыть форму при нажатии пользователем кнопки “Ок” (Выбрать) и т.д.

При помощи событий получается простое и элегантное решение. Всего-то объявить на форме списка клиентов событие:
Event OnClientSelect(ByVal lId As Long)

На форме заказа это событие обработать:

Dim WithEvents m_frmKlientSepis As Form_frmKlientSpis
'--

Private Sub Kn_KlientSelect_Click()
	'-- выбор клиента
	'-- можно и так
	'-- DoCmd.OpenForm "frmKlientSpis"
	'-- Set m_frmKlientSepis = Forms("frmKlientSpis")

	'-- но мне нравится этот вариант
	Set m_frmKlientSepis = New Form_frmKlientSpis
	m_frmKlientSepis.Visible = True
End Sub

Private Sub m_frmKlientSepis_OnClientSelect(ByVal lK_KLIENT As Long)
	'-- клиент выбран пользователем
	Me.K_KLIENT = lK_KLIENT
	Set m_frmKlientSepis = Nothing '-- уничтожаем форму
End Sub

Подробности можете увидеть в примере. Чуть позже я расмотрю еще один пример – связные списки.

До скорых встреч!

(с) Скоков Сергей

Written by Сергей Скоков

Октябрь 5th, 2008 at 7:09 пп

Повышение сопровождаемости. Часть 1. Формы.

4 комментария

Здравствуйте, уважаемые подписчики.

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

MS Access представляет из себя конструктор со встроенным языком программирования. Формы, отчеты, запросы и пр. никакого отношения к языку не имеют. Можно сказать, что они представляют из себя хранимые настройки классов Form, Report, QureyDef и п.р. При создании формы не обязательно создается модуль класса (далее класс), только если указать в свойстве «наличие модуля» да или создать обработчик события. В этом случае имя класса будет Form_<имя формы>. Это истинно и для отчетов.

К объектам MS Access (формы, отчеты, запросы, таблицы) обращаются по текстовому имени. В результате компилятор не проверяет правильность написания текстовых констант. В процессе жизни проект может пережить много модификаций: добавлений, удалений, переименований. После подобных изменений идет страшная череда тестирований и исправлений ошибок. Один из способов повышения сопровождаемости – это писать «компилируемый код». Да, смешно звучит. Т.е. переносить проверку кода с этапа выполнения на этап компиляции. Сейчас все поясню. Все что будет сказано про форму, в той или иной степени относится к отчетам.
Read the rest of this entry »

Written by Сергей Скоков

Июль 14th, 2008 at 12:45 дп