Почему я должен был вручную установить .value из .text при потере фокуса в несвязанном текстовом поле

Question

У меня есть несвязанное текстовое поле, чтобы принять удаление старше: количество дней. Это в заголовке отчета. Я установил его на 30 дней, но я хочу, чтобы пользователь мог его изменить. Я колотил головой, пытаясь понять, почему ввод 40 не был принят, и каждый раз он возвращался к 30. Я наконец решил использовать событие lost_focus, чтобы установить .value в .text. Это сработало.

Дальнейшие исследования показали, что когда текст и значение get текстового поля совпадают, в моем случае это 30. Изменение числа в текстовом поле на 40 показывает значения текста в 40 и значения в 30. Если я специально не установил Value в значение text, Access изменит текст в значение value. Это поведение отличается от других мест в Access, таких как формы.

Может кто-нибудь сказать мне, почему это может быть? Я не могу найти настройки, которые могли бы сделать это. Это потому, что в заголовке отчета? В чем разница между этим и каждым другим текстовым полем, которое я когда-либо использовал?

Answer 1

Лучше всего создать форму с несвязанными полями со списком и отобразить данные в подотчете. Мне нравится разрабатывать свои отчеты так, чтобы при обновлении значений генерировался запрос для источника записей отчета, для этого требуется 2 запроса, один со всеми возможными данными и отфильтрованный как источник записей подотчета. Это будет контролировать данные для печати, а также позволит пользователям закрывать или отклоняться от отчета и позже возвращаться к данным.

Private Sub ComboBox1_AfterUpdate()
Dim Query1 as Object
Dim Temp_Name as Variant
Temp_Name = SubReport.SourceObject
SubReport.SourceObject = Empty
Set Query1 = Me.Form.Application.DBEngine.Workspaces(0).Databases(0).QueryDefs ("SubReport_Query")
Query1.SQL = "Select * Unfiltered_Query WHERE Field1 <= " ComboBox1 & ";"
SubReport.SourceObject = Temp_Name
End Sub

Answer 2

С точки зрения «передового опыта» отчеты о доступе не предназначены для интерактивного использования, несмотря на возможность манипулирования некоторыми несвязанными элементами управления. Хотя могут быть реализованы обходные пути, которые функционируют достаточно хорошо, такие решения часто бывают неполными и содержат ошибки и функционируют по-разному в зависимости от активного представления: представление отчета или предварительный просмотр. Подходящие шаблоны проектирования включают использование форм доступа для указания параметров отчета, которые затем открывают отчет в статической конфигурации .

Это может не удовлетворить вопрос "Почему?" если вы ищете более глубокий ответ о том, почему Microsoft реализовала непоследовательное связывание в Access или почему они вообще допускают интерактивные элементы управления в отчетах, если они ведут себя не так, как в формах. Но у Access есть множество других причудливых поведений, которые не имеют известных / опубликованных объяснений.

Относительно приоритета свойства Value, обновляющего свойство Text (а не наоборот): Значение является ключевым полем, поскольку оно содержит фактические данные для элемента управления (связанный или несвязанный). Хотя естественно иметь один элемент управления как для отображения, так и для ввода (эээ, так работают почти все элементы управления), процессы отображения данных и анализа пользовательского ввода представляют собой две разные функции. Визуальное представление, возвращаемое свойством Text, можно манипулировать, используя различные свойства форматирования, и технически может отображать неполное представление базовых данных Value. Если существуют какие-либо конфликты между сохраненным свойством Value и свойством Text, естественно, что существующее свойство Value имеет прецедент.

Я предполагаю, что автоматическое связывание было "смягчено" для отчетов, чтобы обеспечить более гибкий вывод пользовательских отчетов. Сначала рассмотрим форму доступа в виде таблицы: элемент управления «Несвязанная форма» показывает одинаковое значение для всех записей . Даже если элемент управления редактируется в определенной строке, обновленное значение отображается для всех строк. Один и тот же объект элемента управления по существу перекрашивается для каждой строки, и отсутствует концепция отдельных экземпляров элемента управления, которые могут содержать разные значения. Связанные элементы управления имеют встроенный код, который перерисовывает элемент управления с данными из конкретной строки, но все еще существует , а не несколько экземпляров, каждый из которых "содержит" отдельные значения. Визуальный вывод отличается от интуитивной объектно-ориентированной парадигмы, в которой мы думаем о том, как назначать каждой визуальной строке свой собственный экземпляр элементов управления в памяти - он просто не работает так в Access.

В отличие от только что описанного поведения формы, предварительный просмотр отчета (и фактический вывод на печать) позволяет несвязанным элементам управления отображать разные данные в строке, используя событие Detail_Format (). В событии Detail_Format () можно установить свойство Value элемента управления, когда свойство Text автоматически обновляется в соответствии с различными свойствами форматирования. Этот текст обновления затем выводится для текущей строки. Возможно (только догадываясь), что это поведение не будет работать должным образом, если свойство Text обновит свойство value. Я подозреваю, что это вызовет рекурсивные события во время генерации отчета Поскольку отчеты не должны быть интерактивными, соответствующий код синтаксического анализа ввода текста был «отключен», чтобы он не вел себя так, как в форме.

Все это объяснение не делает Access менее расстраивающим и не снимает его ограничений, но, по крайней мере, учится приспосабливаться и проектировать вещи по принципу «доступа к безопасности», а не бороться с ним.