Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TWebbrowser и прокси. [D5, WinME]

SergP © (2004-02-18 04:38:00)
Есть в инете пример как можно работать c TWebbrowser'ом через прокси. Думаю приводить его не стоит, так как все его знают. (Заключается в юзании UrlMkSetSessionOption).

Так вот. Если я в своем приложении юзаю 1 TWebbrowser c таким способом работы через прокси, то все работает нормально. Более того несколько копий приложения могут работать одновременно через разные прокси.

Попробовал сделать несколько TWebbrowser в одном приложении (создаю их в ран-тайме). Хотел сделать чтобы каждый TWebbrowser конектился через отдельный прокси. И вот тут начались проблемы. Что можно сделать?

nikkie (2004-02-21 13:32:00) [1]
проблемы будут, их не может не быть.

начать с того, что DownloadBegin не перехватит все коннекты - попробуй открыть www.ya.ru в WebBrowser и сделай поиск.

далее, если страница содержит много картинок и т.п. (я попробовал на www.yandex.ru) - для каждой может потребоваться отдельный коннект. вроде DownloadBegin вызывается для каждой из них, но реальный коннект может произойти далеко не сразу после этого - видимо это связано с тем, что WinInet ограничивает количество одновременных коннектов. при одновременной навигации нескольких WebBrowser проблемы гарантированы.

ну и очевидно, что событие DownloadBegin возникает в основном потоке, а коннект происходит в дополнительном. проблемы тут не гарантированы, но скорее всего будут, причем трудноуловимые.

ты лучше расскажи откуда такая задача взялась. наверняка решение лучше найдется.

SergP (2004-02-21 11:13:00) [2]
>можно попробовать некоторый изврат - не разрешать двум WebBrowser
>скачивать одновременно. когда один из них соберется скачивать (поймать в
>OnDownloadBegin?) - вызвать UrlMkSetSessionOption. пока он скачивает
>(пока не случился OnDownloadComplete?) не давать скачивать другим
>WebBrowser. идея паршивая.

Хм.. А если просто каждый раз в OnDownloadBegin вызывать эту функцию и по Sender'у определять какой прокси устанавливать. Ведь когда браузер начал что-то качать, то вызов UrlMkSetSessionOption не должен влиять на уже идущую закачку? Т.е. получится что несколько браузеров смогут закачивать оджновременно с разных проксей...?
Или я что-то неправильно ли я понимаю?

SergP (2004-02-21 11:12:00) [3]
>можно попробовать некоторый изврат - не разрешать двум WebBrowser
>скачивать одновременно. когда один из них соберется скачивать (поймать в
>OnDownloadBegin?) - вызвать UrlMkSetSessionOption. пока он скачивает
>(пока не случился OnDownloadComplete?) не давать скачивать другим
>WebBrowser. идея паршивая.

Хм.. А если просто каждый раз в OnDownloadBegin вызывать эту функцию и по Sender'у определять какой прокси устанавливать. Ведь когда браузер начал что-то качать, то вызов UrlMkSetSessionOption не должен влиять на уже идущую закачку? Т.е. получится что несколько браузеров смогут закачивать оджновременно с разных проксей...?
Или я что-то неправильно ли я понимаю?

nikkie (2004-02-18 23:08:00) [4]
имхо, использование UrlMkSetSessionOption - некоторая хитрость, основанная на том, что MSHTML использует WinInet функции для скачивания веб-контента. согласись, что WebBrowser и UrlMkSetSessionOption - разного поля ягоды. но поскольку вряд ли стоит ожидать, что микрософт изменит эту архитектуру, то метод такой имеет право на существование.

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

можно попробовать некоторый изврат - не разрешать двум WebBrowser скачивать одновременно. когда один из них соберется скачивать (поймать в OnDownloadBegin?) - вызвать UrlMkSetSessionOption. пока он скачивает (пока не случился OnDownloadComplete?) не давать скачивать другим WebBrowser. идея паршивая.

есть иной способ указать прокси WebBrowser-у. у EmbeddedWB есть событие OnGetOptionKeyPath - там можно указать путь в реестре откуда WebBrowser будет брать и куда записывать параметры, в том числе и прокси.

для твоей задачи тоже самый фонтан - придется на каждый WebBrowser заводить отдельную ветку в реестре. либо извратиться еще больше и перехватывать API обращения к реестру.

имхо, надо лучше подумать, зачем это все надо. возможно, проще обойтись вообще без WebBrowser.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »