I'll buy you a latte....

G

Guest

hmm ...


That Link Cor provided looks verry promissing ,,, if you can throw a listbox
, puzzle on a webform and display this on a web page.

why would a webbrowser control fail ?? ...

i have just tested the example ( Rich.exe downloadable from the link Cor
provided ) and installed the files to my IIS directory after calling the
file controls.html it just shows the 2 listboxes without displaying anny
warning at all

so i tested this from a remote client ( other computer on my LAN ) and again
it shows the listboxes without anny warning at all

i understood from the docu that this is functioning because it runs in an
isolated storage .

so i guess this is your solution , just throw a webbrowser control on the
parent control and you have forfilled your task ( the example is C# but it
is verry simple and with the link information it should be an easy task )

Seems like your boss is not such an idiot as some people thought :)


hth

Michel







Michel Posseth said:
After reading the hole post the following

1. the security popups would also occur with a custom VB6 activex control
you even needed to sign the cab files to show a popup with green markers
then it still required the explicit confirmation of the user ( this was
already so with IE 4 )

2. the security in IE has only gone stricter ,

3. have you considered builing a smart application if i read your last post
and understaqnd your requirments correctly , a .Net smart application would
be a perfect substitute

# Concept #

http://en.wikipedia.org/wiki/Smart_client

user navigates to youw web / intranet page with a through explanation what
wil happen , clicks the install link , the framework will install all
necesary components automaticly and will launch the application, the
application is actually delivered to the client throuh IE



Hope to have given you some ideas

regards

Michel


jim said:
Registered User said:
There is an activex control for Firefox that could be used, but my boss
specifically wants an IE activeX control hosted on a webpage that will be
viewed with IE.

This example of nesting controls seems to amuse him, and no matter how I
argue that I can have another activex control on a web page rather quickly
he still wants his IE activex control on a webpage to view it in IE.

What is meant by "his ActiveX control"?

Just a figure of speech. It's the shdocvw.dll control that ships with IE
that he wants implemented in a webpage.
By itself the AxSHDocVw.AxWebBrowser control isn't especially useful.
The control needs a container that can expose a UI and
programmatically interact with the control's properties, methods and
events. Essentially this would be an ActiveX web browser control which
contains an embedded AxSHDocVw.AxWebBrowser control. Now embed the
container in the webpage.

That's a thought. Although (through much bitching an gnashing of teeth) I
have found that he wanted to use the IE control because it would not have to
be registered or installed on most Windows PCs (depending on how updated the
user's PC is of course).

As far as interacting with the webcontrol in the webpage, Peter Bromberg [C#
MVP] said "the native COM IE Web Control was never designed to be hosted in
a web page via the <object clsid=.... tag arrangement. You would not be able
to sink any events and that's just for starters. Check here for details:
http://support.microsoft.com/kb/q183048/".

So, this whole thing may be futile. I really don't understand the thinking
behind making the webbrowser control events and procedures NOT accessible
from within a webpage. If Microsoft is known for anything, it's recursion.
Just look at most of the objects in VB6 and VB.Net. They are almost all
recursed in one way or another.

The link Peter gave was for the IE4 webbrowser control. I had really hoped
that had changed by IE7, but Peter also gave a code sample in a second post
that I tested out and I got an error message in IE7 (fully patched) that
said "Internet Explorer has blocked thsi site from using an ActiveX control
in an unsafe manner. As a result, this page may not display correctly."
This message and behavior is a result of new security measures in IE7.

That alone will doom this task as we cannot really expect all users to lower
their security settings (or even know how to) just to run this "educational
webpage".

So, I have a couple of lattes to hand out. 2 to Peter and 1 to you for your
help also. Where is the nearest Starbucks? I'll phone in your orders.
Although I have done a lot of embedded IE in Java, Delphi, & C# I have
never considered embedding a browser in a webpage. As such my
suggestion is just a thought experiment that you might consider
pursuing.

Thank you for your suggestion. I also recommended an entirely different
path. I recommended wrapping an IE application using Thinstall. That would
also get rid of any requirements to install anything on the end user's PC.
The end users would have to run the executable (just over 2.2MB) but there
is no install or registering of components (even 3rd party components)
required.

Seems the objection to Thinstall is two-fold. (1) Price. Thinstall starts
at $4,995 PER APPLICATION and before client licensing is considered. (2)
Thinstall apps require lots more bandwidth than simply embedding a control
that is already on most Windows PCs.

I keep poking him for the real reason behind holding so steadfastly to a
difficult solution to a simple problem of teaching about activex controls,
but he's not cracking yet. It *has* to be something more than he's telling
me.

Thanks for your suggestions!

jim
 
J

jim

The more I poke at the shriveled grey mass he affectionately calls his
brain, the more specific he seems to get (which is expected of all end
users/project managers I suppose).

One of his (unspoken) goals was to be able to load this page without and
installs (hence the use of the IE control) and avoid any problems with PCs
that are locked down and may not allow the end users that are viewing the
educational material the ability to install anything locally.

I have looked at the link that you provided (thanks for that) and I have
googled some results for .net smart client.

It seems that the major hold up in using a smart client for this project is
the requirement for .Net 2.0 to be pre-installed on the clients. As we will
not have access to the PCs to make those changes for all that may view the
web pages, we cannot make sure that this is the case. Additionaly, any user
that wants to use click once apps and tries to install the .Net 2.0
framework must have admin privileges and we were trying to keep this in the
browser to avoid installation issues like that.

Your suggestion was a good avenue to pursue and brings up a couple of
thoughts that I had on the subject of click once deplyoment.

1) It is quite obvious that the .Net framework is a key component of
Microsoft's future plans for the Windows operating systems and applications
written for them. So, why is the .Net framework an elective download? Why
not push out such an important component of the overall Windows platform?
Just doesn't make sense to me.

