Для чего нужна программа search

Протокол search:application — это расширяемое соглашение для вызова классического приложения поиска в Windows Vista с пакетом обновления 1 (SP1) и более поздними версиями. Протокол был создан в Windows Vista с пакетом обновления 1 (SP1), чтобы предоставить Windows способ определения и вызова классического приложения поиска по умолчанию.

Синтаксис протокола предоставляет ряд параметров, полезных для выполнения общих поисковых запросов на рабочем столе, таких как введенные пользователем условия поиска или расположение, в котором был начато поиск. Когда пользователи выполняют поиск из одной из двух доступных точек входа (меню «Пуск» или Windows Explorer), операционная система использует протокол поиска для запуска классического приложения поиска по умолчанию. Это делается путем добавления введенных пользователем условий поиска в стандартный синтаксис протокола поиска и передачи этих сведений приложению, зарегистрированного в качестве приложения поиска по умолчанию.

Если другие классические приложения поиска не установлены, поиск, введенный в эти точки входа, запускает обозреватель поиска Windows. Однако сторонние разработчики могут создавать, устанавливать и регистрировать свои приложения для обработки протокола поиска и быть приложением поиска по умолчанию. Такие приложения должны поддерживать синтаксис протокола поиска и регистрироваться в компоненте «Программы по умолчанию», чтобы обеспечить беспроблемную работу с Windows.

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

Поиск: протокол не заменяет собственный протокол search-ms: Приложения по-прежнему могут использовать протокол search-ms: для запуска обозревателя поиска окна или автоматического запроса индексатора поиска Windows.

В этой статье рассматриваются следующие вопросы:

• Синтаксис
• Windows Vista с пакетом обновления 1 (SP1) используется протокол поиска:
• Примеры
• Регистрация приложения, обрабатывающего протокол

• Записи реестра

Синтаксис

Протокол поиска использует следующий стандартный синтаксис в кодировке URL-адресов:

search_parameter=value[

Синтаксис начинается с идентификации самого протокола (search:). Пары параметров и значений — это аргументы, передаваемые поисковой системе, как описано в следующей таблице, в которой показаны все возможные параметры синтаксиса протокола поиска.

Параметр Значение Описание:

query	Текст в кодировке URL	Текст запроса, введенный пользователем.
inputlocale	Любой допустимый код языка (LCID)	Код кода, идентифицирующий язык ввода для запроса.
keywordlocale	Любой допустимый LCID	LCID, идентифицирующий язык международной версии индексатора. Значение по умолчанию — 1033 (en-us).
Крошки	Оператор AQS	Этот аргумент ограничивает область поиска. В Windows Vista протокол поиска поддерживает полные AQS, а также специальную реализацию аргумента location . В Windows XP протокол поиска также поддерживает полные AQS, за исключением специальной реализации kind и store .
Синтаксис	NQS, AQS (без учета регистра)	Синтаксис запроса, используемый для поиска по индексу: синтаксис естественного запроса или расширенный синтаксис запросов (AQS). AQS — это значение по умолчанию и всегда предполагается синтаксический анализ и поддержка.
stackedby	Любое допустимое свойство из системы свойств	Свойство, задающее столбец для стека результатов.
subquery	Полный указанный путь для сохраненного файла поиска (*.search-ms)	Результаты вложенного запроса используются в качестве источника запроса. То есть условия запроса ищутся в результатах вложенного запроса.
displayname	Строка в кодировке URL-адреса	Имя текущего поиска.

Windows Vista с пакетом обновления 1 (SP1) используется протокол поиска:

Windows Vista с пакетом обновления 1 (SP1) имеет несколько точек входа, из которых вызывается протокол поиска: протокол. Эти точки входа описаны ниже, а также общий синтаксис, связанный с каждым из них.

Точка входа протокола поиска Расположение Вызывается запрос

Поиск везде	Меню «Пуск»	search:query=Search Term>
Поиск везде	Проводник	search:query=Search Termcrumb>
Клавиша Windows+F	В любом месте	Поиск:
CTRL+F	Проводник	search:query=Search Termcrumb>
F3	Меню «Пуск»	Поиск:
F3	Проводник	search:query=Search Termcrumb>

Точка входа протокола поиска Windows Vista с пакетом обновления 1 (SP1) не использует все возможные параметры в протоколе поиска. Приложения, которые касаются только обработки вызовов протокола поиска из Windows Vista с пакетом обновления 1 (SP1), могут использовать следующую таблицу в качестве руководства к минимуму, который необходимо реализовать.

Параметр Используется Windows? Как Windows Vista с пакетом обновления 1 (SP1) использует его при вызове поиска:

query	Да	Текст запроса, введенный пользователем.
Крошки	Да	Crumb использует location аргумент, чтобы указать, откуда поступил запрос.
subquery	Да	Результаты аргумента subquery используются в качестве области элементов для поиска. Это обычно используется, если пользователь использует ФАЙЛ SEARCH-MS для поиска, а затем вызывает приложение поиска по умолчанию из этого поиска.
inputlocale	Нет	В настоящий момент не используется.
keywordlocale	Нет	В настоящий момент не используется.
Синтаксис	Нет	В настоящий момент не используется.
stackedby	Нет	В настоящий момент не используется.
displayname	Нет	В настоящий момент не используется.

Примеры

Если пользователь вводит «Майкрософт» в меню «Пуск » и нажимает кнопку «Поиск везде», будет выполнен вызов протокола поиска:

search_query=microsoftSeattle» в Windows Explorer в папке C:MyFolder и нажимает кнопку «Поиск везде», выполняется следующий вызов, используя escape-символы для «:» и «».

search_query=seattleПрограммы по умолчанию » во время установки, чтобы пользователь мог легко настроить значение по умолчанию. Помимо процедур установки, которые обычно практикуются в Windows XP, приложение на основе Windows Vista должно зарегистрировать в компоненте «Программы по умолчанию», чтобы приложение и пользователи могли легко настраивать значения по умолчанию.

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

1. Запись идентификаторов ProgID в HKEY_LOCAL_MACHINE, как описано ниже. Обратите внимание, что приложения должны создавать идентификаторы ProgID для конкретного приложения для протокола поиска.
2. Утверждение сопоставления протокола поиска на уровне компьютера.
3. Зарегистрируйте приложение с помощью программ по умолчанию, как описано в разделе «Регистрация приложения для использования с программами по умолчанию» в качестве претендента на протокол поиска.

Записи реестра

Ниже приведены примеры обязательных записей реестра для вымышленного классического приложения поиска Contoso Search.

HKEY_LOCAL_MACHINE SOFTWARE Classes contoso-search URL Protocol = «»
HKEY_LOCAL_MACHINE SOFTWARE Classes contoso-search DefaultIcon (Default) = %ProgramFiles%ContosoSearchcontososearch.exe,-7
HKEY_LOCAL_MACHINE SOFTWARE Classes contoso-search shell open command (Default) = %ProgramFiles%ContosoSearchcontososearch.exe %1
HKEY_LOCAL_MACHINE SOFTWARE RegisteredApplications Contoso Search = «Software\Contoso\Search\Capabilities»

HKEY_LOCAL_MACHINE SOFTWARE Contoso Search Capabilities ApplicationName = «Contoso Search Test App» ApplicationDescription = «Contoso search is a great new desktop search application»
HKEY_LOCAL_MACHINE SOFTWARE Contoso Search Capabilities UrlAssociations search = «contoso-search»

Источник: learn.microsoft.com

App Search

Поиск приложений — это приложение для поиска приложений, которое быстро ищет ваши приложения.

Основные функции AppSearch:
Search Самый быстрый поиск
☆ показывает недавнюю историю
Info Информация о приложении
App удалить приложение
☆ Нажмите на значок поиска на клавиатуре, откроется первое приложение в результатах поиска
Ves экономит время
☆ Маленькое приложение
Adds не добавляет
☆ Поддержка планшетов

Инструкция:
Search Введите ключевое слово для поиска в поле поиска
☆ Нажмите на название приложения, чтобы открыть приложение
☆ или нажмите значок поиска на клавиатуре, чтобы открыть первое приложение в результатах поиска

Последнее обновление
17 нояб. 2019 г.

Безопасность данных

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

Нет информации.

Оценки и отзывы

Оценки и отзывы проверены info_outline
arrow_forward
Оценки и отзывы проверены info_outline
phone_android Телефон
tablet_android Планшет
634 отзыва
Vadim Demin

more_vert

• Пожаловаться

9 ноября 2020 г.

Утилита, расширяюшая функционал как стандартного лаунчера от Google, так и многих других (скажем, для Nova она не нужна — этот функционал там уже имеется: строка поиска в меню ее прекрасно заменяет). Приложение бесплатное, потому оценка — «отлично».

Источник: play.google.com

SEARCH — слухи и факты

Все чаще на страницах журналов, посвященных САПР, стали появляться статьи, в которых авторы (чаще всего — осознанно) преподносят читателям заведомо недостоверную информацию о том или ином программном продукте или его производителе. К сожалению, это отражает специфику конкурентной борьбы на российском рынке САПР.

Многочисленные «доброжелатели» старательно бомбят предприятия письмами, факсами с рассказами о скорой кончине своих конкурентов и плохом качестве их программных продуктов. В связи с этим хотелось бы обратиться ко всем продавцам и покупателям САПР: «Господа продавцы! Давайте будем рекламировать свои программные продукты и оставим в покое чужие!

Пусть пользователи решают сами, какой программный продукт лучше подходит для решения их задач. Господа покупатели! Не расспрашивайте продавцов одной системы о прелестях и недостатках конкурирующей! Правду вы от них все равно не услышите, а только дадите им лишний повод взять грех на душу».

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

В данной статье я хотел бы опровергнуть слухи, которые упомянутые доброжелатели распространяют об одной из самых популярных отечественных систем документооборота и управления информацией — о программном комплексе Search производства компании «ИнтерМех». Сразу оговорюсь, всю информацию, которую я привожу о данном программном продукте, вы можете проверить сами, обратившись непосредственно в компанию «ИнтерМех». Там же можно получить пробную версию системы для опытной эксплуатации на своем предприятии. А теперь начнем нашу импровизированную дискуссию.

Search предназначен для работы только с САПР CADMECH

Действительно, первая версия Search, которая вышла в 1990 году, разрабатывалась в качестве модуля расширения системы CADMECH и предназначалась для поиска файлов чертежей. Сегодня Search — это универсальная система документооборота и управления информацией об изделиях, способная взаимодействовать с множеством программных продуктов самого различного назначения. При этом механизмы взаимодействия также могут быть самые разные, например:

• посредством чтения различной информации непосредственно из файлов документов (например, чертежей AutoCAD и Mechanical Desktop, спецификаций и ведомостей AVS, документов MS Word и электронных таблиц MS Excel и т.д.);
• с использованием стандарта ODMA (Open Document Management API), который представляет собой стандартный API для организации взаимодействия между системами управления документами и внешними программами. В этот стандарт входят: набор функций, позволяющий заменять в редакторе документов стандартные диалоги открытия и сохранения файлов на аналогичные диалоги системы документооборота, функции для обмена атрибутивной информацией между редакторами и системами управления документами, а также функции, предназначенные для обеспечения ссылочной целостности многофайловых документов. В настоящее время стандарт ODMA поддерживается множеством программных продуктов — как зарубежных (Microsoft Office, Corel WordPerfect Suite), так и отечественных (КОМПАС-График, FineReader и т.д.);
• с помощью встроенных в Search модулей интеграции с различными CAD-системами (например, с SolidWorks, Solid Edge, Autodesk Inventor), позволяющих полностью автоматизировать процесс получения информации о составе и параметрах сборочных единиц и деталей, модели которых созданы в этих CAD-системах;
• посредством встроенного интерфейса программирования Search API, который позволяет получить авторизованный доступ на чтение и запись к большинству объектов системы. В частности, этот интерфейс используют для взаимодействия с Search большинство программных продуктов НПП «ИнтерМех» — Cadmech, Cadmech Desktop, Techcard, LCAD, AVS. Многие пользователи Search также используют в своих собственных разработках функции интерфейса Search API, что, с одной стороны, увеличивает функциональные возможности этих программных продуктов и снижает затраты на их написание, а с другой — позволяет внедрить Search в общее информационное пространство предприятия и обеспечить поддержку всего жизненного цикла выпускаемых на предприятии изделий;
• путем обеспечения хранения в Search файлов документов любого типа с ручным заполнением карточек с атрибутами и автоматическим вызовом соответствующих внешних программ для просмотра, редактирования и печати этих документов. При этом сохраняются все взаимосвязи между составными и многофайловыми документами, что обеспечивает комплексное извлечение из архива Search всех файлов, необходимых для редактирования или просмотра документа.

Использование Search API предполагает «наличие у заказчика специалистов по программированию на конкретном языке»

По крайней мере, такой вывод можно сделать, прочитав статью «Критерии сравнения систем TDM/PDM» в журнале «САПР и графика» № 1’2002. Автор этой статьи не может не знать, что интерфейс Search API построен на технологии COM (Component Object Model), которая является стандартом взаимодействия Windows-приложений. Вызовы COM-функций позволяет осуществлять практически любая среда программирования, способная генерировать 32-битные Windows-приложения. Пользователи Search используют для этого и Visual C++, и Delphi, и Visual Basic, и Oracle Forms, и даже Word Basic. Что касается поставляемых с Search примеров использования функций API, то они написаны на Delphi главным образом потому, что он является самой распространенной в странах СНГ средой разработки Windows-приложений.

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

1. База данных может храниться в собственном формате, разработанном специалистами данного предприятия.
2. Часть информации может храниться в MEMO-полях в соответствии с какими-либо правилами (например, номер_параметра=значение, а номер вычисляется по имени через промежуточную таблицу).
3. Значащая информация об изделиях может храниться вперемешку с информацией, необходимой для ее визуального представления (например, вывода на печать конструкторской спецификации).
4. База данных может содержать какие угодно правила извлечения информации (например, если в поле FIELD1 содержится ‘A’, то последующие цифры в этом поле означают номер записи в таблице TABLE1, в которой содержится соответствующая запись с допустимой заменой вида «один-на-один»).
5. Также может потребоваться периодическая синхронизация информации между исходной базой данных и базой Search и т.д.

Интерфейс Search API значительно облегчает процесс занесения информации в Search и позволяет программисту сосредоточиться на решении задач, связанных с чтением информации из исходной базы данных. Если же на предприятии вообще нет своих программистов, то задачи импорта существующей информации помогут решить специалисты НПП «ИнтерМех».

Система Search существует на рынке более 10 лет и поэтому устарела морально и технологически

С такими заявлениями трудно спорить — система Search версии 1.0 действительно давно устарела. Однако с тех пор на рынок вышло еще пять поколений этой системы, в которой постепенно претерпело изменение все: функциональность, используемые СУБД и операционные системы, технологии и языки программирования. Однако очень важно, что с момента выхода первой версии Search накоплен большой опыт работы системы на сотнях предприятий и учтены пожелания тысяч пользователей системы. А без этого не может быть надежной и масштабируемой информационной системы, способной отвечать разнообразным требованиям заказчиков. Хотелось бы предостеречь читателей от поспешного приобретения сложных программных продуктов (будь то PDM-, MRP- или CAD-системы), которые недавно появились на рынке (или еще даже не появились), в противном случае вам придется потратить немало времени и средств на доработку и отладку таких программ, вместо того чтобы заниматься своей работой.

Search может быть использован для автоматизации документооборота только на машиностроительных предприятиях

Изначально Search был предназначен для автоматизации документооборота в машиностроительной отрасли стран СНГ, поэтому настройки системы по умолчанию ориентированы на работу с документами в соответствии с правилами ЕСКД и ЕСТД. Однако гибкая архитектура системы позволяет применять ее во многих предметных областях. В Search настраивается практически все: пользовательский интерфейс, наборы параметров для документов и изделий, бланки извещений и отчетов, маршруты движения документов и заданий, права доступа к объектам системы, правила работы с документами любого типа и т.д. В настоящее время система успешно работает на множестве машиностроительных и приборостроительных предприятий, а также в проектных организациях.

Для формирования состава изделия в Search нужно обязательно оформлять конструкторскую спецификацию

На самом деле это всего лишь один из способов формирования состава изделий в базе данных Search. Например, САПР CADMECH и редактор конструкторских документов AVS позволяют на основании сборочного чертежа изделия автоматически сформировать его спецификацию, по которой Search затем ведет базу данных состава и применяемости изделий. Формировать проектные связи изделия можно также:

• из внешних программ с помощью функций Search API;
• автоматически при занесении в Search сборочных моделей SolidWorks, Solid Edge и Autodesk Inventor;
• простым перетаскиванием изделий с помощью мыши в схему проектных связей;
• с помощью специальных команд в режиме отображения дерева проектных связей изделия.

Search может хранить файлы документов только в базе данных, что не дает возможности использовать для хранения документов такие устройства, как, например, магнитооптические библиотеки

В комплект поставки Search 6 входит специальная служба (сервер документов), способная хранить файлы документов на любом устройстве, которое доступно в ОС Windows в качестве логического диска. Это может быть и обычный винчестер, и магнитооптическая библиотека, и сетевое устройство хранения данных, и даже удаленный FTP-сервер. Однако в Search оставлена возможность хранения файлов документов и в базе данных, поскольку СУБД обеспечивает дополнительный уровень защиты информации, хранящейся в файлах документов, от несанкционированного доступа к ней. К тому же стоимость хранения информации на тех же магнитооптических библиотеках уже давно превысила стоимость ее хранения на жестких дисках, а время доступа к данным по-прежнему остается длительным.

Search хранит файлы документов централизованно, что увеличивает вероятность потери документов в случае выхода из строя сервера, на котором эти документы хранятся

Вместо опровержения данного заявления задам два простых вопроса:

• вероятность какого события выше: отказа сервера или поломки одной из сотни рабочих станций?
• в каком случае администратору легче организовать страховое копирование информации: если она находится на одном сервере в одной базе данных или если она распределена по тысячам каталогов на сотнях рабочих станций?

Конечно, если вы вместо надежного сервера намерены использовать персональный компьютер кустарной сборки и при этом не очень беспокоитесь о страховом копировании важной информации, то никакой Search не спасет вас от потери документов. В этом случае лучшее решение — шкаф с многочисленными листами ватмана плюс огнетушитель.

Бессмысленно брать систему в опытную эксплуатацию

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

Вместе с Search необходимо приобретать СУБД

Верно, но не совсем. Search может работать и с СУБД InterBase 6.0, бесплатную версию которой компания Borland предоставляет на официальном сайте производителя.

Вообще, СУБД InterBase обладает достаточной масштабируемостью для обслуживания 100-150 рабочих мест Search. Если же вам требуется более надежное и масштабируемое решение, то придется приобретать СУБД Oracle. При этом нужно учесть, что для работы различных информационных систем крупного предприятия все равно требуется СУБД такого же класса, как Oracle, поэтому рано или поздно предприятию придется приобретать подобную СУБД. Следует отметить, что, идя навстречу пожеланиям пользователей, компания «ИнтерМех» готовит к выпуску новую версию Search 7, которая будет работать с еще одной промышленной СУБД — MS SQL Server, которая по надежности и производительности не уступает СУБД Oracle, но отличается от нее более простым администрированием и значительно меньшей стоимостью.

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

В статье «Миф о Windchill», опубликованной в журнале «САПР и графика» № 11’2001, автор производит сравнительный анализ нескольких западных PDM-систем, из которого следует, что интерфейс рекламируемого им iMAN, в отличие от остальных систем, полностью переведен на русский язык. И рядом приводит иллюстрации пользовательского интерфейса iMAN, в которых нет ни одного русского! Как говорится, и смех и грех.

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

1. Неполный и неточный перевод документации и справочной системы. Это действительно большая проблема, поскольку документация к сложной PDM-системе может содержать десятки томов.
2. Неполный перевод подсказок, сообщений об ошибках, вспомогательных утилит и т.п. При этом любой пользователь такой системы рискует увидеть на экране сообщение типа Discard changes? Yes/No. Вам лучше заранее обучить своих сотрудников английскому языку.
3. Не факт, что следующая версия этой системы вообще будет переводиться на русский язык. Существует много примеров, когда крупные западные компании заявляли о бесперспективности российского рынка и закрывали свои представительства в странах СНГ.
4. А как насчет поддержки российских стандартов (ЕСКД, например)? А насчет выпуска различных конструкторских спецификаций, извещений об изменениях, ведомостей и т.п.?

В заключение необходимо отметить, что компания «ИнтерМех» продолжает активно развивать Search. Новое, седьмое поколение системы будет построено с использованием многоуровневой модели сетевых вычислений, будет иметь гораздо более совершенные механизмы администрирования и разделения прав доступа к объектам системы, принципиально новый модуль маршрутизации документов, способный управлять бизнес-процессами всего предприятия. Появится возможность хранения данных в еще одной популярной СУБД — MS SQL Server. Также расширятся возможности системы по управлению жизненным циклом изделия, в частности появится возможность получения состава изделия на определенную дату или для изделия с определенным серийным номером. Более подробно новые возможности InterMech Search 7 будут рассмотрены в следующих статьях, посвященных этой популярной информационной системе.

«САПР и графика» 3’2002

Источник: sapr.ru