TWebbrowser и прокси.

← →
SergP © (2004-02-18 04:38) [0]

Есть в инете пример как можно работать c TWebbrowser"ом через прокси. Думаю приводить его не стоит, так как все его знают. (Заключается в юзании UrlMkSetSessionOption).

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

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

← →
nikkie © (2004-02-18 23:08) [1]

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

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

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

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

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

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

← →
SergP © (2004-02-21 11:12) [2]

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

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

← →
SergP © (2004-02-21 11:13) [3]

проблемы будут, их не может не быть.

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

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

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

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

TWebbrowser и прокси. Найти похожие ветки