2) Why are click once apps' security settings dependent upon the location
from which they are launched? Wouldn't it be better to alert a user that a
particular app (no matter where it is launched from) is requesting (or
requiring) specific permissions (like read/write access to program
directories or the ability to edit the registry) and let the user make the
call to (a) allow only certain behaviors, (b) trust the application or (c)
trust the location and all apps lainched from it? I certainly think it
would make click once deployment a more viable alternative for truly
powerful desktop applications.

3) Thinstall is an application that can wrap your application into a single
executable. It encapsulates all of the .Net framework needed to run your
app - so the user does not have to have .Net installed. It also
incorporates all COM components and DLLs into the EXE and requires NO
REGISTRATION of these components to work. Thinstall even runs your app in a
virtual sandbox and can obfuscate the whole thing for you. I can't, for the
life of me, figure out why Microsoft has not incorporated this technology
into the build and deployment cycle of .Net applications.

Thanks again for your input. I love the idea of click once deployment, but
with competing technologies like Thinstall out there - click once is years
behind in application deployment technology.

jim

Michel Posseth said:
After reading the hole post the following

1. the security popups would also occur with a custom VB6 activex control
you even needed to sign the cab files to show a popup with green
markers
then it still required the explicit confirmation of the user ( this was
already so with IE 4 )

2. the security in IE has only gone stricter ,

3. have you considered builing a smart application if i read your last
post
and understaqnd your requirments correctly , a .Net smart application
would
be a perfect substitute

# Concept #

http://en.wikipedia.org/wiki/Smart_client

user navigates to youw web / intranet page with a through explanation
what
wil happen , clicks the install link , the framework will install all
necesary components automaticly and will launch the application, the
application is actually delivered to the client throuh IE



Hope to have given you some ideas

regards

Michel


jim said:
Registered User said:
There is an activex control for Firefox that could be used, but my boss
specifically wants an IE activeX control hosted on a webpage that will
be
viewed with IE.

This example of nesting controls seems to amuse him, and no matter how
I
argue that I can have another activex control on a web page rather
quickly
he still wants his IE activex control on a webpage to view it in IE.

What is meant by "his ActiveX control"?

Just a figure of speech. It's the shdocvw.dll control that ships with IE
that he wants implemented in a webpage.
By itself the AxSHDocVw.AxWebBrowser control isn't especially useful.
The control needs a container that can expose a UI and
programmatically interact with the control's properties, methods and
events. Essentially this would be an ActiveX web browser control which
contains an embedded AxSHDocVw.AxWebBrowser control. Now embed the
container in the webpage.

