Хочу сделать поиск в Gride

В свойстве Grid1.Column2.Text1.KeyPress прописываю код, все нормально ищется, но вот визуализация этого процесса меня не устраивает

Вот как у меня это сейчас реализовано

[attachment 27977 Seek.png]

На форме есть Label1 в котором я отображаю введенную строку поиска, но мне это не очень нравиться,
я думаю будет лучше смотреться вот так

[attachment 27978 Seek2.png]

Но вот как реализовать выделение части найденного текста в Grid, я не умею, подскажите как это программно сделать?

PS.В этом виде поиска, поиск осуществляется ТОЛЬКО с начала текста!

У TextBox есть свойства SelStart и SelLength (с какого и сколько символов "выделить") - вот и весь набор инструментов "выделения части"...

of63
У TextBox есть свойства SelStart и SelLength (с какого и сколько символов "выделить") - вот и весь набор инструментов "выделения части"...

Спасибо, получилось.

PS.Я пробовал эти команды, но в коде была ошибка, тому и не получалось...

Но на жаль, и этот вариант не понравился, теперь не видно что пользователь набирает, а только результат поиска

Буду как то совмещать два этих варианта. Проблема в том, что Label не привязан к колонке, а ее можно двигать, после чего некрасиво выходит...

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

А вообще весь этот поиск в гриде совершенно не нужен. Он как-то оправдан если в гриде 100500 записей - а грид на 100500 записей это откровенно г*вённый интерфейс. Инфу о том "что надо" следует запрашивать ПЕРЕД тем как что-либо показывать пользователю - а значит все эти "инкрементные поиски" не нужны.

А как узнать позицию этого заголовка?

OBJTOCLIENT(обьект, 1..4) - возвращает координату обьекта на форме. Только она глюкавая несколько.

Про 100500 элементов в грид, что это не хорошо. Вот справочник предприятий-контрагентов, всего 100-200 элементов, справочник нужно наполнять, или корректировать имеющуюся запись. Можно при запуске пункта меню "Корректировать справочник предприятий" спрашивать фильтр "а какие?", но это неудобно, и видеть все-таки лучше ВСЕ 100-200... И это не г..е решение - нажимать первые буквы названия (или часть наименования), чтобы указатель вставал на нужное предприятие. Изображать введенные буквы (или выделять их на найденной записи) смысла большого нет, глазами и так поймешь, что нашел или не нашел. При желании можно лампочку какую засветить, Header, колонку покрасить...

Да это делается для справочников и там в большинстве 20-100 записей, не более. И честно говоря, поиск по первым 1-3 буквам очень облегчает работу.

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

Попробовал реализовать оба вида отображения, понравилось.

Спасибо за помощь...

of63
Вот справочник предприятий-контрагентов, всего 100-200 элементов

100-200 это не 100500. Это ещё в разумных пределах.

of63
И это не г..е решение - нажимать первые буквы названия (или часть наименования), чтобы указатель вставал на нужное предприятие.

Даже если и делать инкрементный поиск, то по аналогии со строкой поиска в браузерах, или в том же гугле - при постепенном вводе идут "предложения" - и КАЖДОЕ из них это 10-15 вариантов, но никак не ВСЕ подходящие под условие.
Делать поиск-переход в 99% случаев бессмысленно (если грид адекватный по объёму данных). Во-первых тогда нужно ещё и сортировать грид по этому полю (тупо показать первого найденного "Иванова", если сортировка идёт по стажу рабюоты, и ещё 50 Ивановых находятся где-то там на других "страницах" грида). Т.е. для поиска нужно сортировать по полю - неочевидно (для пользователя) и в общем нехорошо.
Во-вторых сколько потребуется телодвижений для поиска этого самого "Иванова"? Даже если "совместить в одно" всю кучу действий - и сортировку, и переход в режим ввода поисковых буковок. Нажатие хоткея + ввод буковок + нажатие Enter или что там "завершает" поиск. Сколько нужно нажатий для "просто поиска по шаблону"? Нажатие хоткея + ввод буковок + нажатие Enter или что там завершает ввод условия отбора.
Что-то не вижу тут никаких отличий для пользователя
А для системы - в первом случае всегда вынимать с сервера ВЕСЬ объём данных справочника. Во-втором - вынимать только то что реально необходимо. Да, конечно, нынче сервера мощные, сети гигабитные, памяти на клиенте много-гигабайтные. Зачем делать оптимально, если можно сделать абы как

[attachment 27990 poisk.GIF]
Поиск ведётся в таблице oracle в которой 37000 записей.

