I have a button declared like this:
<asp:Button id=Send runat="server" EnableViewState="False"
ToolTip="Email me this report" CssClass="Button" Text="Email me this report">
</asp:Button>
But if I do Inspect Element in browser, it shows like this:
<input type="submit" class="Button" title="Email me this report"
id="ctl03_Toolbar_Send" onclick="javascript:WebForm_DoPostBackWithOptions(new
WebForm_PostBackOptions("ctl03$Toolbar$Send","", true, "", "";, false, false))"
value="Email me this report" name="ctl03$Toolbar$Send">
I wonder where the onclick event comes from? What does it do?
Thanks for your help in advance.
If you set the PostBackUrl property for the Button server control, then it means it is cross page posting and then asp.net framework instead of normal __DoPostBack() adds "WebForm_DoPostBackWithOptions". Check if you have "PostBackUrl" Property set for this button.
<asp:Button id=Send runat="server" EnableViewState="False" PostBackUrl="~/Page2.aspx"
ToolTip="Email me this report" CssClass="Button" Text="Email me this report">
</asp:Button>
If in your case you have not set the "PostBackUrl", then ASP.NET framework also does not add this by default for Button Control, so this means there has to be another control setting the OnClick attribute value probably using following sever side code -
PostBackOptions myPostBackOptions = new PostBackOptions(this);
myPostBackOptions.ActionUrl = "Page2.aspx";
myPostBackOptions.AutoPostBack = false;
myPostBackOptions.RequiresJavaScriptProtocol = true;
myPostBackOptions.PerformValidation = true;
// Add the client-side script to the HyperLink1 control.
Button1.OnClientClick = Page.ClientScript.GetPostBackEventReference(myPostBackOptions);
Understand that there's no such thing as "ASP.NET Controls" in the rendered HTML that the web server outputs in response to a user's request. All the ASP.NET controls do is render some HTML in a way that makes everything work as expected on the server. The Button control is emitting the "onclick" attribute in order to trigger some JavaScript that will result in the form data being posted back to the server (assuming any client side validators don't prevent it).
The reason for using this method to send the data back is, as I just mentioned, to give any client-side script a chance to run first, such as data validation controls that can check and see if any required fields are not filled out.
Basically, unless you're looking to create your own ASP.NET server controls, you don't need to worry too much about exactly what is getting emitted as the ultimate response from IIS. It's good to be familiar with what's happening (and I'm certainly not saying that you shouldn't learn exactly how server controls do their thing), but you don't have to be intimately familiar with every client-side call and parameter that ASP.NET is making in order to get started.
Remove "EnableViewState="False" and it should use the default PostBack.
When you set button to not store state, it will use this option instead which is wired to the page_load javascript event differently on the page.
Also if there is some validation control on the page this can cause it as well. Set the CausesValidation property of the button to false.
<asp:button runat="server" ID="test" CausesValidation ="false" />
Related
I have created specific code that allow a user to load a dialog to specify some search criterias.
The code that call the dialog is
<i class="fa fa-fw fa-dot-circle-o"
onclick="PF('LoadLabelHomoVectoDialog').show();"
/>
<p:inputText
id="CertificationCodeId"
value="#{vC.postLabellingSearchCriteria.certificationCode}"
readonly="true"
/>
The user click on icon and dialogbox is displayed.
The user make some action in dialog, click on OK button and CertificationCodeId inputText widget is filled directly using Javascript. I can see specific value in it.
Then on main page (not more in dialog), I click on SEARCH button to start a new search using criteria value found in CertificationCodeId inputText widget.
If readonly attribute equal "false", the widget value is correctly transmitted to ViewController on server.
If readonly attribute equal "true", the widget value is NOT transmitted to ViewController on server.
I thought that readonly attribute is only to prohibit user input, but not to prohibit value to be transmitted to server.
What do I wrong ?
Is that a Primefaces issue ?
There exists a answer to my problem to Validate readonly components anyway on form submit that is disctinct from what is proposed !!! What is proposed is a duplicate of the link I propose :-)
JSF and PrimeFaces do not process values when inputs are disabled or readOnly for security purposes. So even a hacker enables the input and submits the form, JSF-PrimeFaces checks the component. So it is standard behavior. You need to enable it on server side.
Found here: https://forum.primefaces.org/viewtopic.php?t=15632
Because I will that visible inputText is READ-ONLY, the only solution is to duplicate READ-ONLY inputText like this ...
<i class="fa fa-fw fa-dot-circle-o"
onclick="PF('LoadLabelHomoVectoDialog').show();"
/>
<p:inputText
id="CertificationCodeId"
value="#{vC.postLabellingSearchCriteria.certificationCode}"
readonly="true"
/>
<p:inputText
id="CertificationCodeIdBecauseJSFdontSentReadOnlyWidgetValueToServer"
value="#{vC.postLabellingSearchCriteria.certificationCode}"
style="display:none"
/>
The value of second widget is sent to server because it is not disabled or read-only.
In Javascript code, I must assign the two widget.
JSF and PrimeFaces do not process values when inputs are disabled or
readOnly for security purposes. So even a hacker enables the input and
submits the form, JSF-PrimeFaces checks the component.
I think now, that issue that JSF/Primefaces want to avoid, is always there because an hacker can change content of the hidden widget.
The only thing I see is that the code is more complex and less readable :-)
Why to do simple when it is possible to do complex ?
I hope I can explain this properly.
I have a page in ASP.net (3.5) containing a GridView. I have implemented jquery to freeze columns and headers of the GridView (the jquery I implemented can be found here: http://gridviewscroll.aspcity.idv.tw/).
Now, the frustrating part. Any control I place on the page, above the GridView maintains view state on post back. Any control following the GridView loses view state on post back.
<asp:TextBox ID="tbx_Value1" runat="server" />
<asp:TextBox ID="tbx_Value2" runat="server" />
<asp:GridView ID="gv_Data" runat="server" />
<asp:TextBox ID="tbx_Value3" runat="server" />
So, on post back the view state of tbx_Value1, tbx_Value2 and the GridView are retained, but the view state of tbx_ValueValue3 is lost. Setting EnableViewState="true" does not improve the situation.
The JQuery download is called in the following javascript:
<script type="text/javascript">
var c = 0;
c = '<%=this.col %>';
$(document).ready(function() {
gridviewScroll(c);
});
function gridviewScroll(c) {
$('#<%=gv_Data.ClientID%>').gridviewScroll({
width: 1350,
height: 330,
freezesize: c,
arrowsize: 30,
varrowtopimg: "../../../images/arrowvt.png",
varrowbottomimg: "../../../images/arrowvb.png",
harrowleftimg: "../../../images/arrowhl.png",
harrowrightimg: "../../../images/arrowhr.png",
headerrowcount: 1
});
}
</script>
I am at a loss as to how to address this. I have moved my controls around, recreated the page, rebuilt the application. All of this returns the same result. So, I can only assume it has something to do with the javascript (or jquery download I am using). Perhaps when it is applied in the page life cycle? Javascript/jquery is not my strong point, so any help would be greatly appreciated.
Thank you.
I found the culprit to this query. The Gridview in this situation is dynamically created based on user input. I did not fathom anyone would request or need a very large GridView. However, when they did, the nature of this Gridview being what it is, resulted in a lot of controls being created.
Once I realized this was happening I updated the web.config appSettings key: "aspnet:MaxHttpCollectionKeys" to a larger number, but also restricted the size a user can request.
I arrived at this solution by way of this post:
'Operation is not valid due to the current state of the object' error during postback
Iv tried many things (JS/Jquery) to disable this AsyncFileUpload but none are working...please advise..
<ajaxToolkit:AsyncFileUpload OnClientUploadError="uploadError"
OnClientUploadComplete="ajaxUploadImage_ClientUploadComplete" runat="server"
ID="ajaxUploadImage" Width="400px" UploaderStyle="Modern"
CompleteBackColor = "White"
UploadingBackColor="#CCFFFF" ThrobberID="imgLoader"
OnUploadedComplete = "ajaxUploadImage_OnUploadComplete"
OnClientUploadStarted="AssemblyFileUpload_Started"
/>
var upload = $$('ajaxUploadImage');
upload.enableSelection('false');
var upload = $$('ajaxUploadImage');
upload.enableSelection('false');
upload.disableSelection();
document.getElementById("ctl00_MainContent_MapUserControl_ajaxUploadImage").disabled = true;
So...iv tried using the ID assigned by me..iv tried using the ID assigned in the browser....what am I doing wrong? user can still click of the text box or the select button and the pictures folder pops up, allowing the user to select an image for upload
should note that iv also tried disabling it from code behind
ajaxUploadImage.Enabled = false;
Have also tried setting disabled="true" inside the control, and checking the control in developer tools it is disabled, but I can still click on the text box or button and the pictures folder opens
The control emits its own markup and is hard to manage.
You can try set Visible=false, because its logic runs every time the page is loaded and the control is visible.
I have been putting my head into the disabling part and it seems we can surely disable the AsyncFileUpload control.
The trick is, ajax toolkit re-assigns the ids to the its controls, so whatever your id is, it will re-assign a new id to it even if you are using <%= control.ClientID %> this approach to get the names of the control.
So, I would suggest you inspect the element in the browser and copy the element ID from there.
My Scenario:
This was my control in the markup:
<asp:AsyncFileUpload CssClass="custom-file-input" ID="fileupload" runat="server" OnUploadedFileError="fileupload_UploadedFileError" OnUploadedComplete="fileupload_UploadedComplete" />
Notice, My control's ID is fileupload. And this is how I was disabling it before:
$('#<%= fileupload.ClientID %>').attr('disabled', true);
Which obviously never worked because $('#<%= fileupload.ClientID %>') this returned me the ID as #fileupload which is not correct because originally, ajaxtoolkit had modified it from #fileupload to #fileupload_ctl02 so, I had to hard code the ID in my javascript to get it working. e.g:
$('#fileupload_ctl02').attr('disabled', true); // I am using an older version of jQuery,
For newer versions of jQuery, you would disable it using the prop() method instead.
JS
document.getElementById('fileupload_ctl02').disabled = true;
Hope it helps someone.
I have a set of server side combo boxes in a table. Based on client events, I need them to appear or disappear. I've tried the following with no success:
document.getElementById("cboToothNumber").style.visibility = "hidden";
$("#cboToothNumber").hide()
Any ideas? Also, this will need to work from a js file
You don't want the ASP.NET ID, you want the client id, so try
$("#<%=cboToothNumber.ClientID%>").hide()
From a JS file, this won't work. You can use the same code to get the ClientID and set it as a variable or pass it into a function in the Javascript file though.
Have you checked the ID of the combo boxes once the page has rendered? The Id of the element might be changing due to it being serverside.
If you are using .net 4 - there is a way to disable the ClientId by setting the ClientIdMode.
<asp:Label ID="Label1" runat="server" ClientIDMode="[Mode Type]" />
Check out these links:
http://weblogs.asp.net/scottgu/archive/2010/03/30/cleaner-html-markup-with-asp-net-4-web-forms-client-ids-vs-2010-and-net-4-0-series.aspx
http://weblogs.asp.net/asptest/archive/2009/01/06/asp-net-4-0-clientid-overview.aspx
A required field validator seems to always to fire when the associated textbox is disabled (whether the textbox contains text or not).
When the textbox is enabled the validator behaves correctly.
Can anybody tell me why?
I've tried disabling the required field validator with ValidatorEnable but that seems to make no difference.
Here's the relevant HTML from the page (cut down):
<tr id="trBrokerNetID" runat="server">
<td>
<cc1:mitextbox id="txtBrokerNetID" runat="server" cssclass="bodytext" width="220px" maxlength="20" onBlur="JavaScript:CheckBrokerBranch(false);"></cc1:mitextbox>
<asp:requiredfieldvalidator id="rfvBrokerNetID" runat="server" width="1px" errormessage="BrokerNetID - Please supply a value" controltovalidate="txtBrokerNetID">*</asp:requiredfieldvalidator>
</td>
</tr>
Any ideas gratefully received.
Now what I didn't know was that when a control is disabled on the clientside it doesn't get included in the postback.
Which is why the serverside validation was firing. As far as it was concerned the control was empty.
The soolution is to use the readOnly property rather than the disabled property.
Now to figure out how to style the control to make it have the same look as if it was disabled.
ASP.NET's validators work in mysterious ways :D
First of all it is dangerous to use the id of an ASP.NET control to access it in jQuery.
If you place the control in a repeater or wrap the page in a master page, then the id of the html element will be something different than the id you specified. Use class to access the element instead.
If ASP.NET validators want the field to be enabled then you must try another approach.
My suggestion would be this:
1.
Add a class to the textbox, that makes it looks disabled:
$("#txtBrokerNetID").addClass("thisClassMakesItLookDisabled");
2.
Add an event that checks on focus to the textbox and blurs it if there is focus:
$("#txtBrokerNetID").focus(function() {
$(this).blur();
});
Now the field behaves as if it is disabled and the validator works.
One option you can choose, is to set a ValidationGroup than the one the form uses, an then, when validating the form call Page_ClientValidate('text_validation_group') if needed. That way client validation won't get in the way.