Rakshith.Net

Firebug for IE and chrome

2009-11-13T01:23:00.000-08:00

Installing Firebug

Just add this code into any page that you want to contain Firebug lite:

How to call javascript function on userControl load ?

2008-10-30T05:27:00.000-07:00

One way to do this is
Register StartUp script on pageload of your usercontrol

Page_Load()
{
ClientScript.RegisterStartupScript(this.GetType(), "onlo", "YourMethod();",true);

}

Another way is
call your method on window.onload

Master Page To Content Page Interaction

2008-01-29T02:43:00.001-08:00

Here is a case where the master part of the master page name can be misleading. The master page sounds like a good place to put logic and code that will tell the page how to do something. After all, a master page is the master, right? We now know that the master page is just another child control. Ideally, the master page will remain passive. Instead of telling it’s parent page what to do, the master page should tell a page when something interesting happenes, and let the page decide what to do.

Let’s pretend every page in our application displays a report, and every page needs a button for users to click and email the report. Putting a Button and a TextBox inside the master page seems like a reasonable choice.

< asp:TextBox runat="server" id="EmailAddressBox" />
< asp:Button runat="server" ID="SendEmailButton"
OnClick="SendEmailButton_Click" />

What happens when the user clicks the button? We can choose from the following options:

* Handle the Click event in the master page, and have the master page email the report.
* Expose the Button and TextBox as public properties of the master page, and let the content page subscribe to the click event (and email the report).
* Define a custom SendEmail event, and let each page subscribe to the event.

The first approach can be ugly because the master page will need to call methods and properties on the page. Master pages are about layout, we don’t want to clutter them with knowledge of reports and specific pages.

The second approach is workable, but it tightly couples the page to the master. We might change the UI one day and use a DropDownList and a Menu control instead of a TextBox and Button, in which case we’ll end up changing all of our pages.

The third approach decouples the master page and content page nicely. The page won’t need to know what controls are on the master page, and the master page doesn’t have to know anything about reports, or the content page itself. We could start by defining the event in a class library, or in a class file in App_Code.

using System;

public class SendEmailEventArgs : EventArgs
{
public SendEmailEventArgs(string toAddress)
{
_toAddress = toAddress;
}

private string _toAddress;
public string ToAddress
{
get { return _toAddress; }
set { _toAddress = value; }
}

}

public delegate void SendEmailEventHandler(
object sender, SendEmailEventArgs e);

We can raise this event from a master page base class (if we have one), or from the master page itself. In this example, we will raise the event directly from the master page.

< %@ Master Language="VB" %>

< script runat="server">

Public Event SendEmail As SendEmailEventHandler

Protected Sub SendEmailButton_Click(ByVal sender As Object, _
ByVal e As System.EventArgs)

Dim eventArgs As New SendEmailEventArgs(EmailAddressBox.Text)
RaiseEvent SendEmail(Me, eventArgs)

End Sub

< /script>

We'll need to add some validation logic to the master page, but at this point all we need is to handle the event in our page. We could also handle the event from a base page class, if we don’t want to duplicate this code for every page.

< %@ Page Language="VB" MasterPageFile="~/Master1.master"
AutoEventWireup="true" %>
< %@ MasterType VirtualPath="~/Master1.master" %>

< script runat="server">

Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs)
AddHandler Master.SendEmail, AddressOf EmailReport
End Sub

Protected Sub EmailReport(ByVal sender As Object, ByVal e As SendEmailEventArgs)

Dim address As String = e.ToAddress

' do work

End Sub

< /script>

Tab Control doesn't display correctly within User Control

2008-01-14T06:41:00.000-08:00

I m using a user control in a Tab Control. I don't know why some times i get 'Sys.Res.referenceNotFound' is null or not an object javascript error.By this error my Tab control get blank.No user control is being displayed.This doesnt happen on every request.I have tried searching for the answer. but the search didn't worked. Then i finally found the answer for this problem.

The default ajax__tab_tab class has a hard-coded height of 13px.But where in my user control exceeds this height.So increasing the size of ajax__tab_tab class to 21px solved my problem.
But this may work I m not sure.But in my case it worked and got into another problem, where my other pages formatting screwed up.Then i did lot of other stuffs for that.
But make sure that other pages formatting is correct before using this fix.

Microsoft JScript runtime error: 'AjaxControlToolkit' is undefined

2008-01-08T22:17:00.002-08:00

