In my .aspx I've written the following:
<ajaxToolkit:ComboBox ID="cmbAddressAlias" runat="server" DropDownStyle="Simple" AutoCompleteMode="Suggest" CaseSensitive="false" AutoPostBack="true" RenderMode="Inline" Width="170px" CssClass="cmbProvince" OnSelectedIndexChanged="cmbAddressAlias_SelectedIndexChanged"> </ajaxToolkit:ComboBox>
It's binding correctly (datasource dynamically binded) and it raises event too, while changing index.
However it's not raising the event when I manually clear the combobox text.
If currently combobox having text "ASP" then I manually select that entire text and using del key I am deleting but it is not raising event for me. When I change index it automatically raises the event.
I need to raise the event while combobox is empty.
You should handle this event as well "OnTextChanged" and note that it's different than "OnSelectedIndexChanged" which has been handled by you. Handle this event and it will fire when you clear the text on the combo.
And if the above does not work this post might help you.
Related
I read Microsoft's article on ASP.Net Page Life Cycle events. It confused on one thing. When Page_PreInit gets called, all the controls' Init method is not yet called. When I setup a test project, I observed a different behavior. In the mark up, I created asp label and button controls and set certain properties such as Text. I put a break point at the beginning of Page_PreInit. When break point got hit, I checked if the controls got created or not by referring to them by their Ids in the Watch window. They all existed and none returned null. Then I checked the Text property and it was what I set in the mark up. So doesn't this contradict what Microsoft says? If this is the case what do Controls' Init method do if they are already initialized? Is there something I miss?
I created asp label and button controls and set certain properties
such as Text. ... Then I checked the Text property and it was what I set
in the mark up.
If you set property value at Design Time, they are in control tree so properties are available in all events.
However, if you add a TextBox and a user clicks on submit, TextBox Text Property only start available at Page_Load event.
The reason is that Page_Load is the place where properties are loaded with information recovered from view state and control state.
Look at this example
<asp:Label runat="server" ID="Label1" Text="Name" />
<asp:TextBox runat="server" ID="TextBox1" />
<asp:PlaceHolder runat="server" ID="PlaceHolder1" />
<asp:Button runat="server" ID="SubmitButton"
Text="Submit" OnClick="SubmitButton_Click" />
After Postback,
Notice that you can only retrieve TextBox value at Page_Load event.
I reference a previous post: Focus lost on partial postback with UserControls inside UpdatePanel
where an excellent solution works perfectly for web-page controls within a form.
However, I have placed my UC inside a detailsview template-field (for Edit+Insert).
The UC contains an UpdatePanel needed to adjust the text-formatting and control's style(s) following the TextChanged event of the UC-textbox (AutoPostback=True) during the Edit-mode and Insert-modes of the DetailsView.
As such, when the DetailsView-control is in Edit-mode, and user changes Text in the UC, the textchanged event is fired and the user-entered value is validated and when OK, the thousounds-separator (comma) are added to the UC-textbox-text, BUT, the focus moves to the next field in the DetailsView and QUICKLY returns back to the UC-control.
This incorrect focus-move(s) does NOT occur when the UC is wrapped in updatepanels as noted in the referenced post since the focus and tabbing order works perfectly outside of the DetailsView control.
Here is the aspx markup for the template-field-EDIT (only).
<asp:TemplateField HeaderText="Initial Mileage" SortExpression="IMilage">
<EditItemTemplate>
<asp:UpdatePanel ID="updpnlIMilage" runat="server" UpdateMode="Conditional" >
<ContentTemplate>
<TGANumeric:GANumeric ID="ucnumIMileage" runat="server"
Caption="Initial Mileage" HideCaption="True" Width="160"
DisplayMask="999,999" InputMask="999999"
Enabled="True" IsRequired="False"
MinNumber="0" MaxNumber="999999"
Text='<%# Bind("IMilage") %>'
TabIndex="0"
/>
</ContentTemplate>
<Triggers>
<asp:AsyncPostBackTrigger ControlID="ucnumIMileage" />
</Triggers>
</asp:UpdatePanel>
</EditItemTemplate>
Thanks in advance. Your comments are welcome.
Thanks...J.
So are you saying your control hierearchy (partial) is:
UpdatePanel > TGANumeric:GANumeric > UpdatePanel > TextBox
This is an awful lot of overhead to just format a number with a comma, which is the only reason I see for your posting back. As far as I can tell there is nothing you need from the server, so why post?
Or is there?
My thoughts, lose the update panels, disable the AutoPostback on the Textbox, handle the formatting client side if it must be seen immediately, or leave the formatting to the DetailsView field DataStringFormat when it posts after save.
I'm betting this will clear up any focus issues.
Based on all the comments in this thread, I want to explain the actual root cause of the tabbing misbehavior.
1) There were no coding issues or event-issues with the user-control.
2) There were no coding issues or event-issues with the layering of Master-page, Content-page, Ajax update-panels / nested update-panels, details-view and template-fields containing the user-control.
3) The real culprit was a small snippet of code where the page adjusts the web-controls on the form based on the "state" (status) of the page/form. I manage the adjusting of visible and/or enabling of web-controls in a single subroutine in the code-behind so that all of this enabling/disabling visible/not-visible occurs in one place under a set of CASE-statements.
The actual erroneous snippet of code inside the 'sbSetFormState()'-method was messing with the class-variable 'm_eFormState' that actually caused the update panel to re-fire and thus the tabbing got thrown out of sequence.
This was discovered by the great suggestion from 'fnostro' to remove or add functionality features until the mis-behavior exposes itself.
I mark this topic as resolved/closed.
Again, thanks to fnostro !!!
I have a ASP.Net webform that has several textboxes. Some of the textboxes have an OnTextChanged event with AutoPostBack set to true.
When the user enters some text and leaves the textbox, I want some code to run. This part works fine.
The problem is that if a user enters some text, then clicks or tabs to another textbox, the OnTextChanged of the current textbox event fires fine but the textbox that the user clicked on does not keep focus. This causes problems because the user thinks they are on the next textbox but they aren't. And no object seems to have the focus.
Is there anything that can be done to make the next object keep focus while the OnTextChanged event of the current textbox fires?
One option is to use <asp:UpdatePanel> Control.
Facts about using it:
The postback request would be made via AJAX.
It would not recreate the whole page HTML.
When the UpdatePanel updates, it replaces the DIV innerHTML, that would make the textbox lose focus (bad point).
To maintain the focus, you would have to avoid the UpdatePanel from updating when the textbox posts back.
You can avoid the update by setting the UpdateMode and ChildrenAsTriggers properties.
Here is an example:
<asp:UpdatePanel ID="uppTextboxes" runat="server" UpdateMode="Conditional" ChildrenAsTriggers="false">
<ContentTemplate>
<asp:TextBox ID="txb1" runat="server" AutoPostBack="true" OnTextChanged="txb1_OnTextChanged" />
<asp:TextBox ID="txb2" runat="server" />
</ContentTemplate>
</asp:UpdatePanel>
Since the whole page is recreated on postback on serverside and the browser will recreate all html on clientside, you have to tell ASP.NET that your TextBox needs focus.
Use Page.SetFocus:
Page.SetFocus(IdOfControl);
However, i would prefer not to postback at all if i can. Can't you use a button that the user has to click after he has entered all necessary data?
I have several text boxes on a page. I want to save the text in the corresponding TextBox on LostFocus. It is to ensure the data is not lost when power failure or internet connectivity is lost. How can I accomplish something like this?
Another solution would be to use an UpdatePanel. You could then leverage server-side events rather than an event handler. You're markup might look something like this:
<asp:ScriptManager ID="ScriptManager" runat="server" />
<asp:UpdatePanel ID="UpdatePanel1" UpdateMode="Conditional" runat="server">
<asp:TextBox ID="SomeTextBox" runat="server" TextChanged="SomeTextBox_TextChanged" AutoPostBack="true" />
</asp:UpdatePanel>
</asp:ScriptManager
and then in the TextChanged handler you could do your work.
Explanation: the TextChanged event will fire on the text box in which the text was actually changed when the post back occurs. The AutoPostBack property is necessary so that the page will in fact post back when the text box loses focus.
One final thing to remember, you will probably need to leverage this.IsPostBack on the page in the Load handler because every time a control is updated it's going to reconstruct the page. It's common that logic in the Load handler only needs to execute one time, but that would pose a problem if you didn't check to see if it was a post back because then it would execute every single time you left a text box.
Use jquery.
First on attach blur event handler, where you call ajax method to server passing new value of the textbox.
Handle this ajax event on serverside and write your data to the database or anywhere else.
Here is a piece of code that may help.
$('#textbox_id').blur(function() {
$.ajax({url:"handler_url.ashx?textbox_value=" + $('#textbox_id').val()});
});
Then create your ashx handler on server and handle your requests with ProcessRequest method. From there you will have access to Request.QueryString where new value of textbox will be stored.
I am trying to attach a server-side event to lookup the city/state for the user-entered zipcode in a field like the one below.
<asp:TextBox ID="TextZipcode" runat="server" CssClass="inputtext" Columns="10" MaxLength="10"></asp:TextBox>
Since there is no lost focus event to capture, has anyone had any luck getting this to work?
Sure, why not? Just attach a JavaScript handler and have it invoke an AJAX action.