<FooterTemplate>
<asp:Label runat="server" ID="dlVideosFooter" Text="No Vidoes available at this moment for the selected category.Please try later or select another category"
Visible='<%#bool.Parse((dlBuzzVideos.Items.Count==0).ToString()) %>'></asp:Label>
</FooterTemplate>
Note:dlBuzzVideos is the datalist id.
Thursday, November 10, 2011
Trim a DataBound Linkbutton inside a DataList
<ItemTemplate>
<asp:LinkButton ID="LinkButton1" runat="server" Text='<%
getShortString(Eval("Location1")) %>'></asp:LinkButton>
</ItemTemplate>
</asp:DataList>
protected string getShortString(object value)
{
string shrtString = value.ToString();
if (shrtString.Length > 4) // Change this value to set your character limit
{
shrtString = shrtString.Substring(0, 4) + "..."; // Change this value to set your character limit
}
return (shrtString);
}
source : http://forums.asp.net/t/1521615.aspx/1
<asp:LinkButton ID="LinkButton1" runat="server" Text='<%
getShortString(Eval("Location1")) %>'></asp:LinkButton>
</ItemTemplate>
</asp:DataList>
protected string getShortString(object value)
{
string shrtString = value.ToString();
if (shrtString.Length > 4) // Change this value to set your character limit
{
shrtString = shrtString.Substring(0, 4) + "..."; // Change this value to set your character limit
}
return (shrtString);
}
source : http://forums.asp.net/t/1521615.aspx/1
Friday, August 26, 2011
How to open a page in new window using Response.Redirect
Use OnClientClick="form1.target='_blank';"
<form id="form1" runat="server">
<asp:ImageButton runat="server" ID="imgBtn" OnClick="imgBtn_Click"
OnClientClick="form1.target ='_blank';"/>
</form>
in the code behind:
protected void imgBtn_Click(object sender, ImageClickEventArgs e)
{
Response.Redirect("NewPage.aspx");
}
<form id="form1" runat="server">
<asp:ImageButton runat="server" ID="imgBtn" OnClick="imgBtn_Click"
OnClientClick="form1.target ='_blank';"/>
</form>
in the code behind:
protected void imgBtn_Click(object sender, ImageClickEventArgs e)
{
Response.Redirect("NewPage.aspx");
}
Tuesday, August 16, 2011
HOW TO PROPERLY ACCESS CONTROLS IN THE MASTER PAGE
One of the great new features in ASP.NET 2.0 has been the ability to use master pages to layout the common elements of the web site. This certainly works better than top and bottom include files or top and bottom Web User Controls. But at least with the user controls, if we wanted to access a control within it, the method to do so was pretty straight forward. All you had to do was expose the control as a public property. Or, better, create a pass through property on the control that sets or retrieves the inner control’s property. By doing this, you could turn a side bar element on or off (as an example.)
While you can expose elements of a master page in a similar manner, anyone who’s done this knows there are a few gotchas along the way. I’m going to tell you how to avoid the gotchas and you’ll have the added benefit of being able to access the controls on the master page even if you decide to use a different master page without having to change any code other than the master page directive at the top of the aspx page.
Now, just to bring everyone on to the same page, a master page is just a web user control. So, we can expose controls or properties of those controls the same way and access them from the inner page’s Master property. So, for starters, let’s say we create a master page with a table:
We’ll name the master page, MainMasterPage because MasterPage is the name of the Class that represents the master page and we’ll get ourselves into all kinds of confusion explaining this if I don’t have unique names for things.
OK. So, the next thing we want to do is make it so that we can conditionally hide the SideBar from a main page. So, to do that, we’ll want to make the TD surrounding the SideBar a runat=”Server” control and give it an ID. Might as well call it _sideBar.
Next, we’ll want to be able to turn the sidebar off. So, we’ll create a property in our MainMasterPage’s codebehind file called, SideBar and make it boolean:
public bool SideBar
{
get { return _sideBar.Visible; }
set { _sideBar.Visible = value; }
}
So, now comes the fun part. Accessing this property from the codebehind file of or aspx page.
As I mentioned before, the Page object has a Master property hanging off of it, but if we just access it directly using Page.Master, you’ll see that there is no SideBar property hanging off of it. That’s because we need to cast the Master property to a MainMasterPage before we can see the SideBar property. So, our final code to turn off the side bar from within our aspx page’s codebehind will look like:
((MainMasterPage)(Page.Master)).SideBar = false;
If you did everything correctly, you should now have a side bar that goes away. This code works 99% of the time. But, I’ve run into issues where I’ve made a change to the code and recompiled and I get an error message saying that MainMasterPage can’t be found even though all of the code is correct. No errors in the MasterPageFile or in the ASPX file. Still, it won’t build.
The only reasonable explanation for this is that .NET is doing some sort of inconsistent magic behind the scene that works most of the time but causes this error. Something like maybe changing the class name of MainMasterPage, or the namespace it lives in.
However I have found that you can completely eliminate this error by creating an interface the the defintions of your properties you’ve defined in your master page, implementing the interface on your master page, and then casting Page.Master to the interface type instead of the MainMasterPage type.
So, create the interface:
public interface IMainMasterPage
{ public bool SideBar { get;set;} }
Implement it on MainMasterPage:
public partial class MainMasterPage : System.Web.UI.MasterPage,
IMainMasterPage
{
protected void Page_Load(object sender, EventArgs e) { }
public bool SideBar
{
get { return _sideBar.Visible; }
set { _sideBar.Visible = value; }
}
}
And, change our cast:
((IMainMasterPage)(Page.Master)).SideBar = false;
You now have the added advantage of being able to create another master page, applying the same interface and implementing the SideBar property on it and you can either change the master page in design view or write code to change it dynamically and the code will still work. Without the interface, this change would require you to change the codebehind in each page that accessed the SideBar property.
source : how-to-properly-access-controls-in-the-master-page
While you can expose elements of a master page in a similar manner, anyone who’s done this knows there are a few gotchas along the way. I’m going to tell you how to avoid the gotchas and you’ll have the added benefit of being able to access the controls on the master page even if you decide to use a different master page without having to change any code other than the master page directive at the top of the aspx page.
Now, just to bring everyone on to the same page, a master page is just a web user control. So, we can expose controls or properties of those controls the same way and access them from the inner page’s Master property. So, for starters, let’s say we create a master page with a table:
| Header | |
| Content Area | SideBar |
| Footer
| |
We’ll name the master page, MainMasterPage because MasterPage is the name of the Class that represents the master page and we’ll get ourselves into all kinds of confusion explaining this if I don’t have unique names for things.
OK. So, the next thing we want to do is make it so that we can conditionally hide the SideBar from a main page. So, to do that, we’ll want to make the TD surrounding the SideBar a runat=”Server” control and give it an ID. Might as well call it _sideBar.
Next, we’ll want to be able to turn the sidebar off. So, we’ll create a property in our MainMasterPage’s codebehind file called, SideBar and make it boolean:
public bool SideBar
{
get { return _sideBar.Visible; }
set { _sideBar.Visible = value; }
}
So, now comes the fun part. Accessing this property from the codebehind file of or aspx page.
As I mentioned before, the Page object has a Master property hanging off of it, but if we just access it directly using Page.Master, you’ll see that there is no SideBar property hanging off of it. That’s because we need to cast the Master property to a MainMasterPage before we can see the SideBar property. So, our final code to turn off the side bar from within our aspx page’s codebehind will look like:
((MainMasterPage)(Page.Master)).SideBar = false;
If you did everything correctly, you should now have a side bar that goes away. This code works 99% of the time. But, I’ve run into issues where I’ve made a change to the code and recompiled and I get an error message saying that MainMasterPage can’t be found even though all of the code is correct. No errors in the MasterPageFile or in the ASPX file. Still, it won’t build.
The only reasonable explanation for this is that .NET is doing some sort of inconsistent magic behind the scene that works most of the time but causes this error. Something like maybe changing the class name of MainMasterPage, or the namespace it lives in.
However I have found that you can completely eliminate this error by creating an interface the the defintions of your properties you’ve defined in your master page, implementing the interface on your master page, and then casting Page.Master to the interface type instead of the MainMasterPage type.
So, create the interface:
public interface IMainMasterPage
{ public bool SideBar { get;set;} }
Implement it on MainMasterPage:
public partial class MainMasterPage : System.Web.UI.MasterPage,
IMainMasterPage
{
protected void Page_Load(object sender, EventArgs e) { }
public bool SideBar
{
get { return _sideBar.Visible; }
set { _sideBar.Visible = value; }
}
}
And, change our cast:
((IMainMasterPage)(Page.Master)).SideBar = false;
You now have the added advantage of being able to create another master page, applying the same interface and implementing the SideBar property on it and you can either change the master page in design view or write code to change it dynamically and the code will still work. Without the interface, this change would require you to change the codebehind in each page that accessed the SideBar property.
source : how-to-properly-access-controls-in-the-master-page
Friday, July 1, 2011
Displaying Pageresults of a Gridview/Datalist
lblPageinfo.Text="Showing results: " + (_PageDataSource.CurrentPageIndex * _PageDataSource.PageSize + 1) + "-" + (_PageDataSource.CurrentPageIndex * _PageDataSource.PageSize + dlSearchJobs.Items.Count) + " of " + _PageDataSource.DataSourceCount ;
- where _PageDataSource is the object of PagedDataSource class
- PagedDataSource _PageDataSource = new PagedDataSource();
- dlSearchJobs is the Datalist used to display results from DB
output : Showing results: 1-10 of 43
if using GRIDVIEW
lblPageinfo.Text="Showing results: " +(gvInbox.PageIndex) * gvInbox.PageSize + 1) + "-" + (gvInbox.PageIndex* gvInbox.PageSize+ gvInbox.Rows.Count) + " of " + objData.Length ;
- where gvInbox is the Gridview
- objData is the Datasource for Gridview
Friday, June 17, 2011
Friday, February 18, 2011
Why C# doesnt support Multiple inheritance
Not just C#, infact complete CLR doesn't support mutiple inheritence. However you can achieve your functionality using interfaces.
There are several reasons for multiple inheritence in not introduced in CLR.
First and foremost, .net allows you to use mutiple languages and each of these language would behave differently on how multiple inheritence works over it. So it was difficult for designers to resolve this issue.
Also mutiple inheritence create lot of complexity in the code.
for more read Why doesn't C# support multiple inheritance?
There are several reasons for multiple inheritence in not introduced in CLR.
First and foremost, .net allows you to use mutiple languages and each of these language would behave differently on how multiple inheritence works over it. So it was difficult for designers to resolve this issue.
Also mutiple inheritence create lot of complexity in the code.
for more read Why doesn't C# support multiple inheritance?
PageLifeCycle
Page request:The page request occurs before the page life cycle begins. When the page is requested by a user, ASP.NET determines whether the page needs to be parsed and compiled (therefore beginning the life of a page), or whether a cached version of the page can be sent in response without running the page.
Start:In the start step, page properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the IsPostBack property. Additionally, during the start step, the page's UICulture property is set.
Page initialization:During page initialization, controls on the page are available and each control's UniqueID property is set. Any themes are also applied to the page. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state.
Load:During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state.
Validation:During validation, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page.
Postback event handling:If the request is a postback, any event handlers are called.
Rendering:Before rendering, view state is saved for the page and all controls. During the rendering phase, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream of the page's Response property.
Unload:Unload is called after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and any cleanup is performed.
Start:In the start step, page properties such as Request and Response are set. At this stage, the page also determines whether the request is a postback or a new request and sets the IsPostBack property. Additionally, during the start step, the page's UICulture property is set.
Page initialization:During page initialization, controls on the page are available and each control's UniqueID property is set. Any themes are also applied to the page. If the current request is a postback, the postback data has not yet been loaded and control property values have not been restored to the values from view state.
Load:During load, if the current request is a postback, control properties are loaded with information recovered from view state and control state.
Validation:During validation, the Validate method of all validator controls is called, which sets the IsValid property of individual validator controls and of the page.
Postback event handling:If the request is a postback, any event handlers are called.
Rendering:Before rendering, view state is saved for the page and all controls. During the rendering phase, the page calls the Render method for each control, providing a text writer that writes its output to the OutputStream of the page's Response property.
Unload:Unload is called after the page has been fully rendered, sent to the client, and is ready to be discarded. At this point, page properties such as Response and Request are unloaded and any cleanup is performed.
Thursday, January 27, 2011
Subscribe to:
Posts (Atom)