Just ran into this weird error when trying to add an AJAX control to a web page and we spent a lot of time trying to resolve this.
Basically the web page worked fine but when moving it to the server it generated a client-side JS error: "Microsoft JScript runtime error: 'AjaxControlToolkit' is undefined".

this is the corresponding code:

Sys.Application.add_init(function() {
$create(AjaxControlToolkit.ModalPopupBehavior, {"BackgroundCssClass":"modalBackground", ...}, null, null, $get("btnNew"));
});

Google search did reveal people having similar problems but no good solution.
Then there was some good information in this thread.
Basically it turns out that the the script is being compressed under certain circumstances (like debug mode vs. non-debug) and whether the compression settings are defined in the web.config file.

Here is what fixed it for us. The important setting is the one "enableCompression='false'":

<system.web.extensions>
<scripting>
<scriptresourcehandler enablecompression="false" enablecaching="true">
</scriptresourcehandler>
</scripting>
</system.web.extensions>

Make sure you switch the compression off, since it seems it does not work, even when using IE7 like I do.

Configuring ASP.NET AJAX

2008-01-05T03:59:00.000-08:00

This topic describes the elements in the Web.config file that support Microsoft ASP.NET AJAX. It also describes how to incorporate those elements into the Web.config file for an existing ASP.NET application.

Using the ASP.NET AJAX Web Configuration File in a New Web Site

When you create a new AJAX-enabled Web site, you can use the Web.config file provided in the installation package to add the required configuration settings. In Visual Studio, the Web.config file for Microsoft ASP.NET AJAX is included in your project when you create a new ASP.NET AJAX-enabled Web Site.

If you have to manually add the Web.config file to a new Web site, you can get a copy of it from the installation path. By default, the file is in the following location:

drive:\Program Files\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.0.nnnn

Adding ASP.NET AJAX Configuration Elements to an Existing Web Site

In an existing Web site, you typically have values in the Web.config file that you want to retain. In that case, you can add the new ASP.NET AJAX elements into the existing Web.config file.

The new elements are part of the following configuration sections:

http://asp.net/ajax/documentation/live/ConfiguringASPNETAJAX.aspx

'Sys' is undefined - ASP.NET AJAX

2008-01-04T21:53:00.000-08:00

You might receive the error 'Sys' is undefined when running ASP.NET AJAX Web pages or trying to AJAX enable your exisitng Web Applicaitons.

This error occurs specifically when you try upgrading your existing ASP.NET 2.0 Applications to AJAX by using the ASP.NET AJAX controls like UpdatePanel, etc., The common cause for this error is that you havent updated the Web.Config file of the application to enable the runtime understand ASP.NET AJAX. Let me explain a little more.

When you install ASP.NET AJAX your Visual Studio 2005 gets the toolbox updated with ASP.NET AJAX Server side controls like ScriptManager, ScriptManagerProxy, UpdatePanel, UpdateProgress etc., You already have your existing ASP.NET 2.0 application pages and you can add ScriptManager, UpdatePanel and other controls from Toolbox to your pages. When you run the page, you would get 'Sys' is undefined javascript error. The reason being that, your web.config of the existing ASP.NET 2.0 application misses certain settings that require to be added to make it understand the ASP.NET AJAX Server side controls like UpdatePanel, UpdateProgress etc.,

To resolve the issue, follow the steps in the link below:

http://geekswithblogs.net/ranganh/archive/2007/07/15/113963.aspx

How to improve ASP.NET AJAX error handling

2008-01-04T21:42:00.000-08:00

If you’ve done much ASP.NET AJAX development, you’re no doubt familiar with JavaScript alert errors similar to the one pictured above. This particular one occurs on the official ASP.NET forums in FireFox, if you try to navigate away from viewing a user profile before the Recommended Reading panels asynchronously load.

Not only is the error message of “…” completely meaningless, but it blocks your intended navigation away from the page until you’ve dismissed the alert window. Hopefully, someone at Telligent will read this, because the ASP.NET AJAX framework gives us an easy way to replace the annoying JavaScript alerts and vastly improve the usability of our applications.

Find more details : http://encosia.com/2007/07/18/how-to-improve-aspnet-ajax-error-handling/

Are you making these 3 common ASP.NET AJAX mistakes?

2008-01-04T21:33:00.000-08:00

It’s important to remember that a partial postback is just that: A postback.

The UpdatePanel’s way of abstracting AJAX functionality behind standard WebForm methodology provides us with flexibility and familiarity. However, this also means that using an UpdatePanel requires careful attention to the ASP.NET Page Life Cycle.

