Can I implement a constructor in an ASPX page without a Codebehind file?
I have a page "test.aspx" and I try to include a constructor:
<%# Page Language="C#" %>
<script runat="server">
public dd_prop_test_aspx() : base() { /* Do stuff */ }
</script>
But, the runtime compiler gives me an error:
CS0111: Type 'ASP.test_aspx' already defines a member called 'test_aspx' with the same parameter types
Line 558: [System.Diagnostics.DebuggerNonUserCodeAttribute()]
Line 559: public test_aspx() {
Line 560: string[] dependencies;
Can I specify a directive to not generate a constructor automatically (as it appears that the compiler does)? Or, do I have another way of working around this?
In the end, I would like to set variables in the class before Page_PreInit, so if a workaround exists without using constructors, that would work, too.
Although you cannot redeclare the constructor, you are free to override any method from a <script runat="server"> tag, as long as you don't override it in the code beside as well. And, you can also add page event handlers (same restrictions apply) like Page_PreInit.
As you can use both the page event and the override at the same time, you might be able to inject code in advance:
<script runat="server">
void Page_PreInit(object sender, EventArgs e)
{
Response.Write("First?");
}
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e); // implicitly calls Page_PreInit
Response.Write("Second!");
}
</script>
So if you are using Page_PreInit in your code behind as a page event handler, you can use the override of OnPreInit in your .aspx and put your code before the call to base.OnPreInit(e).
If you're overriding OnPreInit in your code behind, you can declare a Page_PreInit in your .aspx and it depends on where you call base.OnPreInit(e) before your code behind logic or after.
In other words: you have full control over when it happens.
Related
The ASP.NET function ClientScript.RegisterClientScriptBlock can be used to register a chunk of JavaScript code that will be added to the page when it's rendered. The idea here is that you could have multiple instances of various user controls trying to register the same script over and over, but this ensures that it will only be included once.
The problem is, you don't really have any control over where the code is added to the page. This will insert the code inside the BODY tag of your page, but I need to add something (not limited to JavaScript code) into the HEAD block.
I'm well aware of various methods of adding something to the HEAD block via a ContentPlaceHolder block or by "Head.Controls.Add but these options do not address the problem of the same thing being added multiple times.
Is there an existing way to do this, or do I have to write a class that does something similar to ClientScript.RegisterClientScriptBlock except targeting the HEAD block?
I threw together a user control. There's nothing in the markup at all, so you can just add a new Web Forms User Control to your project and put this in the code behind:
public partial class ScriptControl : System.Web.UI.UserControl
{
private Dictionary<string, string> _scripts = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
public void RegisterScript(string key, string script)
{
if(!_scripts.ContainsKey(key)) _scripts.Add(key, script);
}
protected override void Render(HtmlTextWriter writer)
{
writer.WriteFullBeginTag("script");
foreach(var script in _scripts.Values) writer.Write(script);
writer.WriteEndTag("script");
}
}
Just add the directive to your page markup:
<%# Register TagPrefix="uc" TagName="ScriptControl"
Src="ScriptControl.ascx" %>
(where "ScriptControl.ascx" is whatever you've named the control)
and then you can add it wherever you need to, including in the header.
<head runat="server">
<uc:ScriptControl id="HeaderScriptControl" runat="server"/>
</head>
The usage is pretty much the same:
HeaderScriptControl.RegisterScript("myScript",
#"alert(""hello, world!"")");
I have an authentication roles-based system: different roles are redirected to different folders and in each folder there is a web.config that allows the access only to a particular username.
Few roles have the default page in common with a gridview that react in different ways depending on the role(different columns are shown, events trigger different methods, etc.).
so my problem is that everytime I need to make minor changes to a page I need to copy/paste the same changes to all the others default pages in the other folders.
In terms of code I solved by creating a DefaultFather class which extends System.Web.UI.Page and every other Default class inherits from DefaultFather. In this way, if I dont declare a Page-life-method, the DefaultFather method will be triggered.
but what about the graphic part(html, javascript, asp components, etc...)??
I created a NestedMasterPage just for the Default pages but everytime I need to change the appearance/behaviour of controls(gridview, buttons, linkbuttons) I must use the FindControl() method.
there isnt really another way to solve this problem?
Im thinking of using the Page_Load() method to search for each control with FindControl() and save them into attributes for later usage but it doesnt really look like a good solution.
It would be nice if I could use the masterpage components as properties but I think that in order to do that I should create public properties and I dont know if it will cause some kind of security problem.
any suggestion?
btw, if masterpage is the solution, should I remove the DefaultFather class and place the code directly into the masterpage? or is it a good idea to have another class just for the code?
I'd say there's nothing wrong with having both a master page and a base class for your page. They serve different purposes. The master page is generally all about layout, and the base class would be about page functionality.
If you want to manipulate the markup on your master page, rather than accessing the fields directly, I'd say create a logical function which does what you need it to do, and let the master page do it.
// Site.Master.cs
public void HideSubmitButton()
{
btnSubmit.Visible = false;
}
// Default.aspx.cs
protected void Page_Load(object sender, EventArgs e)
{
((SiteMaster)Master).HideSubmitButton();
}
I'd probably wrap that cast so you can use it more easily - that is something that would belong in your base class:
// DefaultFather.cs
protected new SiteMaster Master { get { return (SiteMaster)base.Master; } }
// Default.aspx.cs
Master.HideSubmitButton();
EDIT
Per your comment about attaching event handlers - if you need to attach events to objects that live on the master (which may not be a good idea - ideally the event handler for something living on the master lives on the master - but if you really need it) you can expose methods to do that as well, like:
// Site.Master.cs
public void AttachEventHandlerToGoButton(EventHandler eventHandler)
{
btnGo.Click += eventHandler;
}
// Default.aspx.cs
Master.AttachEventHandlerToGoButton(DoMyThing);
private void DoMyThing(object sender, EventArgs e) { }
or if you want to get fancy, write a wrapper event:
// Site.Master
<asp:Button ID="btnGo" runat="server" OnClick="btnGo_Click" />
// Site.Master.cs
public event EventHandler GoButtonClick;
protected void btnGo_Click(object sender, EventArgs e) {
if (GoButtonClick != null) {
GoButtonClick(sender, e);
}
}
// Default.aspx.cs
Master.GoButtonClick += DoMyThing;
private void DoMyThing(object sender, EventArgs e) { }
Also see my edit on the Master wrapper - you need the base. there to avoid a stack overflow.
I am trying to register a custom event I added to a user control.
I can do this in code behind, but not in the aspx file.
What am I doing wrong?
Thanks!
The user control:
public delegate void MemberSelectedEventHandler(object sender, string fullMemberName);
public partial class WebUserControl1 : System.Web.UI.UserControl
{
public event MemberSelectedEventHandler OnMemberSelected;
protected void Button_OnClick(object sender, EventArgs e)
{
if (OnMemberSelected != null)
{
OnMemberSelected(this, "Peter");
}
}
}
This works (code behind of aspx page):
MyMemberControl.OnMemberSelected += new MemberSelectedEventHandler(MyMemberControl_OnMemberSelected);
But this doesn't (aspx page):
<scn:MemberControl OnMemberSelected="MemberControl_OnMemberSelected" runat="server" ID="MyMemberControl" />
In the markup you need to prefix your event property with On so the page will know to register the event. Morzel had the answer though it's not stated explicitly.
<scn:MemberControl OnOnMemberSelected="MemberControl_OnMemberSelected" runat="server" ID="MyMemberControl" />
OnOnMemberSelected should cause your handler to be invoked as expected.
First of all I have to take a bit note: When you make a custom event, you don't need to name it with 'On' prefix. .Net framework adds this prefix and the markup intellisense will show you OnOnMemberSelected.
I don't know if it needs, but try to put the delegate declaration inside your WebUserControl1 class. I always do this.
Markup intellisense reacting really slow and I don't see if it deterministic when popullates intellisense information again.
Sum of all:
- put the delegate definition into your class.
- build
- insert your markup code.
If intellisense doesn't work immediatelly I think it will works.
as the title said is SqlDataSource can be shared across different aspx page?
i have exact same sqldatasource on multiple aspx page, is it possible to create one and shared for all the pages.
thanks
Sure. If you really mean shared, as in all pages use the same SqlDataSource, create a Master Page and put the data source in the master. In the codebehind, expose it as a property of the master. From there, you can reference it from any page that uses the Master.
Second option - create a base Page class:
public class MyPage : Page
{
private SqlDataSource mDataSource;
public override void OnLoad(EventArgs e)
{
base.OnLoad(e);
// some code to init your data source - depending on your
// implementation, this may need to be in OnInit instead
}
public SqlDataSource DataSource
{
get { return mDataSource; }
}
}
In this case, any time you create a new page, go to the code behind and change the declaration from implementing Page to MyPage. All pages that implement MyPage will have an SqlDataSource member, though each would have its own instance, so that's not really "sharing" the same SqlDataSource.
Either option gets you where you want to go I think.
UPDATE: Poster requested an example of exposing in as a property of the master:
Given a Master Page with the following:
<asp:SqlDataSource runat="server" ID="mDataSource" ... the rest of your properties .... />
<asp:ContentPlaceHolder runat="server" ID="MainContent"/>
In the code-behind for the master, define the property:
public class SiteMaster : System.Web.UI.MasterPage
{
public SqlDataSource MasterDataSource
{
get { return mDataSource; }
}
// the rest of your master page's codebehind
}
In the pages you define for using your master page, add the following below the #Page declaration:
<%# MasterPage VirtualPath="~/site.master"%>
Now, in the codebehind for that page, you can reference:
protected void Page_Load(object sender, EventArgs e)
{
SqlDataSource ds = this.Master.MasterDataSource;
}
As long as you have as long as you have a <%# MasterType VirtualPath="~/ PATH TO YOUR MASTER" %> in your aspx page, you can reference any properties you expose in the master.
Happy coding.
B
Controls are specific to pages. To share it across pages put it in a UserControl and then expose it through the public property of the UserControl.
If you mean the connection string, the answer is yes. You can put it in a public shared class.
If you mean the connection being open during several pages. No.
You should always close the connection ASAP to avoid memory leaks.
Where is the best part of asp.net page or code behind to register RegisterClientScriptBlock.
You have a bunch of options.
Register script includes in your <head> section or do inline <script> tags. I prefer to have my scripts at the bottom of the page though.
You can also register it at the Page level in your Page_Load (or any other event) by calling ClientScript.RegisterClientScriptBlock and passing it the script you want. Remember that if you do go with RegisterClientScriptBlock, you will need to make sure that you register the code with every page load so that is why I would recommend the Page_Load event if you want to use this method.
For example:
protected void Page_Load(object sender, EventArgs e)
{
AddClientSideJavascript();
// Do other stuff
}
private void AddClientSideJavascript()
{
// Register some client script code
Type someType = this.GetType();
if (!ClientScript.IsClientScriptBlockRegistered(someType, "TESTSCRIPT"))
{
string script = "function ShowAlert() { alert('Test'); }";
ClientScript.RegisterClientScriptBlock(someType, "TESTSCRIPT", script, true);
}
// Register more here... etc...
}
Just make sure you don't include it the portion of your Page_Load that is wrapped with the if (!IsPostBack) check or else your scripts will not get registered after any postbacks.
The correct answer is - at any point within page_load.