I'm currently building a user control that displays a message when a Repeater is empty.
The idea is simple, provide the user control with the ID of the Repeater. When the user control is rendered look up the Repeater and check Items.Count. If it's zero then display the message.
I would like to add one more feature though. I want to be able to hide the Repeater if there are no Items.
Obviously I can't do this in protected override void Render(HtmlTextWriter writer) because the Repeater has (possibly) already been rendered. I also can't do this when the the Repeater ID is assigned to the user control, as the databinding hasn't happened yet.
So my question is.. what event can I override in my user control where databinding has occurred, but rendering has not.
Consider the Page's PreRender event. That way binding has happened but nothing has yet been rendered although they are just about to.
Related
Allright so I have a slight issue when I want to load some basic usercontrols which contain an UpdatePanel inside to another page which is an usercontrol.
The set up:
Whenever an user clicks on a button a pop-up shows up containing some basic info on a certain person and a tab which contains the companies he worked for. The amount of companies he/she works for can range from 1 to 4~, so I do a query then for each company I get I add a view to a multiview, this view contains multiple simple user controls (Textfields inside an updatepanel). Now whenever I go to the page I get this error:
Cannot unregister UpdatePanel with ID 'UpdatePanel2' since it was not registered with the ScriptManager. This might occur if the UpdatePanel was removed from the control tree and later added again, which is not supported. Parameter name: updatePanel
Now I know this is a common error caused by generating UpdatePanels dynamically which aren't registered with the ScriptMaster. I can't add a PreInit event handler to the page which adds the UserControls with the UpdatePanels since it's an UserControl itself.
My question is:
How can I get rid of this nasty error in a not so nasty way e.g. not a hardcoded sub routine which adds the UpdatePanel to the scriptmaster
You could define the functionality you want to add inside your user controls. I have done the same in the past, adding the following, inside of my user control.
override protected void OnInit(EventArgs e) {
// your code here
}
Add a ScriptManager on your MasterPage before the UpdatePanel. And your updatePanel is a bit confusing so might change it as well. :)
The scenario:
I have some JSON data which I'm using to load stored-data into fields on my form. One of these fields is a DropDownList. The DropDownList happens to be in a child, of a child ASCX control, which I'm accessing from a parent ASPX page. When this DropDownList has its SelectedIndexChanged, it makes other fields visible on the form.
I'm using one of my functions to find this control, which is working successfully, but when setting the SelectedValue of my DropDownList control, the SelectedIndexChanged event is not firing. Meaning some fields aren't loading, resulting in some JSON data not being loaded and lost.
I have seen a suggestion of simply calling ddl_SelectedIndexChange(sender, args) function, but the page I'm calling dynamically loads hundreds of child controls depending on the current request, so was wondering if there is a way of invoking the SelectedIndexChanged event (if it exists) for a control, without having to search and manually call the ddl_SelectedIndexChanged() function. Is it possible?
DirectCast(WebUtils.ControlFinder(upMain, f.fieldClientID), DropDownList).SelectedValue = f.fieldData.ToUpper()
I hope it makes sense. Sorry if I haven't made this clear enough.
I ended up using Reflection to Invoke the properties event that I required, worked a treat.
I am using a FormView to select companies from a database. This FormView is bound to an ObjectDataSource, which is bound to a DropDownList. When a user selects a company from the DropDownList, the FormView is populated with information pertaining to the company (AutoPostBack is enabled on the DropDownList to provide dynamic record changing). My FormView supports insert, update, and delete functions, of which all three work.
My problem is as follows: After I edit a record in the FormView, the record successfully changes, however, it is completely removed from the screen. Only after I select a new company from my DropDownList will a record re-display in the FormView.
Does anyone have an idea as to what may be the issue here?
You need to databind again.
void FormView_ItemInserted(Object sender, FormViewInsertedEventArgs e)
{
Gridview.Databind();
}
You need to trigger the child control to be databound when the parent control has been modified.
I've found that the most reliable palce to do this is in the parent control's DataBound event. After a successful edit, this event is called, because the control needs to re-bind to the edited data.
Here's a snippet from some actual code of mine where I do something similar. In it, I have a control called QuestionGroupResutls that has child records in a control called QuestionResults.
void QuestionGroupResults_DataBound(object sender, EventArgs e)
{
QuestionGroupsEditingDetailsView1.DataBind();
QuestionResults.DataBind();
}
I have this in Page_Load, but you can specify this declaratively in the asmx (I just don't have a code sample).
QuestionGroupResults.DataBound += new EventHandler(QuestionGroupResults_DataBound);
I don't know the name of your controls, but you should be able to do the same thing with yours.
I've been getting this exception in my code and wondered if anyone could help me out.
I have a Repeater Control bound to an ObjectDataSource, and the itemtemplate for the repeater contains a User Control (ASCX). This user control in turn contains several other controls, mainly a GridView that is associated with an ObjectDataSource.
On initial use of the controls in this setup, everything works great - data displays properly. However, when I change a filter option (dropdowns outside of the repeater), and then rebind the Repeater, I get the exception:
The ObjectDataSource control 'expDataSource' does not have a naming container. Ensure that the control is added to the page before calling DataBind."
at System.Web.UI.WebControls.DataBoundControlHelper.FindControl(Control control, String controlID)
...
...
at System.Web.UI.WebControls.ObjectDataSource.LoadCompleteEventHandler(Object sender, EventArgs e)
I'm not sure what the problem is - I've read in a few places that moving the datasource outside of the ASCX control might help - this does nothing. The objectdatasource appears to be properly structured, and as I said, it works the first time (only).
I noticed in the stack trace for the exception that this is occurring when ASP.NET is calling FindControl() after LoadComplete() occurs. If I step through my code, it appears as though all my code is finished executing before this happens, so it's all "system" code.
Why would ASP.NET not be able to find this datasource control in the LoadComplete Handler?
Thanks!
Other Notes:
This error occurs every other time. So the first time the data loads properly, then on second refresh fails with this error. Clicking "Load" again, it works (on the third time).
On the times that it fails, it looks like "Page_Load" is being called twice in the ASCX control. So the patterns are:
Working Pattern:
Page_Load on Parent Page
Page_Load on ASCX
Data Loads fine
Failing Pattern:
Page_Load on Parent Page
Page_Load on ASCX
Page_Load on ASCX
Exception
This is all happening from a call to "Repeater.DataBind()", but it behaves differently depending on if it has already been bound or not (evidently).
More Notes:
Real strange behavior. I removed the list of SelectParameters from the bottom of the ObjectDataSource, and all of a sudden, the page does not reject the ObjectDataSource as not having a NamingContainer. Of course, without these parameters, Databinding won't actually work...I can add them in the code, but why would it matter?
Found a strange solution, that I'll post and we can discuss to maybe figure out why this fixed it.
On my page, I had the following structure (paraphrasing the tags somewhat):
Page
DropDownFilter
Repeater
UserControl X
ObjectDataSource
ControlParameters Referencing DropDownFilter
End ObjectDataSource
End UserControl X
End Repeater
End Page
So as you can see, within the Repeater ItemTemplate was the user control, which in turn had the "guilty" ObjectDataSource with ControlParameters. These control parameters had the name of the DropDownList filter on the parent page referenced (so basically, if this control was added to any other page, it would of course fail if it couldn't find a control with the proper name).
So when I went through and changed all the ControlParameters to Parameters (removed the reference to that DropDownList control), now I no longer get the error.
All I can assume is that the fact that this datasource referenced a control on the parent page meant that it was having trouble getting added back to the page's control set on a DataBind(). You would have thought it would fail the first time if it was going to fail at all, so that's still a mystery.
Any thoughts?
This is an exceptional error in ASP.NET DataControls. I had similar problem and lost few months behind this eccentric error, but finally got the solution. The reason is; To display items in ItemTemplate, we should use a server control in the LayoutTemplate to act as the placeholder for the ItemTemplate. For example, we could use a Table/Div control with an ID Property in Layout Template. At run time, this placeholder control will be replaced with the contents of the ItemTemplate and "naming container error" will be disappeared.
Finally, if you are having an objectDataSource in ItemTemplate, make sure that you added somthing(like table/Div) with "Id" property in Layout Template.
Thanks,
Sunil.
Ray hit the nail on the head. You are definitely missing an "if(!IsPostBack)" somewhere. How are you adding the user control to the repeater? Is it dynamic? You say it's in the ItemTemplate, so probably not... But multiple calls to Page_Load imply multiple copies of the control.
Use both DataBind. Example:
SqlDataSource1.DataBind();
ListView1.DataBind();
I have a textbox and button on my .aspx page. The EnableViewState property of the textbox is set to false. But when I enter some text in the textbox and click the button the entered text is still present in the textbox. I expect the textbox to be blank since EnableViewState is set to false. Am I missing something?
Please check this Code Project article to better understand ViewState and Postback Data.
It is something like :
Why some controls retain values
even after disabling the ViewState
while others do not?
The answer is Controls which
implements IPostBackEventHandler IPostBackDataHandler like
Textbox, Checkbox, etc. will retain
the state even after disabling the
viewstate. The reason is during the
Load Postback Data stage, these
controls will get state information
from Posted back form.
But controls like label which do not
implement IPostBackEventHandler IPostBackDataHandler will
not get any state information from
posted back data and hence depend
entirely on viewstate to maintain the
state.
Below is related paragraph to your question.
In page life cycle, two events are
associated with ViewState:
Load View State: This stage follows the initialization stage of
page lifecycle. During this stage,
ViewState information saved in the
previous postback is loaded into
controls. As there is no need to check
and load previous data, when the page
is loaded for the first time this
stage will not happen. On subsequent
postback of the page as there may be
previous data for the controls, the
page will go through this stage.
Save View State: This stage precedes the render stage of the page.
During this stage, current state
(value) of controls is serialized into
64 bit encoded string and persisted in
the hidden control (__ViewState) in
the page.
Load Postback Data stage: Though this stage has nothing to do with
ViewState, it causes most of the
misconception among developers. This
stage only happens when the page has
been posted back. ASP.NET controls
which implement IPostBackEventHandler IPostBackDataHandler
will update its value (state) from the
appropriate postback data. The
important things to note about this
stage are as follows:
State (value) of controls are NOT retrieved from ViewState but from
posted back form.
Page class will hand over the posted back data to only those
controls which implement
IPostBackEventHandler IPostBackDataHandler.
This stage follows the Load View State stage, in other words state of
controls set during the Load View
State stage will be overwritten in
this stage.
This is by design
The following server controls persist their information across requests even when the control ViewState (the EnableViewState attribute) is set to False:
* The TextBox control.
* The CheckBox control.
* The RadioButton control.
This behavior occurs because the ViewState of a control is only one of the methods that are used to persist a control's attributes across requests. In the server controls that are mentioned in the "Symptoms" section, attributes that are not normally posted to the server through the form-get or the form-post are handled by the ViewState. These values include attributes of the control, such as BackColor. Attributes that are normally posted to the server are handled by the IPostBackDataHandler interface. An example of such an attribute is the checked attribute of the CheckBox control.
Also read this article
ASP.NET: TextBox and EnableViewState="False"
For understanding of Viewstate I don't think there is a better article than MSDN
Understanding ASP.NET View State
Take a look at Server controls persist their state when EnableViewState is set to False
The following server controls persist their information across requests even when the control ViewState (the EnableViewState attribute) is set to False:
The TextBox control.
The CheckBox control.
The RadioButton control.
This behavior occurs because the ViewState of a control is only one of the methods that are used to persist a control's attributes across requests. In the server controls that are mentioned, attributes that are not normally posted to the server through the form-get or the form-post are handled by the ViewState. These values include attributes of the control, such as BackColor.
Attributes that are normally posted to the server are handled by the IPostBackDataHandler interface. An example of such an attribute is the checked attribute of the CheckBox control.
Example: Consider backcolor setting programmatically. On postback, if viewstate is switched off, the background color of the Textbox control is lost. However, the text value of the control is maintained.
Note: If the backcolor was set directly in markup rather than in code behind, it would have persisted.
<form id="form1" runat="server">
<asp:TextBox ID="Textbox1" runat="server" EnableViewState="false"></asp:TextBox>
<asp:Button ID="Button1" runat="server" Text="Button" EnableViewState="false" />
</form>
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
this.Textbox1.BackColor = Color.Yellow;
}
}
Following is from Understanding ASP.NET View State:
It is a common misconception among developers that view state is somehow responsible for having TextBoxes, CheckBoxes, DropDownLists, and other Web controls remember their values across postback. This is not the case, as the values are identified via posted back form field values, and assigned in the LoadPostData() method for those controls that implement IPostBackDataHandler.
A server control can indicate that it is interested in examining the posted back data by implementing the IPostBackDataHandler interface. In this stage in the page life cycle, the Page class enumerates the posted back form fields, and searches for the corresponding server control. If it finds the control, it checks to see if the control implements the IPostBackDataHandler interface. If it does, it hands off the appropriate postback data to the server control by calling the control's LoadPostData() method. The server control would then update its state based on this postback data.
Also refer following
View State for TextBox and other controls that implement IPostBackDataHandler
How do I disable viewstate for a specific control?