That's a thought. Although (through much bitching an gnashing of teeth)
I
have found that he wanted to use the IE control because it would not have
to
be registered or installed on most Windows PCs (depending on how updated
the
user's PC is of course).

As far as interacting with the webcontrol in the webpage, Peter Bromberg
[C#
MVP] said "the native COM IE Web Control was never designed to be hosted
in
a web page via the <object clsid=.... tag arrangement. You would not be
able
to sink any events and that's just for starters. Check here for details:
http://support.microsoft.com/kb/q183048/".

So, this whole thing may be futile. I really don't understand the
thinking
behind making the webbrowser control events and procedures NOT accessible
from within a webpage. If Microsoft is known for anything, it's
recursion.
Just look at most of the objects in VB6 and VB.Net. They are almost all
recursed in one way or another.

The link Peter gave was for the IE4 webbrowser control. I had really
hoped
that had changed by IE7, but Peter also gave a code sample in a second
post
that I tested out and I got an error message in IE7 (fully patched) that
said "Internet Explorer has blocked thsi site from using an ActiveX
control
in an unsafe manner. As a result, this page may not display correctly."
This message and behavior is a result of new security measures in IE7.

That alone will doom this task as we cannot really expect all users to
lower
their security settings (or even know how to) just to run this
"educational
webpage".

So, I have a couple of lattes to hand out. 2 to Peter and 1 to you for
your
help also. Where is the nearest Starbucks? I'll phone in your orders.
Although I have done a lot of embedded IE in Java, Delphi, & C# I have
never considered embedding a browser in a webpage. As such my
suggestion is just a thought experiment that you might consider
pursuing.

Thank you for your suggestion. I also recommended an entirely different
path. I recommended wrapping an IE application using Thinstall. That
would
also get rid of any requirements to install anything on the end user's
PC.
The end users would have to run the executable (just over 2.2MB) but
there
is no install or registering of components (even 3rd party components)
required.

Seems the objection to Thinstall is two-fold. (1) Price. Thinstall
starts
at $4,995 PER APPLICATION and before client licensing is considered. (2)
Thinstall apps require lots more bandwidth than simply embedding a
control
that is already on most Windows PCs.

I keep poking him for the real reason behind holding so steadfastly to a
difficult solution to a simple problem of teaching about activex
controls,
but he's not cracking yet. It *has* to be something more than he's
telling
me.

Thanks for your suggestions!

jim
 
J

jim

Got to get a couple of hours sleep - I will look at this more in depth
tomorrow.

Thanks for the link!

jim
 
G

Guest

See inline comments

jim said:
The more I poke at the shriveled grey mass he affectionately calls his
brain, the more specific he seems to get (which is expected of all end
users/project managers I suppose).

One of his (unspoken) goals was to be able to load this page without and
installs (hence the use of the IE control) and avoid any problems with PCs
that are locked down and may not allow the end users that are viewing the
educational material the ability to install anything locally.
* see bottom
I have looked at the link that you provided (thanks for that) and I have
googled some results for .net smart client.

It seems that the major hold up in using a smart client for this project is
the requirement for .Net 2.0 to be pre-installed on the clients. As we will
not have access to the PCs to make those changes for all that may view the
web pages, we cannot make sure that this is the case. Additionaly, any user
that wants to use click once apps and tries to install the .Net 2.0
framework must have admin privileges and we were trying to keep this in the
browser to avoid installation issues like that.

Your suggestion was a good avenue to pursue and brings up a couple of
thoughts that I had on the subject of click once deplyoment.

1) It is quite obvious that the .Net framework is a key component of
Microsoft's future plans for the Windows operating systems and applications
written for them. So, why is the .Net framework an elective download? Why
not push out such an important component of the overall Windows platform?
Just doesn't make sense to me.

Actually it was for a verry short time not an optional download , the push
was not apreciated by corporate admins , and that is the reasson why it is
how it is right now :-(


2) Why are click once apps' security settings dependent upon the location
from which they are launched? Wouldn't it be better to alert a user that a
particular app (no matter where it is launched from) is requesting (or
requiring) specific permissions (like read/write access to program
directories or the ability to edit the registry) and let the user make the
call to (a) allow only certain behaviors, (b) trust the application or (c)
trust the location and all apps lainched from it? I certainly think it
would make click once deployment a more viable alternative for truly
powerful desktop applications.

