Reading json data from a WPF WebBrowser Control - c#

How would I go about reading the json data returned by a web server in response to the ajax calls/polls from the html document inside my wpf web browser control? The connection between the client and server is secured.

It's possible to call C# code from Javascript and vice versa i.e. call Javascript in the page from C#. Depending on your scenario you could use either of these to return the JSON string.
See this article for more information
If you don't have control over the html page i.e. you cannot change it you might have to parse the whole page, you can get the page like this

Related

How to download infinitely-scrolling web page

With WebClient.DownloadString method it's fairly simple to load normal web page source to string.
But is there any easy way to load those pages which extends and loads new content when you scroll down to end?
You cannot "download" such a page, as it doesn't exist in full form. Such pages require user interaction.
You can use one of the forms of the WebBrowser control to browse to, and programmatically interact with a web site.
hey you can try this approach if you want to do it webclient..
See here.. basically he is using the scrapy but this approach can be adopted in case of webclient to i think so.
basically he is using the firebug or chrome developer tool in order to trace the ajax web request after knowing the web request you can get the content with webclient.

Call a C# function from a button clicked on an HTML page

My application (C#) consists of an embedded web browser which will load a page in HTML from a server. The HTML page will be created from scratch for this particular application. My intention is to have the following procedure:
A user opens the application
A web browser embedded within the application will load an HTML page
User will click a button on the HTML page
A C# function (on client side) is triggered from this action
function does some work
send a list of data back to the web page
Web page will retrieve this data and display it
user's browser will be refreshed to display the new page
Now my questions are the following:
How can a C# function on the client side be triggered when a button is clicked on a server page
What is the best way to transfer data (will probably be object)
how can a function on the HTML page wait for data to be received before continuing to execute the function?
Using the WebBrowser control, you can use the ObjectForScripting property. This will allow JavaScript to call C# code using window.external.C# MethodName
There's some quirks with the serialization you might need to work through, and you might need to use webbrowser.Document.InvokeScript to trigger your data back to JavaScript (I've not personally used the result of a window.external call so cannot speak for it).

Refresh asp.net page from a code-behind file

I have an ASP.NET website and a seperate C# application. The application writes data to a file, the website populates the treeview with the data in the file. I populate the treeview in the page Load event.
The website checks if the file has changed. This happens from a code behind file. If the file did change, the website needs to be refreshed. I cannot use Response.Redirect because I get a
Response is not available in this context
I tried System.Web.HttpContext.Current.Response.Redirect, but this gives me a NullReference.
How can I refresh the page from a code behind file, so that it loads the right data in the treeview? Other suggestions that work but use something else than refreshing the page are welcome. Thanks in advance!
Edit: The actual problem is dynamically updating the treeview (new data = updated treeview). I have tried to do something with data from a MySql database but failed. The idea is the same, except the data isn't coming from a file but from a database. I added this because I thought this info might help users understand my problem.
you can't send data to the client from an initiative of the server.
You will have to poll (jQuery/ajax) if new data is available, then refresh from the client side.
this involves basically :
on the server
a web service, webmethod page method, custom handler, etc. that can tell if new data is available
on the client
a timer that query the server if data is refreshed, and, in this case, that refresh the page, or reconstruct the DOM if using some JS templating
[Edit] a bit of background :
Actually, System.Web.HttpContext.Current.Response is null because of the asynchronous model of the Http protocol. The browser emits a request "http://srv/resource", the server intercept it on the port 80 (by default), parse the request, build a response (mostlya bunch of html content) and send the response the browser. Then the connection is closed. This choice allows a great scalability, as it does not requires to keeps thousands of connections alive with nearly no data passing on it.
The impact of this, is that the web server have to knowledge of the client, other than what is send in the request. The server receive text, and send text in return.
Microsoft has created the ASP.Net framework to reproduce the RAD feeling of desktop applications. You think with controls and events, not in producing html flow like ASP or PHP. They succeeded in the sense, that, building web apps are quite similar to desktop development.
The quite is actually what is causing you some confusion. Even if the asp.net framework encapsulate most of the plumbing (viewstate is the key) to simulate this behavior, asp.net will, at least, still be a parser for request text that produces a html text to send to the client, in one shot.
So you have to cheat. You can, as I suggested, automate the browser (using javascript) to wrap this asynchronous work into a "dynamic" application.
You can't successfully use a FileSystemWatcher from within a webpage.
The instance of the page lives just long enough to handle a single request. And after that request has been served, you can't issue a redirect. The browser will not be listening anymore.
You need to do polling from your webpage, using the date you last read that file. If the Last Modified date of that file has changed from what you remember, you will need to refresh your page.

filling web form using a windows application in C#

I have a site which get information of user in one of its pages.
every user has a card which contain his information. I want to write a windows application in Visual C# which read the card and fill web form using those data.
for this reason I have to run a browser in my windows application and run some javascript code to fill that elements in that browser.
does any one how can I run a browser and give to that specific javascript (in url after on page has been loaded) to fill the form?
There is a WebBrowser control that you can use in your windows app. As for populating the information on a web page, I would just pass the userID in QueryString to the URL of the page you create (in your WebBrowser control), and in the page add code to retrieve the user information and display it.
Here is some info on the WebBrowser control:
http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser.aspx
My guess is you would be better off handing over the data you want to see in the web forms via http post or get. Then let the serverside write the values into the propper forms.

Send HTTP Post with default browser with C#

I am wondering if it is possible to send POST data with the default browser of a computer in C#.
Here is the situation. My client would like the ability to have their C# application open their browser and send client information to a webform. This webform would be behind a login screen. The assumption from the application side is that once the client data is sent to the login screen, the login screen would pass that information onto the webform to prepopulate it. This would be done over HTTPS and the client would like this to be done with a POST and not a GET as client information would be sent as plain text.
I have found some wonderful solutions that do POSTS and handle the requests. As an example
http://geekswithblogs.net/rakker/archive/2006/04/21/76044.aspx
So the TL;DR version of this would be
1) Open Browser
2) Open some URL with POST data
Thanks for your help,
Paul
I've handled a similar situation once by generating an HTML page on the fly with a form setup with hidden values for everything. There was a bit of Javascript on the page so that when it loaded, it would submit the form, therefore posting the data as necessary.
I suspect this method would work for you.
Generate a dictionary of fields and values
Generate an HTML page with the Javascript to automatically submit when page is loaded
Write page to a temp location on disk
Launch default browser with that page
Remember though that POST data is sent plaintext as well. POST is generally the way to go for more than a couple fields, as you can fit in more data (2048 byte limit on URLs) and that your user has a friendly URL to see in their browser.
Nothing is sent as plain text when you use SSL, it is encrypted. Unless you set what the default browser is (IE, Firefox, Chrome, etc), then you'll have to figure out what the default browser is and use its API to do this work (if it's possible).
What would probably be must faster and more efficient would be to open the default browser by invoking a URL with Start Process and pass the information on the query string (this is doing a GET instead of a POST, which I know isn't what you're asking for).
The response from the server could be a redirect, and the redirect could send down the filled-out form (storing the values in session or something similar).
That way the complexity is pushed to the website and not the windows application, which should be easier to update if something goes wrong.
HTH
Can you compile your logic in C# and then call it from PowerShell? From PowerShell you can very easily automate Internet Explorer. This is IE only but you might be able to also use WaitnN.
Anything you put at the end of the URL counts as the querystring, which is what GET fills. It is more visible than the POSTed data in the body, but no more secure with regard to a sniffer.
So, in short, no.

Categories