Нужен компонент, реализующий Internet Explorer и MSWord одновременно. Т.е.
— со стороны пользователя компонент должен быть обычным броузером, а
— со стороны кода компонент должен предоставлять доступ к странице, как к документу Word'а.

Нужно это для того, чтобы сохранять действия пользователя и воспроизводить их без его участия для обработки элементов, которые он выбирал. Например, пользователь один раз заходит на такую-то страницу и выделяет текст, а мой код потом периодически будет заходить на эту страницу и загружать на винт текст с теми же свойствами(расположение в документе в пикселах относительно угла всего документа, положение среди других элементов страницы, порядковый номер элемента, имя, размер, что-то еще). Или пользователь заходит на другую страницу и выбирает картинку, а мой код потом заходит каждый день на эту страницу и сохраняет картинку, у которой те же свойства, что и у той, которую выделял пользователь. Для идентификации объекта, который выбрал пользователь мне и нужен богатый набор свойств, как тот, который доступен VBA программисту в Word'е.

Общий вид:
Пользователь ходит по страницам и выбирает разные ресурсы.
Мой код ходит по тем же страницам, находит те же ресурсы и сохраняет их.

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

зы Извените, если вопрос слишком легкий(ламерский), но для меня он достаточно сложен.

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

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

А так — программа даже на внедрённом в код страницы JS может сделать всё с анализом документа, вопрос только в том ,кто её будет писать.

Здравствуйте, 12345_, Вы писали:

_>Об этом мечтали о тначала развития интернета, и всё упиралось в то, что нет алгоритма идентификации похожих с точки зрения человека объектов. Чуть изменится код страницы — программу, прекрасно работающую и долго отлаживавшуюся приходится переписывать.
Если она будет ждать точно такую же страницу, то да. А если идентификация будет происходить по большому количеству свойств?

_>Пошли другим путём — RSS-каналы, включающие подходящую для обработки информацию. Появился поисковик, работающий исключительно на предоставленной ему поисковой информации (не помню название), организованной в XML.
RSS — это же новости. С помощью них описывают только последнюю информацию. Или нет?

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

_>А так — программа даже на внедрённом в код страницы JS может сделать всё с анализом документа, вопрос только в том ,кто её будет писать.
А JScript умеет разбирать текст отображаемый броузером на абзацы?

Мои пять копеек по последнему пункту:
O> А JScript умеет разбирать текст отображаемый броузером на абзацы?
Это сделано еще до отображения. Тегом <p>, например. А разобрать DOM в JS никто не мешает.

Здравствуйте, Ocenochka, Вы писали:

_>>А так — программа даже на внедрённом в код страницы JS может сделать всё с анализом документа, вопрос только в том ,кто её будет писать.
O> А JScript умеет разбирать текст отображаемый броузером на абзацы?
JavaScript умеет DOM и RegExp. Оба эти инструмена позволяют обрабатывать документ, как вам больше нравится.
Только гиморно оно все....

F>Мои пять копеек по последнему пункту:
O>> А JScript умеет разбирать текст отображаемый броузером на абзацы?
F>Это сделано еще до отображения. Тегом <p>, например. А разобрать DOM в JS никто не мешает.
Мне кажеться, что ориентироваться в дереве DOM будет тяжелее, чем в таких объектах, как обзацы. К тому же придеться встраивать свой скрипт в каждую страницу, мне кажеться это может привести к проблемам.

_>>>А так — программа даже на внедрённом в код страницы JS может сделать всё с анализом документа, вопрос только в том ,кто её будет писать.
O>> А JScript умеет разбирать текст отображаемый броузером на абзацы?
LM>JavaScript умеет DOM и RegExp. Оба эти инструмена позволяют обрабатывать документ, как вам больше нравится.
LM>Только гиморно оно все....
Вот и я считаю, что гиморно. Помоему, легче работать с объектами, которые есть в VBA в ворде.

Здравствуйте, Ocenochka, Вы писали:

O>зы Извените, если вопрос слишком легкий(ламерский), но для меня он достаточно сложен.
Поиграй с фичей MS Excel "Create updatable web query". Это поможет тебе понять, чего именно тебе хочется.

O>>зы Извените, если вопрос слишком легкий(ламерский), но для меня он достаточно сложен.
S>Поиграй с фичей MS Excel "Create updatable web query". Это поможет тебе понять, чего именно тебе хочется.
В интернете указанной фразы не нашел и не знаю где такая фича в Excel'е. Причем тут вообще Excel?

Здравствуйте, Ocenochka, Вы писали:

O>>>зы Извените, если вопрос слишком легкий(ламерский), но для меня он достаточно сложен.
S>>Поиграй с фичей MS Excel "Create updatable web query". Это поможет тебе понять, чего именно тебе хочется.
O> В интернете указанной фразы не нашел и не знаю где такая фича в Excel'е. Причем тут вообще Excel?
При том, что прежде чем браться изобретать велосипед, не вредно ознакомиться с существующими. Пардон за неточную формулировку — на самом деле "Refreshable Web Query". Запусти ексель, запусти IE. Выдели кусок таблицы в браузере, сделай Copy, в Excel сделай Paste. В смарт теге он предложит создать Refreshable Web Query.
Вот такой примерно диалог можно увидеть:


В результате, если все сделано правильно, в документ будет внедрена внешняя табличка, которая умеет забирать данные из указанного места по расписанию.

S>При том, что прежде чем браться изобретать велосипед, не вредно ознакомиться с существующими. Пардон за неточную формулировку — на самом деле "Refreshable Web Query". Запусти ексель, запусти IE. Выдели кусок таблицы в браузере, сделай Copy, в Excel сделай Paste. В смарт теге он предложит создать Refreshable Web Query.
Не предложил. Втавил "а бы как" просто и все. Таблицу использовал то же Top 100.

А Вы, собственно, на чем работаете? Если в Delphi, базовым компонентом можно, естественно, выбрать TWebBrowser или Mozilla Control (более геморройно). Далее ловим события OnBeforeNavigate и OnDocumentComplete. Вообще, однажды я столкнулся с ситуацией, когда документ полностью так и не загружался, т.е. DocumentComplete не происходило. На этом скользком принципе основаны стрим-чаты (многие из них так и не отображаются в браузерах вроде Opera — из-за бесконечной загрузки документа). Программа представляла собой клиент для чата (bizarre.kiev.ua), и в ней требовалось реализовать представление поступающих потоковых ("бесконечных") данных в реальном времени в произвольном формате (в дополнение к оригинальному веб-интерфейсу) и их сохранение. Что же я сделал? Я изменил (через DOM-интерфейс компонента TWebBrowser — Document.All.Scripts[i]) оригинальный чатовский JavaScript, который перехватывал поступающие сообщения в сжатом виде и форматировал их для вывода в главный фрейм чата — скрипт этот грузился статично. Теперь скрипт стал кроме своей основной задачи инициировать фиктивную навигацию (что позволило перехватывать OnBeforeNavigate) в выделенном для этого фрейме на URL, представляющий собой модифицированное полученное скриптом сообщение. Перехватив OnBeforeNavigate, я расшифровывал поступающие потоковые сообщения из URL и сразу же направлял их в программу, после чего отменял навигацию (это позволяет обработчик OnBeforeNavigate), таким образом, никакой лишней сетевой активности не происходило.

Фактически, универсальному решению данной проблемы мешают ограничения самого браузерного движка. Скажем, полезной была бы функция определения первого в Z-порядке (видимого) непрозрачного объекта, находящегося в точке (x,y) видимой области или всей страницы. Это, ко всему прочему, позволяет обходить "защиту" некоторых сайтов вроде GooglePrint. Там изображение страницы книги перекрыто прозрачной "пустышкой", которую и сохраняет браузер, когда юзер пытается сделать это правой кнопкой мыши. Полезнейший инструмент от Microsoft — MSIE Developer Toolbar позволил мне увидеть и положение "защищенной" картинки (фон главной страницы), и ее настоящий URL, по которому я открывал изображение в отдельном окне и спокойно его сохранял.

Можно попытаться, загрузив страницу, пройтись по ее DOM-структуре и сгенерировать соответствующий javascript, реагирующий на все события вроде onclick для всех кликабельных объектов, добавить этот скрипт в загруженную страницу (она может увеличиться в размере) и таким образом превратить любой HTML-код в некое подобие AJAX. А еще лучшим решением будет полная переработка браузерного движка (например, Firefox) с заменой (или дополнением) парадигмы "Back-Forward" на "Undo-Redo", более соответствующей концепции Web 2.0. В любом случае, существующие браузеры — крайне неудобная, нестабильная и сомнительная платформа для по-настоящему полнофункциональных веб-приложений. Будь то Opera, IE или Firefox. Опера — фактически закрытое и до недавнего времени коммерческое приложение; IE — инструмент маркетинга MS. И поэтому в ближайшее время наиболее интенсивно будет развиваться как раз Firefox, вместе с компонентами типа GreaseMonkey. Firefox как платформа представляет собой веб-аналог Linux. Так вот, если в Linux-сообществе перекомпиляция ядра под специфический софт или железо (с целью оптимизации) — обычное дело, то и браузерный движок для специфических задач (а тем более для внедрения в состав другого софта) лучше пересобирать (например, если приложение должно использовать DOM и работать как браузер, но отображение страницы не требуется — убираем рендеринг и получаем "слепой" и компактный управляемый извне псевдобраузерный компонент).

