Заглушке переданы неправильные данные windows 10

Осуществляю в Delphi поиск в документе Word следующим образом :
var
SearchText : OLEVariant;
. WordApplication1.Selection.Find.Execute(SearchText,EmptyParam,EmptyParam,EmptyPa ram,EmptyParam,EmptyParam,EmptyParam,EmptyParam,EmptyParam,EmptyParam,EmptyParam ,EmptyParam,EmptyParam,EmptyParam,EmptyParam);

Но вместо поиска появляется ошибка "Заглушке переданы неправильные данные" с укзкнием на эту строчку. Остальные действия с word"ом работают.
Как быть?
Спасибо

← →
clickmaker © ( 2006-11-20 16:14 ) [1]

такое бывает при несоответствии версии клиентской библиотеки типов (tlb) версии сервера

← →
IGo ( 2006-11-20 16:22 ) [2]

to clickmaker

> такое бывает при несоответствии версии клиентской библиотеки
> типов (tlb) версии сервера

и что можно сделать?

← →
clickmaker © ( 2006-11-20 16:25 ) [3]

> [2] IGo (20.11.06 16:22)

Unit от какого офиса? И фактически с каким офисом работаешь?

← →
IGo ( 2006-11-20 16:28 ) [4]

unit — word2000
офис — 2002

Т.е. если я использую unit word2000, а на пк офис другой, то я с ним не смогу работать из Delphi?

← →
clickmaker © ( 2006-11-20 16:30 ) [5]

> [4] IGo (20.11.06 16:28)
> unit — word2000
> офис — 2002
>
> Т.е. если я использую unit word2000

я тебе так сходу не могу сказать. Надо сравнивать методы. Может параметр добавили или убрали, может тип поменяли.
Попробуй сымпортировать библиотеку типов от 2002 офиса и сравни с 2000

← →
IGo ( 2006-11-20 16:38 ) [6]

подцепил word2002. Параметры действительно немного другие. Но результат не изменился.

← →
IGo ( 2006-11-20 16:39 ) [7]

Ошибся : не word2002, а wordXP

← →
clickmaker © ( 2006-11-20 16:41 ) [8]

> [7] IGo (20.11.06 16:39)
> Ошибся : не word2002, а wordXP

это синонимы.
Значит, не нравится ему EmptyParam. Уверен, что обязателен только первый?

← →
IGo ( 2006-11-20 16:44 ) [9]

Нет, не уверен. Но толкового описания поиска в Word"е через дельфи я не нашёл. Только примеры с этой процедурой, но там она использовалась для поиска и замены. Соответственно я убрал параметры замены и всё. Я пробовал играть с другими параметрами, но результат тот же.

← →
Shirson © ( 2006-11-21 09:56 ) [10]

Ненужно искать описание поиска в Word через Delphi. Нужно найти в директории офиса chm файл с хелпом по VBA и посмотреть там.
У меня MSW2k, VBAWRD9.CHM

With Selection.Find
.Forward = True
.Wrap = wdFindStop
.Text = "Hello"
.Execute
End With

WordApplication1.Selection.Find.Forward:=True;
WordApplication1.Selection.Find.Text:="Hello";
WordApplication1.Selection.Find.Execute;

Что-то вроде того. Правда, я не пользуюсь для этого компонентам.

← →
IGo ( 2006-11-21 13:33 ) [11]

Я пробовал это с самого начала. И макросы в ворде смотрел. Но ничего не помогает.
Буду искать другие варианты решения.
Спасибо

Как и во множестве иных компонентов, входящих в состав операционных систем Microsoft, вопрос о исчерпывающей информативности возникающих ошибок Центра обновления Windows, тем более рекомендаций по их устранению, никогда всерьез разработчиками не рассматривался 🙂 Традиционно было решено ввести огроменный перечень числовых статусов (для того, чтобы хотя бы отдаленно понимать о чем идет речь) и завести специализированные танцесбубновые форумы поддержки (как например, незабвенный TechNet), на которых зачастую предлагаются довольно-таки абстрактные рекомендации. Все это, конечно же, сарказм, тем более что для человека думающего, подобные приведенному выше ресурсу является превосходной отправной точкой, задающей верное направление движения. Ну а в данном материале мы попытаемся каталогизировать ошибки Центра обновления Windows.

Тем не менее, в каждой шутке есть только доля шутки. Понятное дело, что в представлении любого нормального человека (а не наглухо отбитого виндового гика), голых идентификаторов для понимая природы происходящего часто недостаточно, требуется как минимум символическое имя. Символическое имя присутствует, но и оно в большинстве случаев, не дает понимания проблемы и не подразумевает каких-либо рекомендаций. Ко всему этому добавляются факторы взаимного влияния различных компонентов системы друг на друга, при которых, к примеру, причиной недоступности файла обновления может быть некорректная работы файловой системы. В итоге, для некоторых ошибок уже наработаны общие рекомендации по устранению, для других же имеются какие-то абстрактные предположения, в силу чего все форумы забиты сообщениями с указанием кодов возврата и вопросов: "Кто виноват?" и "Что делать?".
Одним словом, все это привело к тому, что и я тоже, по примеру немногих, решил составить такой своеобразный каталог ошибок центра обновления Windows, который будет всегда под рукой. Правда из него так же ничего не понятно 🙂 Но для меня лично непонятного меньше чем в сторонних источниках. Остановимся на следующих утверждениях:

