Поиск по display полю

[Кирилл Борисов]

Каким образом вызвать стандартный диалог поиска по display-полю
(при нажатии пользователем комбинации Ctrl-F)
и реализовать данный поиск?

[ТРЕНЕР]

никак

[Кирилл Борисов]

Спасибо, я это знаю.
Я создал эту ветку, чтобы предоставить распечатку обсуждения моему постановщику задачи.
Поэтому хотелось бы, чтобы слово "никак" написал некто Мазуркин Сергей или Максим Горбунов, которые, надеюсь, являются для моего постановщика задач авторитетами в этой области.

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

[mazzy]

Интересный способ использования форума

Тренер прав - никак.
Только долго и мучительно программировать.

Может Максим что дополнительно посоветует...
Но сомневаюсь.

[Maxim Gorbunov]

В Вашей постановке вопроса, на самом деле можно, но долго программируя То есть, перехватываем нажатие Ctrl+F + изменяем контекстное меню, чтобы в нем появился пункт фильтр + по возврату данных из формы поиска разбирать их и накладывать фильтр. В общем, как Вы видите, обходной путь найти можно, но стоимость такого решения будет очень высока, и в целесообразности я бы очень сильно усомнился.

Чтобы ответить аргументировано, разобью Вашу задачу на две:
1. Вызов формы поиска, при нажатии Ctrl+F.
2. Обработка результатов ввода в форму поиска.

1 задача менее сложна, так как заключается только в том, чтобы добавить обработку определенной комбинации клавиш в метод task и изменение контекстного меню для конкретного контрола. Однако решить ее в общем случае невозможно (по крайней мере, сейчас я не готов предложить решение). Таким образом, это придется делать для каждой формы и для каждого поля, в котором Вы собираетесь организовывать поиск по значению display-метода. Кроме того, нужны будут некоторые модификации для формы SysFormSearch.

2ую задачу можно решать двумя способами. Первый (наиболее логичный и не всегда применимый) - разбирать значение, которое пришло из SysFormSearch, и на основании этого накладывать фильтр на физически существующие в системе поля. Очевидно, что это сделать можно далеко не всегда. И в каждом случае нужно будет делать свой разбор. Второй - создать временную таблицу с двумя полями: RecId в фильтруемой таблице и значение display-метода. При этом вам нужно будет каждый раз при обработке поиска заполнять эту таблицу для всех (!!!) строк фильтруемой таблицы. Далее, надо будет подсунуть временную таблицу в запрос.

Ну и наконец, главная причина, по которой этого делать не стоит: Microsoft сейчас активно изменяет контролы на форме. В частности, в SP3 появилась возможность копировать в буфер обмена значения display-методов (кстати, можете предложить через буфер копировать значения в Excel и делать там Автофильтр ) Вы совершенно не застрахованы от того, что эту функциональность не реализуют на уровне ядра в следующем SP. Таким образом, инвестиции в разработку этой функции будут совершенно безсмысленны.

P.S.: Если это настолько критично, добавьте в таблицу нормальное поле, которое будет инициализироваться с помощью display-метода в методах insert() и update() таблицы. Много нервов сэкономите

[ТРЕНЕР]

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

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

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

Например, замена дисплей-метода на поле позволяет делать стандартный поиск по маске и сортировку, делает возможным включение поля в авто-отчет, упрощает построение других отчетов по данной таблице. Если эти возможности существенно упрощают и ускоряют работу конечных пользователей, и при этом не приводят к большим затратам, то это безусловно нужно сделать.

[mazzy]

Спасибо, Тренер.
Спасибо, Максим.

[Кирилл Борисов]

Спасибо ;-)

[raz]

Иногда можно стандартными средствами выкрутиться:
1. Должны быть обновлены перекрестные ссылки.
2. Используем стандартный механизм фильтрации, добавляя нужную таблицу в запрос.

ЗЫ. Иногда необходимо добавить relation на таблицы.

ЗЗЫ. Пример выбора заказов по номенклатуре в приатаченном файле..
[attachment=215:attachment]

[mugz]

Цитата:

Сообщение от Тренер

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

Вот, кстати, рецепт на случай, если надо сделать такую замену в редактируемом источнике данных. Правда, сам не пробовал