5 строк кода

Пара камней в огород 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 рассылку или добавить в ЖЖ друзья.

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

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

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

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

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

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

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

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

До встречи!

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

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