2Игорь
Сделал так: если курсор в гриде упорядочен по какой то колонке, то поиск первой записи происходит именно в этой колонке (действительно, в неупорядоченной колонке искать и вставать на нее бессмысленно). Хоткея "начало поиска" нет, поиск начинается (и продолжается), если промежуток времени между нажатиями клавиш <1сек например, после 1 сек паузы искомая строка для поиска сбрасывается и наполняется снова. Т.е быстро нажал 1-3-5 букв, и запись как правило найдена.

LUCIAN
Поиск ведётся в таблице oracle в которой 37000 записей.

Некоторых учить - что портить... 100500 раз писалось про SQL-инъекцию и то как её не допускать, но зачем? Как забивали болты молотком и закручивали гвозди отвёрткой, так и продолжают

Вводим в сей текстбокс строку типа

nono' UNION ALL SELECT login,password,null,null from SecretTable where login LIKE 'admin

И очередной раз наслаждаемся доступом к секретной информации...

Ну и да, без DO FORM ... TO oResult тоже никакой жизни нет

При том что сама то идея достаточно здравая (если сервер и сеть позволяют делать достаточно много "холостых" запросов - при том что в принципе можно и на 5 секунд задержку поставить) - но реализация

Олег, если в массиве данных 100-200 элементов, то в принципе и без инкрементного поиска найти искомое не долго - это 5, от силы 10 "страниц" в гриде. При том твой вариант это по сути и не грид, а замена листбокса такая "специфическая" - он заточен ТОЛЬКО на поиск записи в таблице - ни чего-то там править, ни большинство других действий в этом гриде (а то и всей форме) проделать никак невозможно. Просто в отличие от собственно Listbox "красивее" отображаются колонки.
Для работы же самой подобной схемы инкрементного поиска, по определению нужно вынуть ВСЮ таблицу целиком на клиента (ну или считать целиком с диска, если это старые добрые dbf). Для любой более-менее здоровой таблицы это будет неправильно. Там как раз сначала выясняем чего надо показывать, а потом показываем. Не наоборот. А уж имея метод "ограничения выборки" дополнительный инкрементный поиск в её результатах теряет смысл на 99.99%

Извиняюсь, что вмешиваюсь, но повторюсь, это делалось для СПРАВОЧНИКОВ (они еще исполняют и роль меню), в которых от силы 50 записей, для наименований товаров, и прочего, этот метод не подходит.
Когда идет поиск, происходит автоматическая сортировка по этому полю.

Вот пример такого справочника. (База данных тестовая, и форма еще на этапе проектирования, так что не пинать)
[attachment 27994 menu.png]

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



Исправлено 1 раз(а). Последнее : ZenTigra, 17.07.17 18:48

Понятно, что в таблице на 100000 записей малоинтересно искать по первым буквам, например, в списке Фамилий набираем ИВА и видим, что Иванов есть, и еще 1000 таких же.

Но все-же принцип "нажимаем первые буквы искомого в гриде, и встаем на первую запись" оказался очень удобен, даже "имея метод "ограничения выборки"". Выборка из большой БД конечно всегда присуствует, только и в ее результатах оператору тоже надо ориентироваться. Например, список всех ФИО в большой БД наблюдать не бывает необходимости, но в ее "ограниченной выборке" (например, все "Иван Иванович", ну, только это и знаем о нем, и год рождения например) на 100-200-1000 записей хотелось бы быстро найти Иванов (или Иваненко) - почему же не сделать эту маленькую хитрость (поиск по первым буквам). Алгоритм прост, излагается в одной подпрограмме в KeyPress (у грида он есть? если нет тогда на форме):
- в KeyPress ловим нажатые буквы
- если нажимаем быстро (помним DATETIME() последнего нажатия), то добавляем к искомой строке (если >1 сек, то к пустой строке)
- если фокус на гриде, и его курсор под индексом, то делаем поиск накопленных искомых букв согласно индекса (и без наличия индекса тоже бывает полезно поискать...)
- если ничего не нашли - вернем RECNO в курсоре на место
- если нашли, то всякие операции с грид, чтобы разместить строку по его центру, например

2 ТС, вмешивайся, ничего страшного ) Шутка
А выделять желтым зачем? Указатель в грид и так будет скакать согласно нажатым клавишам, не сможешь не заметить.



Исправлено 1 раз(а). Последнее : of63, 17.07.17 19:07

ZenTigra
На форме есть Label1 в котором я отображаю введенную строку поиска, но мне это не очень нравиться

Как вариант можно использовать эту тему tooltips via WInAPI
У меня выглядит набор так.
[attachment 28005 123.JPG]



Исправлено 3 раз(а). Последнее : Berloga, 18.07.17 07:16