Need to crop or resize images before uploading, in asp.net? Sounds like the alternative to thumbnail generation in asp.net web page? Here comes a handy code using jQuery, JCrop and ASP.NET.

I have coded a shopping cart in which there was the need of uploading images to the server, and keep the sizes as required by the content of the pages. In my case I had to hard-code the size of the thumbnail I generated. But wouldn't it be lovely if the site user could crop the image and fix the required size? So I have found one very useful way to Upload and Crop Images with jQuery, JCrop and ASP.NET. I hope this will be useful for all programmers.

Upload and Crop Images with jQuery, JCrop and ASP.NET

The asp.net membership has the mechanism that it locks out a user's account if he/she tries to authenticate themselves with false password five times, by default, or within 10 minute window. The locked user can then not login.

In the MembershipUser class there is a public method UnlockUser() that you can call for any username to unlock the user, this will reset their LastLockOutdate field etc and allow the users to login using the same password.

   1: MembershipUser user = Membership.GetUser(username);

   2: user.UnlockUser();

I’ll show you how you can quickly enable ViewState compression and show you the effects it has on overall ViewState size and server performance.

How do I enable Viewstate compression?

Enabling ViewState compression with the RadCompression module really couldn’t be easier. It requires no changes to your code, no changes to your markup, and not even a change to your web.config (assuming you’ve already added the required HttpModule references). The only thing you need to do is add a new Browser file to your web project (or modify your Browser file if you’re already using one). To add a new Browser file, follow these simple steps:

• Right-click on your web project, select "Add…" > "Add ASP.NET Folder…" > "App_Browsers"
• Right-click in your new App_Browsers folder, select "Add…” > "Add New Item…" > "Browser File"
• The new browser file will have some default values, feel free to delete everything and then add this code:

   1: <browsers>

   2:  <browser refID="Default">

   3:  <controlAdapters>

   4:  <adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadHiddenFieldPageStateCompression" />

   5:  <!--Uncomment the following line to use SessionStateCompression and remove ViewState from the page-->

   6:  <!--<adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadSessionPageStateCompression" />-->

   7:  </controlAdapters>

   8:  </browser>

   9: </browsers>

And that’s it!. Run your project at this point and you’ll discover that the RadCompression module is now automatically compressing your ViewState.

How much does the compression help?

ViewState, as you probably know, is just a serialized string of data. By default, it’s not compressed, it’s not encrypted, and it’s often a bloated piece of string data that gets passed back and forth with every request to the server.

Compressing this data is an easy way to reduce your page size and reduce the number of bytes you must send and receive from the server.

To demonstrate RadCompression’s effectiveness, I created a simple page with a RadGrid that loads data from the AdventureWorks Employees table. I bound my grid declaratively to an EntityDataSource and I slowly started increasing my Grid’s page size- from 10 records to 240 per page. As the page size grew, obviously the ViewState grew.

RadCompression Efficiency

The blue bars represent the ViewState size (in KB) with RadCompression. The green bars represent the difference in the original ViewState size (i.e. total size with no compression). And the red numbers indicate the compression “efficiency” at each step (for instance, “53%” means the compressed ViewState was 53% smaller than the original).

• As the original ViewState grew, the compression became even more “efficient” (ranging from 47% to 75% compression ratios)
• In the first two tests, there was no difference between the original and the “compressed” output – more on this in a moment
• On average, RadCompression reduced ViewState size by 61%! (omitting the “0” tests)

So why are the first two tests “0%”? RadCompression actually has a “threshold” that must be passed before compression will kick-in. For smaller ViewState sizes, it doesn’t make sense to apply compression- the overhead of the processing and compression header/footer offset the small gains in overall state size. Currently, this threshold is 8KB. If your original ViewState is smaller than 8KB, RadCompression will automatically skip over it. Bigger than that, and RadCompression will automatically work.

What is the effect on server performance?

Many people will often say, “Sure you can compress ViewState, but doesn’t that add significant processing overhead on the web server?” It is true that adding compression represents extra CPU cycles and it does have an effect on server performance. With RadCompression, though, that impact is relatively small. Internally, RadCompression uses Deflate compression to compress and decompress state, which is much faster than Gzip compression. And thanks to the optimizations of the compression APIs in .NET, the overall effect on server processing time is low.