• Надо понимать, что многие коды возврата, описанные в представленной ниже таблице, являются общими и их возникновение характерно для множества продуктов Microsoft (включая и Центр обновления Windows). Иными словами, неверно было бы считать все приведенные ошибки возникающими исключительно в компонентах Windows Update, тем не менее представлены и те, которые персонализированы исключительно для исполняемого кода группы компонентов Центра обновления Windows. Поэтому давайте условимся считать все приведенные в таблице ошибки возникающими исключительно в контексте исполнения процессов Центра обновления Windows.
• У некоторых может возникнуть ложное ощущение, что найдя код ошибки в таблице вы тут же найдете однозначное решение своей проблемы. Для некоторых ошибок это действительно так, однако в большинстве случаев ошибку надо рассматривать во взаимосвязи с другими ошибками, возникающими совместно с искомой (отображаются в логах в непосредственной близости или в одной сессии). Это банально позволит уйти от незначащих ошибок и найти основную, решение которой и изменит ситуацию.

Тип результата

По традиции компонентной модели Microsoft, ошибки Центра обновления Windows возвращаются в виде числовых идентификаторов, имеющих тип HRESULT (DWORD, 32-битовое целое).

В модели COM была предложена рекомендация, чтобы все функции на выходе, экспортируемые сервером и клиентом, возвращали результат работы типа HRESULT , по которому можно судить о результате выполнения функции (успех/неудача). Старший бит значения специфицирует успешное/ошибочное (0/1) завершении работы функции, следующие далее 15 битов содержат тип ошибки и обеспечивают способ группировки однотипных кодов завершения, младшие (правые) 16 битов предоставляют специфическую информацию о происшедшем. В модели-преемнице DCOM использование HRESULT уже было выдвинуто в виде обязательного требования. Возвращаемые символические значения в интерфейсе Win32 предваряются префиксом S_ в случае нормального завершения и префиксом Е_ в случае ошибки. Вот так, к примеру, выглядят некоторые типовые константы:

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

Методы использования

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

• Лицезреть ошибки Центра обновления Windows можно либо непосредственно в интерфейсе системы, либо по записям об ошибках в файлах %SystemRoot%WindowsUpdate.log и %Windir%LogsCBSCBS.log , а так же событий в системном Журнале Событий.
• Из информации в записях или интерфейсных окнах получаете шестнадцатеричное (либо десятичное) представление ошибки.
• В нижеприведенной таблице находите номер ошибки и смотрите алгоритм устранения в столбце Решение , если это ссылка, то щелкаете и переходите на статью с непосредственными рекомендациями по устранению.

Некоторые ошибки, возможно, никогда и не возникают в процессе работы Центра обновления Windows, а представляют собой информационные статусы/структуры, содержащие выводимые на экран статусные и информационные сообщения.

Вышла новая сборка Windows 10 Insider Preview под номером 14271. Заметных нововведений в ней нет – разработчики сосредоточились на исправлении ошибок и мелких недочетов. Тем не менее, в коде наблюдаются признаки файлов-заглушек для OneDrive.

Слухи о том, что заглушки для OneDrive вернутся в обновлении Redstone, уже всплывали некоторое время назад. Эта функциональность, напомним, появилась в Windows 8.1: в Проводнике отображались все файлы, хранящиеся в OneDrive, даже не загруженные на данный компьютер. Отсутствующие на компьютере файлы можно было скачать, дважды щелкнув по заглушке.

Однако не все пользователи понимали, в чем суть заглушек, и это зачастую приводило к возникновению проблем, так что из Windows 10 заглушки решено было убрать. Такое решение, в свою очередь, вызвало проблемы у пользователей, которые успешно нашли заглушкам файлов применение. Теперь ходят слухи, что в Redstone заглушки вернутся, и новая сборка уже содержит указания на это: MUI-файле библиотеки Windows.CloudStore.dll обнаружилась строка со словом «Placeholder» – «заглушка».

Одновременно с этим многообещающим признаком в сборке 14271 появились и новые проблемы. Некоторые компьютеры выдают синий экран при выходе из гибернации, а ошибка в драйвере мешает нормальной работе антивирусов «Лаборатории Касперского». Пока разработчики ищут решение, рекомендуется не пользоваться гибернацией и установить любой другой антивирус.

Оцените статью: