I know that in order to use most of the controls from the Ajax Control Toolkit, you need to include the ToolkitScriptManager control on your page, and it must be the Toolkit script manager, and not the standard script manager because the extended toolkit version contains extra (java)scripts which enable the controls to work and communicate properly.
My problem is that I keep coming across projects at work from other developers where they used the standard ASP ScriptManager control, and added toolkit controls without switching over to the ToolkitScriptManager. I would have expected these projects to not debug properly, yet they are currently somehow working in test and production environments, and they do not actually break until I download them onto my freshly loaded dev environment from source control.
When someone asked me "Why do we need to replace these controls? They're working everywhere else." I could only shrug my shoulders, I have no idea why other projects are working with regular script managers.
As a side note, problems like this are what are pushing me into becoming a JQuery guy instead of a ACT guy.
Here is a question to answer since this is a Q&A site and not a discussion site: "How is it possible to run the ACT controls without an ACT script manager?" Personally, I would point to a glitch in Visual Studio of some kind, but I want to know if anyone else knows more.
ToolkitScriptManager inherits from ScriptManager and extends/improves its functionality.
You may safely substitute ToolkitScriptManager with ScriptManager just so long as you are not using any advanced feature provided by the ToolkitScriptManager.
What are those supposedly advanced feature differences you ask?
Check Here for your answer...
TMI Alert:
MS actually recommends replacing ToolkitScriptManager in certain instances if you are suffering from Out Of Memory exceptions and there are also a high number of System.Web.FileMonitorTarget objects in existence. These objects are used to check and see if the page was modified (you can see how it relates to AJAX), but these objects should go away and not be maintained.
For some reason, if you're using the ToolkitScriptManager, there are instances where FileMonitorTarget objects just don't go away and end up contributing to server memory problems, but neither I nor they fully understand why replacing the ToolkitScriptManager with ScriptManager actually helps in these scenarios, but just so long as it works, we won't continue to ask questions...
Related
We recently migrated a large ASP. website from framework 1.1 to framework 3.5 and in the process also migrated from a website to a web application.
On the surface everything seemed to work fine, but now we are discovering that none of the "pages" are doing what they used to.
The site is made up of one default.aspx page that loads all the "pages" as user controls. (I am guessing this was to achieve the same effect as having a master page before master pages were invented.)
I think we missed a trick (or twelve) during the migration. What are the big stumbling blocks that other people have experienced
Update
We managed to find the problem that was making our pages stop working, but can not figure out why: When we cleaned up the code of the main page, we added whitespace (a newline) between the open and closing tags of the control that all the other "page" user controls get loaded into. Once we removed the newline everything started working again. Can anyone explain this?
I have experienced problems during manual copying etc. that has lost the connection between the GUI controls and the event-methods in the code behind. There are differences between the different versions of ASP.NET on how the event handling is coupled, and there are even more than one way of doing it (automatic based on names or explicit in code), and this is easy to mess up when changing from one "standard" to another, which is what you do converting to a differen version of .NET. It is also an additional source of confusion for Visual Studio when you also converted from Web Site to Web Application.
I am guessing that the trick was just to do some editing in Visual Studio, and VS might have automagically re-attached event handlers etc.
One things you should know is that if your new server is 64 bit. There is a chance that the controls on the page will be loaded concurrently with the page. In a sense there will be a lot of timing issues. If you are not using 64 bit server however this is not relevant.
After reading the answer here, I understand that, if I register a user control (I guess I'm really trying to use it as a custom server control) like this:
<%# Register Assembly="MyDLL" Namespace="MyDLL" TagPrefix="myDLL" %>
Then only the codebehind is used, and the markup (.ascx) page is ignored. Why is this the case (it seems arbitrary), and how can I get around this problem without having to specify the Src="..." attribute in my Register directive? All I want to do is build a user control into a single assembly (a DLL) and hand that DLL off to another web site or web application project in such a way that the web site/app can use my user control. This should not be that hard, but apparently it is...
I am working in Visual Studio 2008, if it makes a difference.
Edit (prompted by the links in Rex's M's comments): it seems like most of the instructions for doing this kind of thing are applicable to VS2005, even the stuff on MSDN. My question is pretty much exactly stated here; is the answer provided on that thread correct
Is there any reliable, recent documentation describing this sort of thing for ASP.NET 3.5 and VS2008? I feel like using the latest versions is causing more confusion and difficulty than benefit.
The thread you linked to is indeed correct. The information which originally addressed .NET 2.0 and VS 2005 is still very applicable. .NET 3.5 does not actually change .NET 2.0, just adds extra stuff. For things that are already in .NET 2.0, they are unchanged in 3.5.
It sounds like you want the functionality of a Custom Control. In a normal user control situation, the website needs an .ascx and that cannot be placed in a DLL.
I strongly recommend to take a look at custom server controls. Since for the purpose of sharing controls over multiple projects they are better suited in my opinion than user-controls. User controls are better for internal reuse, within the same web application (i.e. on multiple pages).
Should we be able to just reference the Telerik DLLs within our project, set the Output Local to TRUE and be done with it? Things work perfectly on our development machines where we installed the entire Telerik Control Suite but when we deploy, we have a problem in which Telerik controls within UpdatePanels don't seem to be firing events.
If the controls are rendering on the deployed environment without an error, then the necessary .dll's are at least being referenced somewhere.
However, if you have them installed in the GAC, and your reference is to the GAC, then "copy local" might not be doing anything... they might just be copied, and no one is even referencing them.
Can you double check that all your references are local references, and there aren't different versions installed on the GAC on the two machines?
I would look a the .dlls being outputted and those that are on your machine. I bet there is a .dll that it is looking for in the GAC that is not on your production box.
On a side note, why not just use the ASP.NET Ajax Update Panel?
First a little disclaimer - I work for Telerik :)
This is really a strange case. Could you check for any JavaScript errors on your production environment? I suspect there is some deployment issue (for example web resources not configured properly). In case there are JavaScript errors you can check my blog post which explains how to deal with the most common cases.
In any case I recommend you open a support ticket (if not already).
My problem had to do with an HTTP Module we had running for URL encryption. I have found, however, it is best to NOT combine asp:UpdatePanel and RadAjaxPanel in the same pages.
Is the source code for the common login controls available?
Those are the controls which are available under Login section in Toolbox:
Login,
LoginView,
PasswordRecovery,
LoginStatus,
LoginName,
CreateUserWizard,
ChangePassword
Eventually could you point me to a good source of custom implementation of functionality that those controls provide, or some guidance on implementing this functionality without using the mentioned controls.
I am using Visual Studio 2005 (.net2)
I will be using SQLMembershipProvider as the MembershipProvider but that probably should make no difference.
"the entire framework is available" is not true. :)
The source code for the entire framework is available. The link below provides some details as to how to access:
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
I am going to give this a qualified "NO".
I have gone down the road of implementing an implementation of the Login server control using reflected source as a starting point (this was before symbol server integration).
Things seem to go swimmingly, with a few reflection hacks to get to core framework members that obviate reams of code.
Until you get to the designers. That infrastructure is a minefield and gets wide and deep with a quickness and is filled with even deeper buried internal types that need implementations or reflection hacks.
Ultimately wound up with a working control that I could extend but would never want to maintain.
The effort was not wasted; I learned a lot about how over engineered server controls are designed.
And then I just shifted a login control to template mode and got everything I needed to get done in a few lines of code. ;-)
Except as a learning experience I would certainly recommend against going down that road.
Good luck.
I'm using an older version of ASP.NET AJAX due to runtime limitations, Placing a ASP.NET Validator inside of an update panel does not work. Is there a trick to make these work, or do I need to use the ValidatorCallOut control that comes with the AJAX toolkit?
I suspect you are running the original release (RTM) of .NET 2.0.
Until early 2007 validator controls were not compatible with UpdatePanels. This was resolved with the SP1 of the .NET Framework.
The source of the problem is that UpdatePanel can detect markup changes in your page, but it has no way to track scripts correctly. Validators rely heavily on scripts. During a partial postback, the scripts are either blown away, not updated, or not run when they are meant to.
In early betas, MS had the UpdatePanel try to guess what scripts needed to be re-rendered or run. It didn't work very well, and they had to take it out.
To get around the immediate problem, Microsoft released a patched version of the validator classes in a new DLL called Validators.DLL, and gave instructions on how to tell ASP.NET to use those classes instead of the real ones. If you Google for that DLL name, you should find more information. See also This blog post.
This was a stop-gag measure and you should not use it avoid it if possible.
The real solution to the problem came shortly after, in .NET 2.0 SP1. Microsoft introduced a new mechanism to register scripts in SP1, and changed the real validator classes to use that mechanism instead of the older one.
Let me give you some details on the changes:
Traditionally, you were supposed to register scripts via Page methods such as Page.RegisterStartupScript() and Page.RegisterClientScriptBlock(). The problem is that these methods were not designed for extensibility and UpdatePanel had no way to monitor those calls.
In SP1 there is a new property object on the page called Page.ClientScripts. This object has methods to register scripts that are equivalent (and in some ways better) to the original ones. Also, UpdatePanel can monitor these calls, so that it rerenders or calls the methods when appropriate. The older RegisterStartupScript(), etc. methods have been deprecated. They still work, but not inside an UpdatePanel.
There is no reason (other than politics, I suppose) to not update your installations to .NET 2.0 SP1. Service Packs carry important fixes.
Good luck.
#Jonathan Holland: What is wrong with using Validators.dll?
Since they replace the original classes, you are quietly bypassing any bug and security fixes, enhancements, etc. that Microsoft might release in the future (or might have already released). Unless you look carefully at the web.config, you might never notice that you are skipping patches.
Of course, you have to evaluate each situation. If you are absolutely stuck using .NET 2.0 RTM, then Validators.dll is better than nothing.
#jmein
Actually the problem is that the Validator client script's don't work when placed inside of an updatePanel (UpdatePanels refresh using .innerHTML, which adds the script nodes as text nodes, not script nodes, so the browser does not run them).
The fix was a patch released by microsoft that fixes this issue. I found it with the help of Google.
http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx
If for what ever reason you are unable to use the udpated version of the ASP.NET validator controls is actually very easy to validate a validation group yourself, all you need to do is call
Page_ClientValidate("validationGroupName");
Then you can use the PageRequestManager execute the validation as you need.
Definately using the updated validation controls is the way to go, but I'm quite partial to JavaScript ;)