Again this was AFAIK a request from the techy`s ( corporate administrators
etc ) all this can be done however it must be set explicitly i guess MS
doesn`t want to take anny risks in terms of vulnerability ( claims towards
them as they had in the activex time )
3) Thinstall is an application that can wrap your application into a single
executable. It encapsulates all of the .Net framework needed to run your
app - so the user does not have to have .Net installed. It also
incorporates all COM components and DLLs into the EXE and requires NO
REGISTRATION of these components to work. Thinstall even runs your app in a
virtual sandbox and can obfuscate the whole thing for you. I can't, for the
life of me, figure out why Microsoft has not incorporated this technology
into the build and deployment cycle of .Net applications.
Sounds great , however it is 1 pretty expensive and 2 doesn`t sound verry
safe
Thanks again for your input. I love the idea of click once deployment, but
with competing technologies like Thinstall out there - click once is years
behind in application deployment technology.
hmm well i use click once for a lot of my apps however i currently work for
a energy company where we have a managed network so i actually know that all
computers have the .Net farmework installed

* have you seen my post where i told i tested the code from the link that
Cor provided ( return of the rich client ) ?

this also works with a sandbox ( isolated storage ) and did work flawlessly
and without anny installation routines on my systems , and best of all it
is easy to acomplish and is free


regards
Michel
jim

Michel Posseth said:
After reading the hole post the following

1. the security popups would also occur with a custom VB6 activex control
you even needed to sign the cab files to show a popup with green
markers
then it still required the explicit confirmation of the user ( this was
already so with IE 4 )

2. the security in IE has only gone stricter ,

3. have you considered builing a smart application if i read your last
post
and understaqnd your requirments correctly , a .Net smart application
would
be a perfect substitute

# Concept #

http://en.wikipedia.org/wiki/Smart_client

user navigates to youw web / intranet page with a through explanation
what
wil happen , clicks the install link , the framework will install all
necesary components automaticly and will launch the application, the
application is actually delivered to the client throuh IE



Hope to have given you some ideas

regards

Michel


jim said:
There is an activex control for Firefox that could be used, but my boss
specifically wants an IE activeX control hosted on a webpage that will
be
viewed with IE.

This example of nesting controls seems to amuse him, and no matter how
I
argue that I can have another activex control on a web page rather
quickly
he still wants his IE activex control on a webpage to view it in IE.

What is meant by "his ActiveX control"?

Just a figure of speech. It's the shdocvw.dll control that ships with IE
that he wants implemented in a webpage.


By itself the AxSHDocVw.AxWebBrowser control isn't especially useful.
The control needs a container that can expose a UI and
programmatically interact with the control's properties, methods and
events. Essentially this would be an ActiveX web browser control which
contains an embedded AxSHDocVw.AxWebBrowser control. Now embed the
container in the webpage.

That's a thought. Although (through much bitching an gnashing of teeth)
I
have found that he wanted to use the IE control because it would not have
to
be registered or installed on most Windows PCs (depending on how updated
the
user's PC is of course).

As far as interacting with the webcontrol in the webpage, Peter Bromberg
[C#
MVP] said "the native COM IE Web Control was never designed to be hosted
in
a web page via the <object clsid=.... tag arrangement. You would not be
able
to sink any events and that's just for starters. Check here for details:
http://support.microsoft.com/kb/q183048/".

So, this whole thing may be futile. I really don't understand the
thinking
behind making the webbrowser control events and procedures NOT accessible
from within a webpage. If Microsoft is known for anything, it's
recursion.
Just look at most of the objects in VB6 and VB.Net. They are almost all
recursed in one way or another.

The link Peter gave was for the IE4 webbrowser control. I had really
hoped
that had changed by IE7, but Peter also gave a code sample in a second
post
that I tested out and I got an error message in IE7 (fully patched) that
said "Internet Explorer has blocked thsi site from using an ActiveX
control
in an unsafe manner. As a result, this page may not display correctly."
This message and behavior is a result of new security measures in IE7.

That alone will doom this task as we cannot really expect all users to
lower
their security settings (or even know how to) just to run this
"educational
webpage".

So, I have a couple of lattes to hand out. 2 to Peter and 1 to you for
your
help also. Where is the nearest Starbucks? I'll phone in your orders.


Although I have done a lot of embedded IE in Java, Delphi, & C# I have
never considered embedding a browser in a webpage. As such my
suggestion is just a thought experiment that you might consider
pursuing.

Thank you for your suggestion. I also recommended an entirely different
path. I recommended wrapping an IE application using Thinstall. That
would
also get rid of any requirements to install anything on the end user's
PC.
The end users would have to run the executable (just over 2.2MB) but
there
is no install or registering of components (even 3rd party components)
required.

Seems the objection to Thinstall is two-fold. (1) Price. Thinstall
starts
at $4,995 PER APPLICATION and before client licensing is considered. (2)
Thinstall apps require lots more bandwidth than simply embedding a
control
that is already on most Windows PCs.

I keep poking him for the real reason behind holding so steadfastly to a
difficult solution to a simple problem of teaching about activex
controls,
but he's not cracking yet. It *has* to be something more than he's
telling
me.

Thanks for your suggestions!

jim
 
J

jim

Thanks to everyone for their posts and help. I really appreciate it.

The fact of the matter is that this was doomed from the beginning. You
simply cannot use a webbrowser control on a webpage in the same manner that
you can on a webpage. Due to IE security restrictions, and the fact that
Microsoft never wrote the webbrowser control to be used in this manner, you
cannot access the properties or events or methods needed to pull this
project off.

Working on this project actually did give me an idea for some brain building
software that "some people" sould really use.

Thanks again!

jim
 
J

jim

jim said:
Thanks to everyone for their posts and help. I really appreciate it.

The fact of the matter is that this was doomed from the beginning. You
simply cannot use a webbrowser control on a webpage in the same manner
that you can on a webpage. Due to IE security restrictions, and the fact
that Microsoft never wrote the webbrowser control to be used in this
manner, you cannot access the properties or events or methods needed to
pull this project off.

Working on this project actually did give me an idea for some brain
building software that "some people" sould really use.

Thanks again!

jim

Oops! That should read "You simply cannot use a webbrowser control on a
webpage in the same manner that you can on a Windows Form."

Wow - their thinking (of lack of same) may be wearing off on me. I think I
need a vacation.

jim
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top