 |
|
|
I need a particular browser!
I want to change some predefined tags in html source and only my
browser can do this.
In DocumentCompleted event handler, I changed the html
source and all things worked well.
The problem is that, in certain situations when a page contains html
editor (java script) and those predefined tags, DocumentCompleteEx
fires infinitely or html editor doesn't work.
What a problem might be there? Is there any solution for this?
Any help would be much appreciated. Thanks.
davood mahvaar
|
|
|
|
|
|
|
|
|
|
Maybe this is a fairly common problem, but I have not
seen any info that directly addressed it. Here is what is
happening:
We have a dialog based application that
uses the webbrowsercontrol to access various web
applications (Java). Some of these
applications maintain session state using session
variables. And, they sometimes open new windows when
clicking links. When new windows are opened, the session
variables appear to be lost for them. I have set the
RegisterAsBrowser property to true for the top parent
browser control, but it does not seem to fix the problem....
|
|
|
|
|
|
|
Hi rootdial,
This is due to the fact that you are persisting the session variables in cookies and cookies are scoped to the client Windows process.
When the page calls window.open, a new Internet Explorer window is created but in another process.
The workaround is using window.showModalDialog or window.showModelessDialog in the pages or opening the new window in your application (take a loog on how the sample application does this).
|
|
|
|
|
|
|
Hi Paulo,
Great article, and an excellent wrapping job of the axWebBrowser. Due to some limitations I've found in the 2.0 WebBrowser Control (which MSFT is reluctant to fix), I've found your wrap a good browser alternative even when using .NET 2.0.
One question for you though - any ideas why your browser example would crash when linking to the main featured links in www.yahoo.com?
Thanks,
Barry
-- modified at 23:07 Saturday 2nd June, 2007
|
|
|
|
|
|
|
I just recently detected a problem with named targets and I'm trying to solve it. I'll post the solution as soon as I get it.
But, If you are looking for a 2.0 solution, this[^] is a better solution.
|
|
|
|
|
|
|
Thanks Paulo,
I checked into the other solution (which is an extremely impressive wrap of the full browser fucntionality as well as the removal of the mshtml interop), but I have a slight, yet important (to me, anyway) 'nit' that has me preferring your 1.1 wrapping solution, built in 2.0, over the other.
This same problem is also found in Microsoft's WebBrowser 2.0 control, and while MSFT confirms its a problem, it appears that they're avoiding a fix to it, since the fix could be complex and dangerous to other functionality.
Here's how to produce the issue:
1. Go to maps.yahoo.com (specifically the newer flash version of the site - if it comes up with the older HTML version, make sure you have Flash installed, go back to it, and you'll see the newer version).
2. When the map comes up, click in the map area, then try to navigate this with the arrow keys on the keyboard.
- In normal IE - this works perfectly
- In your browser wrap, even rebuilt in 2.0 - this works perfectly
- In csExWB - it works when you first use the arrow key, and then on subsequent key strokes, the keystrokes are passed to an area outside the browser. I'll bring it up in their forum.
- In System.Windows.Forms.WebBrowser (2.0) - even with a workaround that's been popular with the click events, this arrow key problem stops everything.
This keyboard problem seems to happen with all custom C++ ActiveX controls using listboxes and drop-down boxes.
If you can find a solution to that named targets problem, then I no longer see any problem with your control, except for maybe the weaker "external" functionality that csWbEx provides, as you said. But the control being fully functional is more important to me than the wrapper...
Thanks again for your article and your help,
Barry
|
|
|
|
|
|
|
Are you having this problem with IE6, IE7 or both?
|
|
|
|
|
|
|
I've confirmed this same exact behavior with all examples in
- Windows 2000 - IE6
and
- Windows XP Pro - IE7
Your solution works fine for this issue in both environments.
Barry
|
|
|
|
|
|
|
And the crashing? Does it happen in both environments?
|
|
|
|
|
|
|
After some testing - The crashing doesn't happen in the XP IE7 environment, but happens on two different Win2K/IE6 environments. It might be an IE6 thing, but I don't have an XP/IE6 environment to test against.
Based on that, your fixing of this is really very optional (in my opinion). If you have any ideas that could help it work in Win2K/IE6 that are specifically used in Yahoo versus other sites (I've tried many with no problems), I'd appreciate it...
Thanks again,
Barry
|
|
|
|
|
|
|
My problem is with WinXP/IE6.
Since it's an enterprise environment, I don't know how much time I can dedicate to this before a decision to upgrade to IE7 is issued.
Nevertheless, I'll post her how it's going.
|
|
|
|
|
|
|
I hear you - my enterprise probably won't upgrade to Vista or XP till next year, and if XP is chosen (due to the hardward expense in Vista), then the IE7 upgrade may not happen immediately.
At least the problem could be narrowed to IE6... (as you may know, Win2K doesn't have an IE7 option) If you make a fix for this, I'll be happy to help test it.
|
|
|
|
|
|
|
Barry,
I think we had a breakthrough.
Try removing the calls to:
((System.ComponentModel.ISupportInitialize)(this.webBrowserControlBase)).BeginInit();
and:
((System.ComponentModel.ISupportInitialize)(this.webBrowserControlBase)).EndInit();
I’ll post the new sources as soon as I have a final solution.
|
|
|
|
|
|
|
Hi Paulo,
Actually, those lines (related to webBrowserControlBase) didn't fix my issue, but the BeginInit/EndInit lines related to the full control itself did!
In your WebBrowserForm.cs file, here's where I commented out:
((System.ComponentModel.ISupportInitialize)(this.webBrowserControl)).BeginInit();
and
((System.ComponentModel.ISupportInitialize)(this.webBrowserControl)).EndInit();
Are you seeing something different? Either way, great find!
Thanks,
Barry
|
|
|
|
|
|
|
I have the following solution by now:
Set a message hook for the current thread:
SetWindowsHookEx(WH_CALLWNDPROCRET, cbf, IntPtr.Zero, GetCurrentThreadId()) and monitor WM_INITDIALOG message. When it is intercepted, we can get the dialog’s hwnd and respectively close/manage the one.
But there is some problem here: we need to determine if the newly created dialog was originated by WebBrowser control, not by our own code.
Currently I see only 2 ways (both are not elegant) to do it:
1) Place WebBrowser control solely to a windows form specially intended for it. So when WM_INITDIALOG is intercepted, we can trace its owner by GetWindow(HD.ToInt32(), GW_OWNER). Naturally, if owner is the same where WebBrowser is located, then this dialog was originated by it.
2) Trace the caption text of the dialog for some predefined pattern in order to define if it is our dialog.
Does anybody know a more straight way to find out if a window was originated by a certain control?
Sergey Stoyan
|
|
|
|
|
|
|
Hi,
Your control works gracefully!
Could you advice: I tried to intercept a confirmation dialog message box and subscribed on webBrowserControl.ShowMessage event to do it but could not receive this event... What a problem might be there?
Thanks,
Sergey
|
|
|
|
|
|
|
This control has a few design and debug time problems?
Have you tried a release build or starting without debugging?
Can you show your code?
|
|
|
|
|
|
|
No problem with the code. I converted your code to .NET2. Also I tried it in debug mode.
But I found out the problem has another reason. -
I tried to intercept Download File dialog box, while IDocHostShowUI::ShowMessage does not hook it as some guys in internet say. It can intercept only alerts and helps from java script 
My aim is to suppress (else manage) any dialog boxes originated by WebBrowser. I think hooking by SetWindowsHookEx should solve it. But maybe there is a more graceful way? Via subclassing somehow?
Sergey
|
|
|
|
|
|
|
Yes, IDocHostShowUI::ShowMessage is just for window.alert() and window.cofirm().
If you are trying to cancel the download, you can use the FileDownloading event (DWebBrowserEvents2::FileDownload).
Let me know if you find how to do it. I'm also looking for a way to catch window.showModalDialog and window.showModelessDialog.
I tried to extend the WebBrowser control in System.Windows.Forms 2.0 but Microsoft mad it impossible to do so. I'll have to redo everything they did and provide, at least, the same features of this one.
Stay tunned in:
WebBrowserControl[^]
|
|
|
|
|
|
|
I try to manage any dialogs, not only file download.
What people say:
Set Silent property (IWebBrowser2::put_Silent) to true.
Handle NewWindow2 event, cancel all attempts to create a new window.
Same with FileDownload event, to cancel File Download dialog box
Implement IDocHostShowUI - this will take care of scipts calling
alert(), confirm() and so on.
This still leaves dialog boxes created with showModalDialog and
showModelessDialog, and VBScript's InputBox function. I don't know a
good way of suppressing these.
(Igor Tandetnik)
So it seems a strict solution should be low level, not depending on WebBrowser exactly. I hope to find out what window of WB receives message from the newly opened dialog and intercept its hwd via IMessageFilter. Then I can manage it as I need. If it will be impossible, I think to use a hook to do it.
If I'll get a good solution I'll post it here.
Sergey Stoyan
|
|
|
|
|
|
|
I'm tempted to say that, if Igor Tandetnik doesn't know how to do it, it can't be done.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin