Page 1 of 1
script-error windows in html pages of webBrowser
Posted: 16 Feb 2013 16:35
When running a trivial URL with then webBrowserControl
object, it'not rare that are displayed script-error windows because of the code of the hmtl page of the target site.
In the webBrowser Properties
article, MSDN mentions the ScriptErrorSuppressed
http://msdn.microsoft.com/en-us/library ... essed.aspx
When this property is set to true :
... the WebBrowser control hides all its dialog boxes that originate from the underlying ActiveX control, not just script errors.
Can we use such a property in VIP 7.4 and if not, is there a way to disconnect the display of these script-error windows which sometimes can be abundant... ?
Posted: 17 Feb 2013 16:43
The documentation you are looking at concerns the .net version of the webBrowser control. I am quite sure that the underlying control is exactly the same, but the .net wrapping is spomewhat different than the native interface.
So I am sure that the same thing is possible in the native control, but the way it is done may be quite different.
The native webBrowser Control is described here: WebBrowser Control
, but whether the informtion you need is in that section, or should be found in a completely different place is hard to say.
Posted: 19 Feb 2013 10:53
I will investigate.
Posted: 28 Feb 2013 11:46
I found the very simple solution : like explained :
the WebBrowser control hides all its dialog boxes ...
the webbrowser property silent
fills this role.
Now, I come back upon exceptions which are regularly generated when I want to close a web page opened with the webBrowser.
My code of the form htmlForm
using the webBrowser is :
Code: Select all
display(Parent) = Form :-
Form = new(Parent),
onShow : window::showListener.
URL = @"http://www.fnac.com/Informatique/shi48966/w-4",
webBrowserControl_ctl:silent := true(),
Is is launched by the classic :
After navigating, to close it I use :
Are now appearing two exceptions.
It seems to be generated by a caculation based on pixels in the dialog.pro
class. Is there a reason that this class takes place in that case ?
Posted: 28 Feb 2013 14:26
Apparently, these exceptions appears only when the following code is added at the show
Posted: 28 Feb 2013 15:55
I cannot reproduce this problem. Does it only occur in 64bit mode?
A little side comment. Notice that maximize inside an MDI application is quite different from maximizing applications on the desktop.
Desktop: When maximizing an application on the desktop the application will fill the entire desktop, but other applications will retain their size. And "small" applications can overlap the maximized applications (maximized applications will by nature cover all other applications that are below it).
MDI app: When maximizing an MDI child window, you actually change the state of the entire application, because in that state the application will show any child window in maximized state. Using Ctrl+Tab will switch to the next MDI-child and that will also be maximized. So effectively you will change all MDI child windows to maximized state.
I do not know the reason for this difference, and it is quite counter intuitive, that you control it one MDI-child window, when it actually affect the entire application (or all child windows, depending on how you look at it).
Anyway, due to this global effect I think it is "wrong"/"bad" to change the state like you do.
Posted: 28 Feb 2013 17:12
It seems that it only occurs in 64bit mode.
I tried to trace with the debugger the pntPixel2Unit
predicate of dialog.pro
which runs the mapDialogRect
predicate apparently incriminated by the exception report, but without success : the program Under debug terminated normally. But out of debug, the exceptions occur almost each launch.
Thanks for informations on maximization. It was really a form into a MDI application which was maximized. I will use another way to obtain the result I need.
Posted: 12 Sep 2014 11:43
my ActiveX webbrowser also suddenly closes itself on certain systems and an AxtiveX error message of the underlying WIndowsOS appears, should i try the silent mode? also I use the Window SetState Maximized, maybe that is causing the problem,
I will be investigating more to find what causes the problem.
Should this ActiveX webbrowser control theoretically run on all windows systems? also when Remote desktop on windows server 2012 or higher is used?
Posted: 12 Sep 2014 12:56
All Windows computers have a webBrowser control. It's version will correspond to the Internet Explorer on the machine. It is subject to automatic Windows updates, but it will stay in sync with the installed Internet Explorer.
I believe the webBrowser control should run on all Windows systems, provided the Internet Explorer have a reasonable version.
We have however noticed that things may work differently when using remote desktop (not particular for the webBrowser control, more in generel).
It is very unlikely that a crash will not appear when using silent mode. It is also very unlikely that maximized should be the cause of the crash.
The important thing is of course the error message: always consider the error messages carefully first.