In this post, I’d like to point out a few of the problems I’ve seen developers running into and what you can keep in mind to avoid them:

Page events still fire during partial postbacks.
UpdatePanel events fire, even when not updating.
Control event handlers fire after Load events.

Find more details:
http://encosia.com/2007/10/24/are-you-making-these-3-common-aspnet-ajax-mistakes/

Why ASP.NET AJAX UpdatePanels are dangerous

2008-01-04T21:21:00.000-08:00

The UpdatePanel makes AJAX trivially easy for anyone to implement, even without knowledge of what’s actually going on behind the scenes. Unfortunately, that very lack of transparency regarding the mechanics of the client/server exchange makes it all too easy to shoot yourself (or your application) in the foot.

Web methods allow ASP.NET AJAX pages to directly execute a page’s static methods, using JSON (JavaScript Object Notation). JSON is basically a minimalistic version of SOAP, which is perfectly suited for light weight communication between client and server. For more information about how to implement web methods and JSON, take a look at Microsoft’s Exposing Web Services to Client Script in ASP.NET AJAX.

Using JSON, the entire HTTP round trip is 24 bytes, as compared to 872 bytes for the UpdatePanel. That’s roughly a 4,000% improvement, which will only continue to increase with the complexity of the page.

Not only has this reduced our network footprint dramatically, but it eliminates the necessity for the server to instantiate the UpdatePanel’s controls and take them through their life cycles to render the HTML sent back to the browser.

find more details :
http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/

Debugging client JavaScript in Visual Studio 2005

2008-01-04T21:00:00.000-08:00

Client Java Script is one of the most important things in web development but not the best and easiest to develop. Building of bigger and more complicated scripts, especially using DOM model or form field values can cause a lot of frustration and head pain. Moreover, JavaScript debugging is not easy and obvious as should be. But there is a hope.

One of less known features of Visual Studio 2005 is Script Explorer, hidden in Debug menu where appears only when the debugger is running. This great tool allows easily debug JavaScripts.

Before start, we should ensure that client script debugging is not disabled in IE as it is by default. Suitable options are located on Advanced tab of Internet Options where both script debugging checkboxes should be unchecked.

We can come back to Script Explorer. As it was written before, it appears only while the debugger is working. So after starting project we can go do Debug->Windows where should be Script Explorer. Sometimes, don’t know why, it doesn’t so in this case we have to find it manually. Staying in debug mode right click on tool bar and go into Customize. Then select Debug in Categories on the left side of window and find Script Explorer on the right. Just drag it to Debugging toolbar.

After opening Script Explorer panel we will se the tree of active JavaScripts. At the first level are scripts that are imported from external sources or embedded in the page. There are also auto-generated scripts like postback scripts as well. By double-clicking on the selected script it will open in the main window.

At this moment, we can debug it in well known way using breakpoints, steps, Watch and QuickWatch, just like in the server side, including context browsing of a variable.

Breakpoints can also be set up in external *.js files before project will be loaded. Then, after loading project, the breakpoint will be activated by debugger. Note, that it is only possible to *.js files not for scripts embedded in pages. These scripts are available for debugging only after loading page.

Hope it helps.

Provider Design Pattern Overview

2008-01-04T04:36:00.000-08:00

The Provider Model Design Pattern was first introduced with the .NET 1.1 framework, specifically in the ASP.NET starter kits and was formalized in ASP.NET Whidbey as a membership management provider API (Application Program Interface). It's primary purpose is to separate the definition for an API from the implementation. This keeps the API flexible by enabling the core functionality to be flexible and easily changed.

More details on the origins of the pattern in the .NET 1.1 Framework can be found on MSDN:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp

and:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp

original link : http://www.c-sharpcorner.com/UploadFile/rmcochran/providerPattern08102006110013AM/providerPattern.aspx

http://blogs.clearscreen.com/migs/archive/2006/12/01/4781.aspx

WCSF: Registering services through configuration

2008-01-04T04:32:00.001-08:00

One of the requested features for the Web Client Software Factory has been the possibility to register global services through the Web.Config file. By registering the services through configuration there is no need to rebuild any module when you want to switch the concrete implementation of a service.

This is what we wanted to be able to write in the Web.Config:

<compositeWeb>
<modules>
<module name="Shell" assemblyName="MyApplication.Modules.Shell" virtualPath="~/"/>
modules>
<services>
<service registerAs="MyInterfaces.IMyService, MyInterfaces" type="MyImplementations.MyService, MyImplementations"/>
services>
compositeWeb>