Discussions related to Visual Prolog
dominique f pannier
Active Member
Posts: 40
Joined: 23 Sep 2002 23:01

script-error windows in html pages of webBrowser

Unread post by dominique f pannier »

Hi,

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.
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... ?
Regards
Dominique Pannier
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post 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.
Last edited by Thomas Linder Puls on 20 Feb 2013 8:19, edited 1 time in total.
Regards Thomas Linder Puls
PDC
dominique f pannier
Active Member
Posts: 40
Joined: 23 Sep 2002 23:01

Unread post by dominique f pannier »

Thanks Thomas,
I will investigate. :-)
Regards
Dominique Pannier
dominique f pannier
Active Member
Posts: 40
Joined: 23 Sep 2002 23:01

Unread post by dominique f pannier »

Hi,
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 = @"http://www.fnac.com/Informatique/shi48966/w-4",         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

htmlForm:close().
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 ? :roll:
Attachments
exceptionsWB.txt
(5.47 KiB) Downloaded 715 times
Regards
Dominique Pannier
dominique f pannier
Active Member
Posts: 40
Joined: 23 Sep 2002 23:01

Unread post by dominique f pannier »

Hi again,
Apparently, these exceptions appears only when the following code is added at the show event:

Code: Select all

        setState([wsf_Maximized]),
:!:
Regards
Dominique Pannier
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post 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.
Regards Thomas Linder Puls
PDC
dominique f pannier
Active Member
Posts: 40
Joined: 23 Sep 2002 23:01

Unread post by dominique f pannier »

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. :-)
Regards
Dominique Pannier
User avatar
drspro2
VIP Member
Posts: 97
Joined: 28 Apr 2006 12:03

Unread post 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?


thankyou



regards

R
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Unread post 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.
Regards Thomas Linder Puls
PDC
Post Reply