enter image description here
I'm a javascript/html newbie. I'm wondering what this exactly means and why it needs to be done. Won't declaring javascript method anywhere inside the page allow the javascript method to be ready before the dom is ready?
On a side note: I've had issues getting a javascript method to the execute on the onchange event of an ASP.net dropdownlist control, and I'm wondering if it is because the javascript method is declared near the end of the page, after the dropdownlist control is instantiated.
The dropdownlist and javascript function is on a content page, i dont know if that would make a difference regarding the javascript, when it does a postback and has to be placed on the master page.
Related
I am injecting a Javascript-File via a Chrome-Extension on a webpage that uses SAPUI5.
I want to get the model in the binding context of some UI5-Input elements and in order to do so, I need to get to the inputs via document.getElementsByTagName. (or is there another way?)
This only works if they are already rendered. Unfortunately the ready or load events fire too early, when not everything is rendered yet.
Is there a way for me to know when the inputs have rendered?
Edit: I do not have access to the source code of the page, everything I do has to be in the injected script.
To make sure everything is renedered before firing your events, sapui5 has the function onAfterRendering.
All logic written in that function will only be executed after the control is rendered.
When a rerender of the control is rendered, the onAfterRendering is triggered again.
In the end I did it like this:
I already had event listeners attached to click and key events. Every time the handler is called, I check if document.getElementsByTagName('input') returns the inputs I need.
If yes e. g. the rendering of the inputs is complete, I set a boolean that the page is loaded completely and execute my code.
I have an ASP.NET page which sometimes does not generate the expected "WebForm_AutoFocus()" javascript, even though I am explicitly calling .Focus() on one of the controls. Are there any known scenarios where some factor would prevent that javascript from being generated?
Specifically, when the user clicks a particular button, I'm creating some new controls dynamically: in this case a text box. In OnPreRender I'm grabbing that newly-created control and calling .Focus() on it. The idea is, when the postback completes, the browser gives focus to the newly-created textbox control. However, the generated HTML (verified via firebug and fiddler) simply does not contain a WebForm_Autofocus call at all.
In other scernarios, the same page (on postback or on initial hit) calls .Focus() on a different control - one which is not dynamically created; in those cases the WebForm_AutoFocus() script is generated perfectly, and all is well.
Unfortunately, I'm working on a client system that LOVES frameworks upon frameworks, and abstractions upon abstractions, so I cannot post a meaningful/concise code sample here. However, if any of my friendly SO'ers knows more about generation of that "WebForm_AutoFocus" javascript - and scenarios which would prevent it from being generated - that would give me a good place to start digging.
The autofocus call only gets included if asp.net thinks there is a need for it. Set a default button on the page so that asp.net will know to make the method.
In web development, JavaScript is often executed when clicking on elements.
In both Internet Explorer 9 and FireFox 4 a little message pops up in the bottom left hand corner with the JavaScript function will be executed by clicking on elements these elements.
ASP.NET makes use of the JavaScript __doPostback(...ugly parameter names..) on almost every element that sends a request to the server. This JavaScript is automatically added to the HTML elements that are generated by the ASP.NET controls and I have no way to circumvent this.
For example, an ASP.NET DropDownList is rendered as an HTML Select element and the __doPostBack() method is added to it so that whenever the user selects a new element, the server can process this action.
The __doPostaback() method is embedded into many of the ASP.NET controls and there is no easy way to change this.
One of my end users commented that this new feature makes it feel as if they are in "Debug-mode"....
So, my question is: how do I either make this popup show something user friendly...or is there a way to tell the browser (via HTML) not to display this nastiness?
Thanks!
-Frinny
Why don't you make the href of the link a hashtag and attach the actual action via JavaScript:
HTML
<a id="foo" href="#foo">Foo</a>
JS
var foo = document.getElementById('foo');
foo.onclick = function(e){
//script foo!
return false;
};
Your location will still be #foo to look nice, but the actual action will be in the foo.onclick function.
Alternatively you can specify the event inline (Foo), but I try to keep a clear MVC separation with HTML, CSS, & JS.
Using a hashtag also gives you the ability to listen for hash-change events or check the hash tag onload so that a user can still middle-click a link and have it work correctly in a new tab.
To my knowledge there isn't a way to make it not display, as that is part of the browser and not the page.
What I would do is create javascript functions at the top of the page with user readable names that contain the other functions inside.
I'm trying to manually call the ASP.NET (3.5) javascript postback function __doPostBack from my javascript code. The problem is that the postback script block, that is normally rendered right after the beginning of the <form> tag (and the hidden fields), is occasionally rendered near the closing </form> tag.
Is there any way to force it to be rendered near the beginning of the form tag? Also, how does ASP.NET decide when/where to render the postback client script block?
Edit > Additional Info:
The javascript code resides inside a user control that references the __doPostBack function. The control itself does not contain any 'postback controls' that would call that function. (When I mention 'postback controls', I mean ASP.net controls that call the __doPostBack function and not the asp.net ImageButton and Button controls)
Based on what I've observed and #Brian's comment on the dependency of the postback script on the availability of 'postback controls' on the page, I've found that when the page contains controls that cause postback, the __doPostBack script block is rendered after the opening <form> tag and when there are none, it renders them near the closing </form> tag (or according to this it's not even supposed to be rendered). Now it would make sense for ASP.NET not to render the postback script if there are no controls that require it, but the apparent position of the script near the closing tag is the one that still eludes me. I haven't been able to find any documentation that suggests this behavior. All I've been able to find was this.
Having said that, I've found a couple ways around this issue:
Add a 'postback control' and set its visibility to hidden via css (not the Visible property). eg. <asp:LinkButton ID="RequirePostBackScriptLink" runat="server" style="display:none;" /> (this is what I'm using)
Add the control to the Page.RegisterRequiresPostBack and implement the IPostBackDataHandler interface.
Finally, as #Jonathan_Bates mentioned in his post, the proper thing to do is to wrap the reference to __doPostBack inside a function that is an event handler to load (or ready if you're using jquery). That way, there wouldn't be a need to depend on the actual placement of the __doPostBack script.
It'd be great if anyone can provide more info on this, aforementioned, behavior.
I am guessing that where it renders is important to you so that your scripts render after it and can invoke it (which let me say up front, is a bad idea to begin with).
You just need to make sure that whatever script you are using to call __doPostBack calls it after its been read into the browser. If you use a library like jQuery and its $(document).ready() convention, you can be sure that your code won't execute until all other code is loaded, and therefor your code would be able to call __doPostBack.
Some of it is controlled by the controls that render, whereas the page injects the client script blocks and startup scripts at a pre-defined point...
I assume this is for a control or something? This isn't for a standard block?
There seem to be a number of weird things one could do if one wanted, for hooking up page-load type events. Here are some specific questions:
I know about the auto-hooked-up pageLoad function. Are there any others like it?
Where do I hook up events like those from, e.g., Sys.Application.add_init or Sys.WebForms.PageRequestManager.getInstance().addPageLoading?
What's the difference between the first two of those and pageLoad, if any?
Rather importantly, what is the "correct" way to be sure that the ASP.NET AJAX files are all loaded before you start hooking up event handlers, processing the page, etc.? My current approach is to use the auto-hooked-up pageLoad to hook up the rest, but this seems kind of hacky.
The built-in pageLoad function is just a shortcut to the Sys.Application.load event. There is another one - pageUnload. Find more info here.
You can hook those events up almost whenever you like - using the pageLoad function, invoking the add_init/add_load method inside a script block or calling ScriptManager.RegisterStartupScript from server-side. Just make sure you call that JavaScript within the form tag (see #4). By default all those events occur after the page is loaded so your code should have already been executed by then.
Technically there should be no difference between using pageLoad and the load event - the first is just easier to hook up.
By default the ASP.NET Ajax script files are rendered just after the beginning of the form tag. This means that those files will get loaded before any other JavaScript statement defined within the form tag gets executed.