ASP.NET Treeview Control not expanding on click - asp.net

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.

Related

Problems with ScriptManager, ASP.NET Web Forms (4.5), Visual Studio 2013 Prof., AJAX

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.

Failed to load viewstate error after moving website to a new server

I don't really know where to start with this one. I am getting:
`Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request.`
after moving a website to a new server. The exact same code works on my other server. It happens when I submit one of my forms (but doesn't do it on all form submissions).
Any ideas what can cause this so I have somewhere to look?
Using: ASP.NET 2.
EDIT: I am adding some user controls to a placeholder dynamically at runtime but this same code is working ok on my other server. I have tried clearing the controls in the place holder before adding new ones (as I saw a post about that) but it hasn't helped.
EDIT2: It seems that the postback is just failing. It isn't going into the onClick code of the button either so something is deffintiely screwy .. If I try / catch the exception it seems that all the controls are still added successfully ... Setting my Dynamic UC's to EnableViewState = false resolves this particular error.
EDIT3: Ok, I think I may have a handle on what is happening. For some reason on the old server the form action is default.aspx?action=amend but the new server is showing amend.html?action=amend so I think the re-write module is messing up in IIS. This would explain the control adding issue as well because the action is happening 2 times (I think). I will look into the Rewrite module and see if anything is wrong then post back.
Please, have a look at these articles:
http://blog.typps.com/2008/01/failed-to-load-viewstate-typical.html
http://weblogs.asp.net/guys/archive/2004/12/05/275321.aspx
Or try a simple temporary solution - disable viewstate for this placeholder. Either way, I'm puzzled why it actually works on your first server. I'd be glad if someone else will be able to clarify this subject more.
It turns out that the post back Url for the form is wrong on this server (unsure why at the moment, I will update when I know). This is causing the dynamic controls to be added in an unexpected way and causing the error. I noticed this when I managed to post my form and the content didn't update. I manually adjusted the action url using firebug and all is well.
Worth looking at walther's answer regarding dynamic controls and the viewstate though.
Not sure what caused it but I am manually setting the form action in the page load now and it seems to have solved the issue.

Postback intermittently not working with ASP.NET 3.5 and IE?

We have an ASP.NET application that we recently migrated onto a new server with IIS7 and .NET 3.5.
In this new environment, some users that are on IE (6, 7, or 8) are experiencing bizarre intermittent problems with postback not working on ASP.NET buttons. (you click the button and nothing happens)
The issue happens sporadically. Sometimes it works, sometimes it doesn't. For some users the button postback almost never works (but sometimes yes!). To complicate matters there are some pages with asp.net button postbacks that DO always work.
Other pages contain a mix of 'asp buttons' and 'asp link buttons', in which the asp button postbacks often don't work, but the link button postbacks always work.
Javascript is enabled and works. The source DOES contain valid tags.
I actually managed to take View Source snapshots of the same page when it was working and when it was not working and the source was EXACTLY the same!!!
At first I thought it was a problem with IE6, but it's now been reproduced on IE7 on one user's machine.
How would I even BEGIN to tackle this problem?
Any help, ideas, or guidance would be vastly appreciated. I am at the end of my mental rope here.
I know this topic is pretty old, but I found the same problem in my code.
I am using the ComponentArt component library.
In certain circumstances after a postback, buttons with codebehind will no longer execute in IE. I also noticed that buttons with onClientSide clicks would execute their postback when the JS function completes and returns true.
I was able to get all the buttons on the page to submit by adding the following code to my buttons:
OnClientClick="javascript:return true"
Any buttons that are already running a JS function and returning true, should work without issue.
See if this post helps? IE 6 treats buttons a little differently, especially if you have some name conflicts. I could see this being a problem for events if that is the case.
Found the culprit.
It was ComponentArt's 2007 Web.UI components that were being dropped on the page.
Apparently the menu control mixed with the 3.5 framework causes wierd issues with postback not working.

ASP.Net button click event not firing

This is perhaps related to this question, but I have slightly more information.
I recently updated an ASP.Net application to .NET 3.5 after coding a few new pieces with Linq. Now my pages intermittently stop firing event handlers. I have it narrowed down to pages with Ajax on them, and I assume it's either the ScriptManager or the AjaxControlToolkit registration that is precipitating the problem.
The really screwy part is that pages seem to work fine about 2/3s of the time, and the controls lose their event handlers only 1/3 of the time. I wondered about some type of error occurring and the page not rendering correctly, but I cannot find evidence of this.
We were have exactly this issue and as you have said it was only happening some of the time and only on pages with Ajax requests. We found that disabling the HTTP Keep-Alive as suggested in the answer to
Why does Internet Explorer not send HTTP post body on Ajax call after failure? worked.
This can be done in IIS7 by following the instructions in How to configure HTTP KEEP-ALIVE in IIS 7
i have only used Telerik Ajax controls so far, and my observation is if an exception occours in a Ajax enabled control, nothing happens. No exception report, no action. nothing.
Maybe you should test you app without ajax to identify any problem spots
My initial thought would be that something is happening where the javascript is erroring out (un-caught) and aborting the async postback.
If you can get this to happen in a development environment, you might want to try error handling the window.onerror event and throwing some alert boxes up. It might help to see where possible errors occur.
have you tried:
ScriptManager.GetCurrent(this).RegisterAsyncPostBackControl(yourButton);
It's seem to me, you have issue with Update Panel.
Define the following properties of Update Panel if you are using more than one update panel and updation of one panel change the data of other update panel.
For the UpdatePanel
ChildrenAsTriggers = true
EnableViewState = true (if you are using this feature)
UpdateMode = Always
Use the same properties for other update panel in your same page.
If you find it useful, please mark it as your answer else let me know....
Try commenting out Update panel if any. Then try to click button there must be some error on the page. I've also faced similar issues.
In my case none of the events (either button or check box) were firing. I was able to overcome by this problem using following way.
In my master page I had closed a tag referring to an external .js file with /> notation instead of <script></script>.
for Ex: chanage <script src='../../Scripts/common/menu.Js' type='text/javascript' /> to <script src='../../Scripts/common/menu.Js' type='text/javascript' ></script>
Hope this will help you,
Ramesh

asp.net: __doPostBack not rendered sometimes

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?

Resources