Printable View
Hello,
I have a wierd situation. I have an application that uses the AxWebBrowser control. It reports a user agent on an XP machine runing IE 7.0 as "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
This would be correct then. But, the buttons don't have the XP visual styles enabled. :sick: ???
Is it truely using IE 7.0, or is it using only part of it and a different layout engine?
Thanks,
Christian
the webbrowser control does NOT render XP themes for HTML controls...
why, I am not sure where the limitation lies, I just know it exists and there doesn't seem to be anything you can do about it.
Thanks Kleima. Wonder what component is different?
I am not sure... I do know its fixed in 2005, that if you use the .NET 2.0 webbrowser control, and you use visualstyles, the control will inherit it for HTML rendering..
however I am currently writing a .NET 2005 app that uses a webbrowser control, and I found I had to go back and use the active X version that I used in .NET 2003 (which has the same problem with styles as if you used it in 2003), because the managed framework one is lacking in some major areas... I guess it had to be done to allow it to work 100% as part of the managed framework, but it made what I was trying to do impossible..
Actually I would be interested in hearing the limitations as I am too developing an app in 2005 that uses the web browser.
there may be more than 1, but the specific problem I had is this:
I am writing a winform app that uses the WB control to only access 1 site (its an app that brings added functionality and autofilling to a specific website that our customers use)
so anyway, certain parts of the website show popup windows, and when the popup window would pop up, the session state would be totally lost... so basically they would get a popup that would redirect back to the login screen of the website, instead of the page they were supposed to be served.
the cause is that the NewWindow event of the 2005 wb control, doesn't have any event arguments.. the 2003 one did..
the specific event arg is ppDisp, which you can use to assign to another WB control object (lets say that one is in a form called frmPopup, that handles any popups on the site)
so long story short, a popup window on a website, that relies on session state on the webserver, will not work correctly in the 2005 browser (i can't confirm that this happens in all cases, but I know its not limited to mine, as my searching for a solution turned up other people with the same issue)
the only solution that was given anywhere was to continue to use the COM webbrowser control from VB6/.NET 2003
If you look at the object model for the COM WB control, and the 2005 WB Control, you will see lots of differences.
Like I said, I am sure that it was done because the .NET 2.0 framework needed to be written in a way that it would work correctly on 98-2003 windows machines, using IE4 and up..
Instead of using sessions, could you have just used cookies?
its not my site.. my app navigates through a 3rd party website... so I have no control over how they make their site work... I am simply building the browser
basically my app collects all the data they enter on this site, because normally they have to enter it all on this site, then enter it all over again in another local system. This program was written to save them the double duty, by collecting the data as its entered, and then writing it out in the format needed for their local software to read it in and parse it...
so really, the session issue with the 2005 wb control could affect any number of sites...
in standalone IE if I run through the site, it works fine. The same is also true when I use the activeX WB control. However when I use the 2005 WB control, functionality is broken.
If you are sticking a webbrowser in a program to webbrowse sites, you have to go with the notion that it will work the same way it would as if they were using IE, and unfortunatly that just isn't the case with the 2005 WB control. I was excited to use it since it was now part of the managed framework, and was rather disappointed to see it had issues. Perhaps this will be corrected in a service pack... but I doubt it.
Lame. Bugs like that usually take an eon to figure out too.
One day they will come up with a browser that just stores variables in memory for each site. This would make things sooo much easier. Just think, no more need for sessions or storing everything in a database step by step.
One of the reasons I don't like creating web apps any longer is I have grown so accustom to this in .NET
the problem with that is.. it leaves a site open for someone to hack anything "local".. change variable values.. etc...Quote:
Originally Posted by cpatzer
keeping things server side and only serving out pages while keeping the state of the application on the server side, allows greater security measures for the web app...
however I know what you mean about web apps being a pain to work on.. most of the pain is in the differences between browsers though..
There has got to be a way to lock down the data. Knowing Microsoft though, it would probably take 50 viruses until they fixed it.