My VB.NET code is supposed to execute third party Javascript code in an attempt to fill in and submit a form. This process consists of five steps, and I have been able to submit the form when all the steps are kept separate (i.e. behind 5 separate consecutive button clicks). Now, what I'd like to have is one button to handle all the five steps.
The problem is that the form originally only appears after calling "webbrowser.Navigate" command, which apparently modifies the page's HTML code. I seem to be unable to detect when Javascript has finished loading the new HTML in order to fill and submit the form. I have tried a timer control to wait for a certain HTML element ID to appear, but in vain.
This question has been asked before in different forms, but at least I could not find much help from the earlier answers:
InvalidCastException with WebBrowser.IsBusy or ReadyState (VB .NET)
Detect when AJAX changes HTML in a DIV in WebBrowser
http://www.techtalkz.com/vb-net/374234-vb-net-webbrowser-control-how-capture-javascript-events-statusbar-changed-mouseclick-etc.html
Please help me.
Well, this is the way it normally works in the software industry: Only after you've explained the problem to others, are you in a position to sufficiently understand it - and solve it yourself.
The problem was that I had not been using System.Windows.Forms.Timer() but another (less suitable) timer class for tracking changes in the HTML code. This was the reason why Application.DoEvents() did not work. With System.Windows.Forms.Timer() I was able to create a Timer.Tick event that keeps track of the phase of the form submittal (1-5 in my example) and attempts to execute the required Javascript commands in a Try-Catch construction. If an exception is caught, Application.DoEvents() is executed instead, and the timer ensures that the same commands are attempted to be executed shortly again.
This seems to work for me.
Related
I have a WinForms app that uses a .NET webbrowser control. What I need to do, is wire up an event on the WinForms side to fire when a value is set (via javascript) in the loaded HTML page. I had success doing this with an onclick event of a button, but I can't seem to get it to work with a custom event. I don't know if this is a limitation in what the browser control can attach to event wise.
So essentially, I need that when a JS function is called in the HTML page and sets a value of a hidden input element (or it could be a regular input that I style to be hidden), I need to know that in WinForms. If it helps, I am using browser flags in this application to emulate IE11 instead of the default IE9 engine. The HTML page loaded is also mine so I can modify it any way needed to make this work properly. I would just use the onclick events of the buttons, but this is a gmaps integration where there can be upwards of 2000 buttons generated (one per marker placed) so it seems like a huge waste of resources to wire up 2000 onclick events when any of those button clicks only modify 4 input fields with the data I care about.
This project happens to be in VB.NET, but C# solutions would be fine as well. They can be transcoded or if the solution uses C# specific features, we can move this to a separate DLL and reference it.
After spending a lot of time on this today, I found a solution. It isn't a direct solution to the problem I posted, but it got me to where I needed to be. I am still interested in an answer to the original problem if anyone has one, but for now, what I found I could do was to create a class in .NET that I could assign to the ScriptingObject of the browser control and then call window.external.myFunctionName, where myFunctionName is a function within the .NET class. This works great for my specific problem, but would not work if I didn't also control the HTML page I was consuming with the browser. That is why I am still interested in alternate solutions if anyone has one. Thanks.
First of all, apologies if this question was answered before.
I'm writing a code in JS to read an Excel File, get the value of the first cell in the column, search for it (it's an ISBN code, which I'm searching with the Google Books API) and get other relevant info, made available through the search (like Title, Subtitle and Author), then proceed to the next line and repeat the process.
My problem is writing the new data back in the Excel File. The code is writing all info in the last used row in the file. While using window.alert to flag the code, I noticed that when the alert was in a for loop, right before the search was initiated, the new data was inserted just fine, but if I tried to use a pause (like a timer function or a while loop to consume time) it didn't help at all.
What I want to know is why that behavior might be happening and, if possible, of course, a possible solution for my problem, since having to use alert as a pause isn't exactly the most interesting solution.
Thanks in advance
Alert will always stop all execution of code, except for web workers. Therefore, If you need to continue execution, use a web worker. Have a look at this for reference (the note part covers this topic partially)
When browsers show a native modal interaction widget, such as an alert, it transitions into a state that waits for the response. In this state, it is allowed to redraw the page and process certain low level events. Here's the code from Mozilla Firefox that alert() and confirm() use:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/prompts/src/nsPrompter.js#434
This openRemotePrompt function doesn't return until the user clicks "OK" on the alert. However browser behaves differently while the alert is open. A loop repeatedly calls thread.processNextEvent to do certain kinds of work until the dialog is closed. (It doesn't run the application's JavaScript code, since that's meant to be single-threaded.)
When you use a pure JavaScript busy wait, for example, by looping until a certain wall time, the browser doesn't take these measures to keep things moving. Most noticeably, the UI won't redraw while the JavaScript code is looping.
Almost all web pages that I see designed to set the focus to an input box add the code into a body onload event. This causes the code to execute once the entire html document has loaded. In theory, this seems like good practice.
However, in my experience, what this usually causes is double work on the user, as they have already entered data into two or three fields and are typing into another when their cursor is jumped back without their knowledge. I've seen a staggering number of users type the last 2/3 of their password into the beginning of a username field. As such, I've always placed the JS focus code immediately after the input to insure there is no delay.
My question is: Is there any technical reason not to place this focus code inline? Is there an advantage to calling it at the end of the page, or within an onload event? I'm curious why it has become common practice considering the obvious practical drawbacks.
A couple thoughts:
I would use a framework like jQuery and have this type of code run on $(document).ready(.... window.onload doesn't run until everything on the page is fully loaded, which explains the delay you have experienced. $(document).ready(... runs when jQuery determines the DOM has been loaded. You could probably write the same sort of logic without jQuery, but it varies by browser.
I prefer to keep my Javascript separate from my HTML because it allows for a cleaner separation of concerns. Then your behavior is then kept separate from your document structure which is separate from your presentation in your CSS. This also allows you to more easily re-use logic and maintain that code — possibly across projects.
Google and Yahoo both suggest placing scripts at the bottom of the html page for performance reasons.
The Yahoo article: http://developer.yahoo.com/performance/rules.html#js_bottom
You should definitely place the script in the appropriate place if it means the correct user experience -- in fact I would load that part of the script (Used for tabbing inputs) before the inputs to ensure it always works no matter how slow the connection.
The "document.ready" function allows you to ensure the elements you want to reference are in the dom and fires right when your whole document dom is loaded (This does not mean images are fully loaded).
If you want you could have the inputs start out as disabled and then reenable them on document ready. This would handle the rare case the script is not ready yet when the inputs are displayed.
Well if you call it before whole page has loaded you really don't know if the element already has been loaded when you make your call. And if you make your call in pre-hand you should check if the element really exists even if you know it always should.
Then to make the call inline, which might seem ideal. But on the other hand it's really bad if a page takes that long to load that you can make several inputs during the loading phase.
Also you could check if input has been made etc.
Also it is possible to check if any input on page contains focus if($("input::focus, textarea::focus").length)... and otherwise set focus on desired input.
Use the autofocus HTML attribute to specify which element should initially receive focus. This decouples JavaScript and gracefully degrades in older browsers.
When injecting a div server-side from ASP.NET (using .Visible), is it possible that my pages are occasionally being redirected by the server before the javascript in the injected div block finishes executing? If so, how can I prevent a server-side redirect from occurring before my client-side code is done running?
Specifics of my issue:
I needed a quick solution to conditionally track google conversions on ASP.NET pages right before a redirect. I ended up creating an invisible div for each conversion, and when the submit button was clicked, the correct div block would be made visible from the code-behind, and then the rest of the code would process. A redirect is occasionally only a few lines of code away.
After a few weeks of monitoring the numbers, some aren't adding up properly. For example, on a page that cannot be accessed without a previous conversion happening, I'm getting more conversion on the inner page than the outer (which should not be possible). To make sure this div code was executing every time a submit button was clicked, I added a javascript alert as the last line and it did pop up for me every single time. Even after this testing, though, the only logical explanation I can come up with is that the redirect is occurring before the client-side javascript code fully executes. Since the redirect is happening server-side, these run independently of each other.
This will be extremely unreliable. Most likely the tracking is loading an external script or img. As soon as the redirect begins all active requests from the current page are aborted.
If you must track when the user leaves the page I would try some sort of intermediate tracking landing page, or actually encompass all of the tracking code in the submit client function.
In the latter you would have to load the script/image and only process the submit once the onload callback fires.
Hope this helps.
I have made few changes on this huge JSF page, which is full of Javascript as well. I dont know which change make the problem happen.
The problem is: after some Javascript is executed, all the text fields in the page become readonly. The problem is not occurring in IE7 nor in Firefox. I have debugged all the javascript, there is no errors thrown! And there is nothing telling the fields to become readonly, since its working correctly in IE7.
Not sure what the problem is, could be CSS related? or Javascript? And why is it happening on IE6 only?
Note: "Don't support IE6 is not an option"
While IE may be buggy make trouble in some situations, I'm quite sure this is not an IE bug.
How do you tell the fields are read only? Do you get any optical confirmation or is it just that you can't click them any more? In that case, I'll bet you a beer that is's some invisible DIV or other layout element that, due to some CSS setting, squeezes itself above the input fields.
Try the IE developer toolbar to find out whether it's a layout problem.
If they are really disabled as in <input disabled> you need to show some JavaScript or (better) a link.
Still not sure what happened with that build, but what i was sure about is all the Ajax modifications i did was responsible for the problem.
The scenario was like:
Fill textfield1 (hit getValues1 , then hit a validate Ajax)
Fill textfield2 (hit getValues2 , then hit validate on both values together)
Fill textfield3 (hit getValues3 , then hit validate on all three values)
And a forth time again the same scenario. The page was built by a new to JSF guy, and it was very huge. I took long time refactoring it. But now its much better, each text field still have a getValues Ajax, but instead of validating them after getting all the values, i filter the allowed values on the server by sending the chosen criteria
The scenario now:
Fill textfield1 (hit getValues1 Ajax)
Fill textfield2 (hit getValues2 Ajax with value of 1, and get only allowed values)
... etc
The problem seems to be an Ajax racing conditions and at some moment IE6 was hanging or stuck in a deadlock, im not sure.
Lesson learned, "Refactoring once may take a week, but without every single issue will take longer"
um... don't support IE6??? ;)
Suggest disabling your CSS and seeing if the problem goes away. I'm not aware of any CSS tags that can disable a field, though.
Other than that, debugging is your only option. Remove all your .js and add it back in line-by-line until something breaks.
It will probably be hard for us to help you without seeing some code.
See if the HTML for the page has the 'disabled' attribute set on those INPUT elements. If so, then javascript is being used to enable the elements after the page has loaded. This is a not-uncommon technique to keep users from prematurely trying to interact with a page before all scripts have loaded.
If that's what is happening, then what you've probably done is break the way the script recognizes which elements need to be enabled. Since this is only happening on IE6, it sounds like the script might be doing some esoteric DOM navigation, which broke as a result of changes to the markup or CSS.
Unfortunately this is something you'll have to debug by reverting back to previous versions until you identify the change you made that broke the page.
Based on the other answers here, and some of your comments to them, it seems there is a JavaScript function in your page that sets elements to be enabled or disabled.
In order to help, we would have to see your code. Here is something you can do yourself, though, that would solve your problem:
Find that function (or ANY function) that sets elements in your page to disabled or enabled.
Depending on your development environment, there are different ways to do this, but somehow add a breakpoint there at the function.
Load the page.
Whenever that function is called, code execution will stop at that function. Whenever it stops, make sure that it was supposed to be called (and watch the call stack).
Eventually, you'll hit that breakpoint at a point where you weren't supposed to. Look at the call stack to see what caused it (which function resulted in a call to this function).