This may be one of the easiest ways to help reduce your page size, and in turn, help improve your page performance. By simply registering the RadCompression HttpModule and adding a .browser file to your project, you can see reductions of over 70% in your ViewState size with little impact on your server performance. Clearly, as developers we should all be taking active steps to reduce our ViewState size, but if you’ve already done everything you can (or at least everything you have time for) and you want to squeeze a few more KB out of your page, RadCompression is ready and waiting for you in your Telerik toolbox.

At first glance, it should be easy to inject a javascript, but it took a little bit of digging around to figure out the resolution, the key is to use ScriptManager.

   1: <asp:UpdatePanel ID="myUpdatePanel" UpdateMode="Conditional" runat="server">

   2:    <Triggers>

   3:       <asp:AsyncPostBackTrigger ControlID="btnClick" EventName="Click" />

   4:    </Triggers>

   5:    <ContentTemplate>

   6:        <asp:ImageButton 

   7:           ID="btnClick" 

   8:           ImageUrl="ClickMe.png" 

   9:           runat="server"

  10:           CausesValidation="false" 

  11:           OnClick="btnClickEvent"

  12:           ToolTip="Click Me" 

  13:           AlternateText="Click me!" />

  14:    </ContentTemplate>

  15: </asp:UpdatePanel>

We wanted to dynamically inject some JavaScript code. If my ScriptManager control has EnablePartialRendering set to true, it's a simple matter of registering the script. What i didn't realize earlier was that you don't need to the use the current page or current event, you need to call the static method on the ScriptManager class.

   1: protected void btnClickEvent(object sender, ImageClickEventArgs e)

   2: {

   3:    btnClick.Text = "I was clicked."

   4:    btnClick.Disabled = true;

   5:    ScriptManager.RegisterClientScriptBlock(myUpdatePanel, typeof(UpdatePanel),myUpdatePanel.ClientID, "alert('It worked!');",true);            

   6: }

That's it! Use the ScriptManager class, point it to the instance of your update panel, pass it a unique key and then the JavaScript you want, and it will be executed once the update panel is done rendering.

First off, the code-behind model has changed. In the @Page directive, accessing your code behind is accomplish via the CodeFile attribute instead of the Code behind or Src attribute. Also much of the used to DataGrid properties have changed, as seen below:

The CurrentPageIndex which gets or sets the index of the currently displayed page is now simply PageIndex. Setting up paging and sorting in the Gridview has changed from the OnPageIndexChanged and OnSortCommand methods to OnPageIndexChanging and OnSorting, respectively. The primary key field for the items displayed in the GridView has also changed from DataKeyField to DataKeyNames property.

Setting up row colors on the grid is no more SelectedItemStyle or ItemStyle but rather SelectedRowStyle and RowStyle. I guess this makes more sense since it is a row, anyway. The TemplateColumn class that displays custom content in a data-bound control is now TemplateField, and its partner the BoundColumn which represents a field that is displayed as text in a data-bound control is now called BoundField.

Next, in our code-behind, .NET 2.0 utilizes a new language feature known as a Partial. A Partial class is just that, a partial, incomplete definition of the class or structure. So all that is included in the partial class in only the code needed, such as event handlers and the like. .NET infers the control instances and it derives the events bound from the .aspx file during compilation. Notice in the code behind I didn’t have to declare the GridView or the OutputMsg controls there, as I did in the DataGrid version, neither did I need to include most of the Imports statements that were there before!

Another change in the framework went to the RegisterClientScriptBlock method, this now obsolete method needs to be ClientScript.RegisterClientScriptBlock (Type type, string key, string script) or in our code ClientScript.RegisterClientScriptBlock (Me.GetType(),”clientScript”, jsScript.ToString()).

As for implementing custom paging, this also has changed its class wording from DataGridPageChangedEventArgs to GridViewPageEventArgs.

In Short the main diffrence betbeen GridView and DataGrid is:
Sorting: In DataGrid code requires to handle the SortCommand event and rebind grid required. In case of GridView no additional code required.
Paging: In DataGrid requires code to handle the PageIndexChanged event and rebind grid required. In case of GridView no additional code required. It also supports customized appearance.
Data binding: Like GridView DataGrid cannot bind with new datasource control in ASP.NET 2.0. Updating data:  DataGrid requires extensive code to update operation on data. GridView  requires little code. Code like exceptions handling for database part.
Events: GridView supports events fired before and after database updates. In DataGrid less events supported as compared to GridView.