Page 1 of 1

script-error windows in html pages of webBrowser

Posted: 16 Feb 2013 16:35
by dominique f pannier

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 property. ... 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
by Thomas Linder Puls
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
by dominique f pannier
Thanks Thomas,
I will investigate. :-)

Posted: 28 Feb 2013 11:46
by dominique f pannier
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

clauses     display(Parent) = Form :-         Form = new(Parent),         Form:show().   clauses     new(Parent):-         formWindow::new(Parent),         generatedInitialize().     predicates     onShow : window::showListener. clauses     onShow(_Source, _Data):-         setState([wsf_Maximized]),         URL = @"",         webBrowserControl_ctl:silent := true(),         webBrowserControl_ctl:navigate(URL).
Is is launched by the classic :

Code: Select all

_ = htmlForm::display(This)
After navigating, to close it I use :

Code: Select all

Are now appearing two exceptions.
It seems to be generated by a caculation based on pixels in the class. Is there a reason that this class takes place in that case ? :roll:

Posted: 28 Feb 2013 14:26
by dominique f pannier
Hi again,
Apparently, these exceptions appears only when the following code is added at the show event:

Code: Select all


Posted: 28 Feb 2013 15:55
by Thomas Linder Puls
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
by dominique f pannier
It seems that it only occurs in 64bit mode.
I tried to trace with the debugger the pntPixel2Unit predicate of 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
by drspro2
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
by Thomas Linder Puls
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.