I am working on a ASP page having search option. After getting search result, wherever i click on any link which calls javascript function, I am getting an error as 'object expected'. (All search result is displayed on single page only and this happens only on large result). When i enabled javascript debugging, it allows me to debug this error scenario in Visual studio. Here What i found is, the ASP page gets loaded is incomplete(clipped inbetween). So the javascript function which gets called is not in this perticular frame as it is written after body tag.
So my question is, Is there any page size limitation for processing ASP or HTML.
(I am using IE browser). Please let me know any more infor needed.
Thanks.
Not sure page size has anything to do with your problem. However if you are using a grid control set EnableViewState="false" this will reduce your page size considerably and speed up any postbacks you may be doing.
Related
I have the problem that I cannot use the ScriptManager in my ASP.NET Web Forms (4.5) anymore. It always throws the following critical JavaScript error messages (SCRIPT1002 is telling a syntax error) in Internet Explorer 11:
I tried to solve the problem with https://pavanarya.wordpress.com/2011/page/11/ and found out that WebForms.js shall cause the problem regarding to the decrypted WebResource.axd URL of the first error message (see above).
Furthermore, I found out that the error vanishes if I remove the line
from my Layout.Master file. All error messages vanish, but AJAX elements like TreeView (I also use UpdatePanel and Calendar) do not work anymore then, too.
I also tried the Script Resource Viewer from http://www.dotneti18n.com/Downloads.aspx via
http://www.guysmithferrier.com/post/2007/07/Script-Resource-Viewer.aspx. But the funny thing is that even the Script Resource Viewer implements the line
which exactly causes the same error as before, and so it is not a real help for me.
It must be some global problem in the whole project since it does not accepts any ScriptManager (no matter in which ASPX file) anymore. Does someone know that problem?
Many thanks in advance!!!
Remark: The Firefox Browser does not throw an error message, but it does not show the TreeView correctly, too. All images (ImageSet) of the TreeView are missing and the Web Browser displays text instead of the images. I also use a Chart (System.Web.DataVisualization) in the Web project, it was the last item which was added there. I use C#.
I am unable to put this as comment. So I will put it as Answer:
Use ToolScriptManager instead of ScriptManager.
I know this is rather a trivial question but anyhow I want to know if it is solvable.
I have an ASP.NET webform page with a nested masterpage and JavaScript includes. I make extensive use of jQuery and Ajax calls. Once a page is loaded, all communication with the server is done with Ajax calls, so I don't need ViewState enabled, and this is resulting in a reduced HTML output code.
I now have to implement a page where a user can upload a file. So I used the AsyncFileUpload control of AjaxToolkitFileUpload. Once a file is uploaded, I do a Ajax call to the server to request the filename.
It all works fine but I noticed that FireBug found 10 errors per file upload between the OnClientUploadStarted and the OnClientUploadComplete events. The file is uploaded properly and the events on the client side are working too. But I can't ignore the fact that there are errors thrown so I went looking for the problem.
I rebuild the page piece by piece and I found out that this control needs the Viewstate enabled.
However with viewstate=disabled in the page directive the file size is 76.6kb, and with viewstate=enabled the size is 99.2kb.
Again, I know it is trivial and will not affect performance on the site, but it is a nice to know.
- Why does this control needs the viewstate? (I suppose because it actually post the file to a iFrame or something like that?)
- How can I reduce the viewstate and let this control still work properly?
For reducing view state and having this one control work properly, you can use leave view state enabled on your page and set the ViewStateMode to Disabled for the page and then set the ViewStateMode to Enabled for the one control that needs view state. For all other controls they should inherit the setting of the parent by default.
I having an issue with the ASP.NET Treeview control. I create the treeview just fine but the nodes will not expand or collapse. I see there is a javascript error but it is for line 1 character 0 of the webpage, there is nothing at line 1 character 0.
I am using the ASP:Treeview control in conjunction with the Telerik controls, but I'm not sure if that is an issue.
I saw there was a similar question here but the answer is not pertinent to my site. Has anyone run into this issue before? I've tried searching Google and tried a number of proposed solutions but so far none have worked.
Thank you,
Normally with problems like this it is best to isolate the code which is causing the problem. For example, create a minimal page with no other controls or external JavaScript and see if the problem persists.
It's also useful to use a decent debugger. The latest IE8 actually has a very good Visual Studio-style JavaScript debugger built in - go to your page, hit F12 and the go to the Script tab and click 'Start Debugging' and see where that leads you.
I've seen unhelpful javascript errors when a page does an AJAX postback, an exception occurs on the server, and the client javascript is unable to handle what the server returns. You could ascertain if this is happening by debugging the site, putting a breakpoint on the Page_Load method (or something similar), and see if it gets hit when trying to collapse or expand the TreeView.
We got strange error last days. ___doPostBack is undefined.
We are building quite advanced website, but not using postbacks much. One of place where postback used is ASP.NET Login Status control.
It is probabalystic, sometimes it is rendered, sometimes - not. For IE, Chrome it works mostly fine, but from FireFox it is quite high chance not to have doPostBack in page source.
Any ideas?
PS: In addition, error happens only on live environment, which uses Windows 2003 & IIS 5.0, dotnet framework is 3.5
Can it be because I am using OutputCache on page level?
Just happened to us: When googlebot or any other bot hits your page before a regular user, the page is cached without any postback options.
We did a simple hack, using different a outputcacheprofile if the request.browser.javascript is false (asp.net sends different versions of the page to those browsers/crawlers/bots)
I had the same problem, but I realized that ASP.NET does not render __doPostback when server controls don't need it.
When I put a gridview or linkbutton that need __doPostback, ASP.NET rendered it.
Yes it might be about the output cache, comment it out and try again please
Usually this happens when you have malformed javascript somewhere on the page (usually, before the __dopostback function).
Have you viewed the page source and looked to see if the __dopostback function is actually rendered in the page, regardless of whether you're getting the error or not?
I want to set a breakpoint on the __DoPostBack method, but it's a pain to find the correct file to set the breakpoint in.
The method __DoPostBack is contained in an auto-generated js file called something like:
ScriptResource.axd?d=P_lo2...
After a few post-backs visual studio gets littered with many of these files, and it's a bit of a bear to check which one the current page is referencing. Any thoughts?
If you using IE7 for testing you can use View -> Script Debugger -> Break on next statement and then just click the button that generates the event(__DoPostBack)
TBH, I dont think there is much value in setting a breakpoint within the Javascript since it pretty much comes straight back to the server anyways.
It would be best to set breakpoints in your server code.. Depending on what you are trying to debug this will be in different places.. Either in the page event cycle or a controls IPostBackEventHandler.RaisePostBackEvent handler.