Здравствуйте, Ocenochka, Вы писали:
O> Не предложил. Втавил "а бы как" просто и все. Таблицу использовал то же Top 100.
А какие опции в смарт-теге были?
Попробуй Data — Import External Data — New Web Query.

O>> Не предложил. Втавил "а бы как" просто и все. Таблицу использовал то же Top 100.
S>А какие опции в смарт-теге были?
S>Попробуй Data — Import External Data — New Web Query.
Получилось. Спасибо! Поиграюсь...

R>А Вы, собственно, на чем работаете?
На С#. Спасибо за длинное письмо, из которого я понял немного, но открыл для себя некоторые возможности работы с DOM. Работать буду с IE все равно, т.к. с Firefox'ом разбираться боязно, тем более, что я уже с IE начал.

А Вы, собственно, на чем работаете? Если в Delphi, базовым компонентом можно, естественно, выбрать TWebBrowser или Mozilla Control (более геморройно). Далее ловим события OnBeforeNavigate и OnDocumentComplete. Вообще, однажды я столкнулся с ситуацией, когда документ полностью так и не загружался, т.е. DocumentComplete не происходило. На этом скользком принципе основаны стрим-чаты (многие из них так и не отображаются в браузерах вроде Opera — из-за бесконечной загрузки документа). Программа представляла собой клиент для чата (bizarre.kiev.ua), и в ней требовалось реализовать представление поступающих потоковых ("бесконечных") данных в реальном времени в произвольном формате (в дополнение к оригинальному веб-интерфейсу) и их сохранение. Что же я сделал? Я изменил (через DOM-интерфейс компонента TWebBrowser — Document.All.Scripts[i]) оригинальный чатовский JavaScript, который перехватывал поступающие сообщения в сжатом виде и форматировал их для вывода в главный фрейм чата — скрипт этот грузился статично. Теперь скрипт стал кроме своей основной задачи инициировать фиктивную навигацию (что позволило перехватывать OnBeforeNavigate) в выделенном для этого фрейме на URL, представляющий собой модифицированное полученное скриптом сообщение. Перехватив OnBeforeNavigate, я расшифровывал поступающие потоковые сообщения из URL и сразу же направлял их в программу, после чего отменял навигацию (это позволяет обработчик OnBeforeNavigate), таким образом, никакой лишней сетевой активности не происходило.

Фактически, универсальному решению данной проблемы мешают ограничения самого браузерного движка. Скажем, полезной была бы функция определения первого в Z-порядке (видимого) непрозрачного объекта, находящегося в точке (x,y) видимой области или всей страницы. Это, ко всему прочему, позволяет обходить "защиту" некоторых сайтов вроде GooglePrint. Там изображение страницы книги перекрыто прозрачной "пустышкой", которую и сохраняет браузер, когда юзер пытается сделать это правой кнопкой мыши. Полезнейший инструмент от Microsoft — MSIE Developer Toolbar позволил мне увидеть и положение "защищенной" картинки (фон главной страницы), и ее настоящий URL, по которому я открывал изображение в отдельном окне и спокойно его сохранял.

Можно попытаться, загрузив страницу, пройтись по ее DOM-структуре и сгенерировать соответствующий javascript, реагирующий на все события вроде onclick для всех кликабельных объектов, добавить этот скрипт в загруженную страницу (она может увеличиться в размере) и таким образом превратить любой HTML-код в некое подобие AJAX. А еще лучшим решением будет полная переработка браузерного движка (например, Firefox) с заменой (или дополнением) парадигмы "Back-Forward" на "Undo-Redo", более соответствующей концепции Web 2.0. В любом случае, существующие браузеры — крайне неудобная, нестабильная и сомнительная платформа для по-настоящему полнофункциональных веб-приложений. Будь то Opera, IE или Firefox. Опера — фактически закрытое и до недавнего времени коммерческое приложение; IE — инструмент маркетинга MS. И поэтому в ближайшее время наиболее интенсивно будет развиваться как раз Firefox, вместе с компонентами типа GreaseMonkey. Firefox как платформа представляет собой веб-аналог Linux. Так вот, если в Linux-сообществе перекомпиляция ядра под специфический софт или железо (с целью оптимизации) — обычное дело, то и браузерный движок для специфических задач (а тем более для внедрения в состав другого софта) лучше пересобирать (например, если приложение должно использовать DOM и работать как браузер, но отображение страницы не требуется — убираем рендеринг и получаем "слепой" и компактный управляемый извне псевдобраузерный компонент).