Search results matching tag 'Control'

richtextbox in ASP.NET?

omega90 — Wed, 02 May 2012 12:44:03 GMT

Hallo

ich bin gerade dabei eine Signatur erzeugen zu lassen, die Informationen von der Person werden aus dem Active Directory gezogen. Dazu habe ich eine rtf Datei erstellt die aus folgendem Inhalt entstand ...

Mit freundlichen Grüßen
Best regards
i.A. <Vorname> <Nachname>
<Abteilung>
<Firma>
<Strasse>
<Ort>
phone: <Telefon>
fax: <Fax>
email: <eMail>

Nun dachte ich mir ich erstelle in meiner Webform eine Richtextbox in der der Text zu letzt angezeigt wird und die Werte die zur Person gehören eingefügt werden.

Das Problem ist das ich keine Richtextbox in der Toolbox finde :(

Gibt es auch eine andere Möglichkeit die Signatur aufzubauen ...aus einer rtf datei heraus

gruß w.t

jQuery Plugin selbstgemacht - Dynamisches laden von ASP.NET Controls

Roberto — Wed, 02 Sep 2009 21:25:00 GMT

Wer kennt sie nicht... die zauberhaften ajax Kekse.

Doch was steckt dahinter?

In diesem Beitrag werde ich anhand eines Beispiels erklären, wie man ein jQuery Plugin dafür erstellen kann.

Die Vorgehensweiße:
Über einen clientseitigen Funktionsaufruf werden wir den Inhalt eines HTML Containers mit dem eines klassischen ASP.NET Controls ersetzen.
Das alles passiert mit einem Webservice Aufruf per jQuery der den HTML Code zurückliefert.

Schritt 1: Das Plugin

Eine kurze Einführung in jQuery Plugins.
In jQuery werden Objekte mit $.fn.<Name> = function() {} erweitert.
Allerdings sollte der "$" Alias vermieden werden, da Konflikte mit anderen Javascript Bibliotheken(bspw. prototype.js) entstehen können.
Die am häufigsten benutzte Vorgehensweise sieht so aus:

(function($){
    // --- Plugin kommt hier
})(jQuery);

Das neue Plugin nennt sich ascxLoder. Als Parameter die Pfadangabe und eine Sammlung mit Einstellungen.
Natürlich werden auch Standard Werte benötigt, damit ewige Parameter Übergaben vermieden werden.

$.fn.ascxLoader = function( path, params ) {
    var defaults = {
        showLoadingScreen = true
    };
    var config = $.extend(defaults, params);
    // --- Mit $(this) können wir auf den Container zugreifen.
    // --- über config.<Value> die gewünschte Einstellung.
}

Der Aufruf erfolgt dann über:

$("#MyContainer").ascxLoader("~/Control.ascx", { showLoadingScreen: false });

Schritt 2: Der Webservice Aufruf

Damit das Plugin jetzt auch den gewünschten Effekt bringt, bauen wir einen einfachen Webservice Request ein.

(function($){
$.fn.ascxLoader = function( path, params ) {
    var defaults = {
        path: "Control.ascx",
        showLoadingScreen: true
    };    
    var config = $.extend(defaults, params);
    var obj = $(this);
    path = path || config.path;
    // --- der Webservice Aufruf mit Pfad übergabe:
    $.ajax({
        type        : "POST",
        url         : "Webservices.asmx/GetControl",
        data        : '{"Path":"' + path + '"}',
        contentType : "application/json; charset=utf-8",
        dataType    : "json",
        success     : function( result ) {
            // result.d enthält den HTML code für unseren Container
            obj.html( result.d );
        }
    });
}
})(jQuery);

Hinweis: "path = path || config.path" bedeutet: falls path undefined ist, nimm config.path

Schritt 3: Der Webservice

Nun zum Webservice, der uns das gewünschte Control als HTML code zurückgibt.

<WebMethod()> _
Public Function GetControl( Path As String ) As String
Dim page        As New Page()
Dim userControl As UserControl = Page.LoadControl( Path )
Dim output      As New System.IO.StringWriter()
    page.Controls.Add( userControl )
    HttpContext.Current.Server.Execute( page, output, false )       
    return output.ToString()
End Function

Über folgenden Funktionsaufruf lässt sich das Control neu laden.

$("Container").ascxLoader("~/Controls/Control.ascx");

War doch gar nicht so schwierig oder?

Anbei gibt es ein Beispiel zum selber ausprobieren.
Dieses beinhaltet neben dem eben gezeigten Beispiel auch die Möglichkeit, einer Anforderungen Parameter mitzugeben und so je nach Aufruf ein geändertes Control zurückzugeben.

Update:
Eine gelungene und erweiterte Version des Plugins, von Kristof Zerbe findet sich hier!

Events für User- und CustomControls definieren und benutzen

Peter Bucher — Thu, 12 Jun 2008 19:44:00 GMT

In der Welt von ASP.NET gibt es - im Gegensatz zu Classic ASP - ein Eventsystem das in der ASP.NET Engine verwurzelt ist.
Dazugehörend haben viele ASP.NET Controls Events. Das bekannteste ist wohl Button.Click, über diesen Event kann festgestellt werden ob ein bestimmter Button gedrückt wurde, oder nicht.

Nun gibt es ja die Möglichkeit eigene User- und CustomControls zu schreiben.
Diese können mit Events ausgestattet werden, und genau um das geht es hier in diesem Artikel.

Wie funktionieren die Events in ASP.NET?

Grundsätzlich ereignen sich alle Aktionen auf dem Client, bspw. klickt eine Person an einem Computer in dessen Webbrowser auf einen Button.
Danach wird das Formular abgesendet und der Server empfängt dieses.

Der Server leitet den Http-Request (Die Http-Anfrage) an die ASP.NET Engine weiter.
Die Engine findet dann anhand der <Control>.UniqueID (Siehe: Identifizierung von Controls: Control.ID / .ClientID / .UniqueID) das Control zu dem die jeweiligen Daten gehören.

Wenn dieses Control gefunden wurde, leitet die Engine die gesamten POST-Daten (Formulardaten) an das bestreffende Control weiter.
Sind die Daten geändert worden, bzw. befinden sich die Daten in einem erwarteten Zustand, löst das Control den Event aus, ansonsten nicht.

Dies ist die normale Vorgehensweise von Events (Die Page Events laufen ähnlich ab), die über POST (Formular, Postback) ausgelöst werden.

Wie definiere ich einen Event, oder was ist ein Event überhaupt?

Für die Grundlagen zur Event-Erstellung, mit oder ohne nutzerspezifische Argumente, verweise ich hier auf den FAQ Thread des C#-Forums myCSHarp.de.

Eigenen Event definieren / Information zu Events (Externer Link: myCSharp.de)

Die FAQ von myCSharp.de als solches ist auch für andere Sprachspezifische Angelegenheit sehr zu empfehlen.

Wie / Wann werden die Events ausgelöst und gibt es mehrere Auslösearten?

Das trickreiche an Events in ASP.NET ist nicht die Dekleration der Events, sondern der Zeitpunkt an dem sie ausgelöst werden sollen.
Es gibt tatsächlich mehrere Arten von Zustandsveränderungen bei denen ein Event ausgelöst werden kann.

Folgend die Möglichkeiten von Zustandsänderungen durch einen Benutzer der Web Applikation ausgelöst:

Werte die durch einen (oder mehrere) GET-Parameter (QueryString) empfangen werden, bspw. wenn der Benutzer auf einen Link klickt
Werte die durch einen (oder mehrere) POST-Parameter (Form) empfangen werden, bspw. wenn der Benutzer Formularfelder ausgefüllt hat und dann auf einen Button klickt, oder aber nur auf einen Button klickt

Zudem gibt es noch weitere Faktoren und Möglichkeiten, die als Indikatoren für eine Eventauslösung benutzt werden können:

Werte die durch einen (oder mehrere) POST-Parameter empfangen werden, die durch die __doPostback-Javascriptfunktion abgeschickt werden
Zustandsänderungen aller Art auf der Serverseite (Datei, Datenbank, Session, Zeit, Datum, etc...
Festgelegte Logik im Code, bspw. Vergleiche, etc...

Aller Anfang ist ~~schwer~~ leicht

Zuerst folgt ein Beispiel das auf einen GET-Parameter reagiert und bei Vorhandensein des Parameters einen Event auslöst.

C#:

namespace pb.Web.UI.WebControls.Examples { public class TestControlGetSimple : WebControl { public event EventHandler ParameterAvailable; protected virtual void OnParameterAvailable(object sender, EventArgs e) { if (this.ParameterAvailable != null) this.ParameterAvailable(sender, e); } protected override HtmlTextWriterTag TagKey { get { return HtmlTextWriterTag.Div; } } protected override void OnInit(EventArgs e) { base.OnInit(e); HyperLink link = new HyperLink(); link.ID = "hlTest"; link.Text = "Testlink"; link.NavigateUrl = "?test=1234"; this.Controls.Add(link); } protected override void OnLoad(EventArgs e) { base.OnLoad(e); string name = this.Context.Request.QueryString["test"]; if(!string.IsNullOrEmpty(name)) { this.OnParameterAvailable(this, EventArgs.Empty); } } } }

Was genau passiert da jetzt?

Das Beispiel ist einfach aufgebaut. Zuerst wird ein Event mit einem Standard-Eventhandler (in .NET verfügbar) implementiert.
Danach wird die eventauslösende OnEvent-Methode definiert, die aufgerufen wird, wenn der Event ausgelöst werden soll.

Anschliessend wird per überschriebenen TagKey-Eigenschaft angegeben, dass das Control ein umschliessenden Div-Tag besitzen soll. (Im Beispielprojekt wird das für die Formatierung benutzt).
In der OnInit-Methode wird ein Objekt vom Typ Hyperlink angelegt, ein Text und eine Url + GET-Parameter angegeben und anschliessend zum Control hinzugefügt.

Jetzt kommt der spannende Teil: Das Event wird ausgelöst.

Beim Laden des Controls wird ein evt. vorhandener Parameter über <HttpContext>.Request.QueryString(<Key>) abgerufen, und anschliessend überprüft ob dieser null oder ein Leerstring (String.Empty) ist.

Falls dies nicht der Fall ist, wird der Event ausgelöst. Das war schon der ganze "Zauber" auf der Control-Seite.

Die Benutzung des Controls in einer ASP.NET Seite ist sehr einfach und geht so von der Hand, wie ansonsten ein Klick-Event eines Buttons abonniert wird.

Wie das Control registiert wird, um auf der Seite zu benutzen, kann im folgendenen Blogpost nachgelesen werden:

UserControl und CustomControls per web.config verfuegbar machen

Beispiel:

ASPX:

 
<fieldset> 
    <legend>GET Beispiel (simple)</legend> 
    <pb:TestControlGetSimple ID="testGetSimple" runat="server" /> 
    <br /> 
    <asp:Label ID="lblInfoGetSimple" Text="Parameter nicht verfügbar" runat="server" /> 
</fieldset>

Codebehind (C#):

 
protected void Page_Load(object sender, EventArgs e) { 
    this.testGetSimple.ParameterAvailable += testGetSimple_ParameterAvailable; 
} 


void testGetSimple_ParameterAvailable(object sender, EventArgs e) { 
    this.lblInfoGetSimple.Text = "Parameter ist <strong>vorhanden</strong>"; 
}

Zuerst werden auf der ASP.NET Seite das Test-Control und ein Label hinzugefügt.
Anschliessend abonnieren wir das Event im Page_Load Eventhandler und fügen dem zugewiesenen Handler Code hinzu, damit das Label anzeigt, ob der Event ausgelöst wurde oder nicht.

Wenn der Link angeklickt wird und infolgedessen ein GET-Parameter vorhanden ist, wird das Event ausgelöst und im Eventhandler den Text des Labels geändert.
Aus Benutzersicht ist nur der geänderte Text sichtbar.

Das Beispiel wurde mit Absicht sehr simpel gehalten, um einen einfach Einstieg zu ermöglichen.

Ein erweitertes Beispiel mit GET-Parametern

Folgend der Code eines erweiterten Beispiels, das mithilfe einer Session erkennen kann, ob der aktuelle Wert des GET-Parametes geändert wurde. Den ASPX-Teil wird nicht mehr gezeigt, da er praktisch identisch zum Beispiel (Siehe Code) ist.

C#:

 
namespace pb.Web.UI.WebControls.Examples 
{ 
    public class TestControlGet : WebControl, INamingContainer 
    { 
        public delegate void NameChangedDelegate(object sender, NameChangedEventArgs e); 
        public event NameChangedDelegate NameChanged; 


        protected virtual void OnNameChanged(object sender, NameChangedEventArgs e) { 
            if (this.NameChanged != null) 
                this.NameChanged(sender, e); 
        } 

        protected override HtmlTextWriterTag TagKey { 
            get { 
                return HtmlTextWriterTag.Div; 
            } 
        } 

        protected override void OnInit(EventArgs e) { 
            base.OnInit(e); 

            for (int i = 0; i < 5; i++) { 
                HyperLink link = new HyperLink(); 
                link.ID = "testLink" + i.ToString(); 
                link.Text = "Patrick " + i.ToString(); 
                link.NavigateUrl = "?name=Patrick" + i.ToString(); 
                this.Controls.Add(link); 
                this.Controls.Add(new LiteralControl("<br />")); 
            } 
        } 

        protected override void OnLoad(EventArgs e) { 
            base.OnLoad(e); 

            string name = this.Context.Request.QueryString["name"]; 
            string nameBefore; 
            object sessionValue = this.Context.Session["name"]; 

            if (sessionValue != null) 
                nameBefore = sessionValue.ToString(); 

            bool flag = false; 

            // Erste Änderung (ohne Session, erster Aufruf) 
            if (name != null && sessionValue == null) 
                flag = true; 

            // Änderung mithilfe der Session herausfinden 
            if (sessionValue != null && name != null && !sessionValue.Equals(name)) 
                flag = true; 

            if(flag) 
                this.OnNameChanged(this, new NameChangedEventArgs(name)); 

            this.Context.Session["name"] = name; 
        } 
    } 

    public class NameChangedEventArgs : EventArgs { 
        private string _newName; 

        public NameChangedEventArgs(string newName) { 
            this._newName = newName; 
        } 

        public string NewName { 
            get { return this._newName; } 
        } 
    } 
}

In diesem Beispiel wird eine Liste von Links mit GET-Parametern ausgegeben.
Wenn der empfangene Parameter ändert, wird der Event ausgelöst.

Beim ersten Empfangen eines Wertes wird dieser in die Session geschrieben und dieser Spezialfall berücksichtigt.
Wird jedoch ein Wert empfangen, wenn die Session schon ein Wert enthält, wird auf Ungleichheit geprüft, falls wahr wird der Event ausgelöst.

Zudem wird in diesem Beispiel ein eigener Delegate benutzt, um eigene EventArgs zu unterstützen.
Im Eventhandler kann der geänderte Namen einfach über e.NewName abgerufen werden.

(Der Einfachheit halber habe ich keinen generischen EventHandler benutzt, obwohl dieser ab .NET 2.0 natürlich zu empfehlen wäre. Wie es geht, siehe: Eigenen Event definieren / Information zu Events (Externer Link: myCSharp.de) )

Einen Event über POST-Werte mithilfe von IPostBackEventHandler und ClientScript.GetPostBackEventReference auslösen

Wie weiter oben schon angesprochen, stellt ASP.NET selber eine Architektur bereit, um mit POST-Daten Events über eine spezielle Infrastruktur auszulösen.
Die jetzt vorgestellte Lösung basiert auf der __doPostBack-Funktion, die ASP.NET im Normalfall in jeder ASP.NET Seite zur Verfügung stellt.

Folgend die Definition der Schnittstelle.

C#:

 public interface IPostBackEventHandler 
{ 
    void RaisePostBackEvent(string eventArgument); 
}

Im Normalfall geschieht ein Postback über einen Html-Button, der das Formular absendet.
Das Formular kann aber auch per Javascript abgesendet werden, genau das nutzt die __doPostBack-Funktion.
Sie kann zusätzlich Parameter entgegennehmen und diese über HiddenFields (Versteckte Eingabefelder) zum Server schicken.

So ist nicht nur ein Abschicken und Prüfen von Form-Elementen möglich, sondern auch das übergeben beliebiger Elemente und zudem auch den Namen des Controls, von dem die Elemente bzw. Argumente kommen.

Über die Methode GetPostBackEventReference() der Klasse ClientScript finden sich viele Überladungen, die benutzt werden können um eine Javascript Postback-Referenz zu bekommen.
Dies ist nichts weiter als ein benutzerdefinierter Aufruf der __doPostBack-Funktion, mit eigenen Parametern.

ASP.NET stellt eine Schnittstelle Namens IPostBackEventHandler zur Verfügung, die implementiert werden kann, um über Postbacks mit der Möglichkeit der Übergabe von Elementen zu kommunizieren.
Dabei muss immer das Control selber (schlussendlich die UniqueID des Controls) übergeben werden, sowie Argumente nach Wunsch.

Vielleicht kennt der eine oder andere die __doostBack-Funktion aus dem GridView, wenn eine Zeile selektiert wird.
Dies wird genau nach diesem Schema erledigt.

Folgend nun das Beispiel (Wiederum nur das Control an sich, da der Rest praktisch gleich ist):

C#:

 
namespace pb.Web.UI.WebControls.Examples 
{ 
    public class TestControlPost : WebControl, INamingContainer, IPostBackEventHandler 
    { 
        public delegate void NameSelectedDelegate(object sender, NameSelectedEventArgs e); 
        public event NameSelectedDelegate NameSelected; 


        protected virtual void OnNameChanged(object sender, NameSelectedEventArgs e) { 
            if (this.NameSelected != null) 
                this.NameSelected(sender, e); 
        } 

        protected override HtmlTextWriterTag TagKey { 
            get { 
                return HtmlTextWriterTag.Div; 
            } 
        } 

        protected override void OnInit(EventArgs e) { 
            base.OnInit(e); 

            for (int i = 0; i < 5; i++) { 
                HyperLink link = new HyperLink(); 
                link.ID = "testLink" + i.ToString(); 
                link.Text = "Patrick" + i.ToString(); 
                link.NavigateUrl = "#"; 
                link.Attributes.Add("onclick", this.Page.ClientScript.GetPostBackEventReference(this, "Patrick " + i.ToString())); 
                this.Controls.Add(link); 
                this.Controls.Add(new LiteralControl("<br />")); 
            } 
        } 

        #region IPostBackEventHandler Members 

        public void RaisePostBackEvent(string eventArgument) { 
            if(this.NameSelected != null) 
                this.NameSelected(this, new NameSelectedEventArgs(eventArgument)); 
        } 

        #endregion 
    } 

    public class NameSelectedEventArgs : EventArgs 
    { 
        private string _selectedName; 

        public NameSelectedEventArgs(string newName) { 
            this._selectedName = newName; 
        } 

        public string SelectedName { 
            get { 
                return this._selectedName; 
            } 
        } 
    } 
}

Das Beispiel ist dem letzten Beispiel sehr ähnlich, jedoch geht es hier um das Selektieren eines Namens, nicht um die Änderung dessen.

Es werden auch HyperLinks erzeugt, und in dessen clientseitigem onclick-Eventhandler jeweils die PostBackEvent-Referenz mithilfe obengenannter Methode ein parameterisierter Javascript-Aufruf für das jeweilige Link erzeugt.
Dabei wird eine Referenz auf das Control selbst mitgegeben, damit ASP.NET das Control anhand der UniqueID identifizieren kann, und den Namen, der selektiert werden kann.

Die ASP.NET Engine merkt beim Durchgehen aller Controls, dass dieses Control die IPostBackEventHandler Schnittstelle implementiert und feuert dann ggf. bei Bestehen eines Events dass durch das Link gesendet wurde, das Event.

Dies geschieht dadurch, dass ASP.NET die Methode RaisePostBackEvent aufruft und ihr das Argument übergibt, dass vom Client gesendet wurde.
Aufgrund dieser Infos kann schlussendlich im Eventhandler auf das Argument zugegriffen werden.

Das Interface IPostBackDataHandler, Sinn und Nutzen

ASP.NET stellt noch ein weiteres Interface zur Verfügung, um Events auszulösen.
Dieses setzt zwei Methoden voraus, folgend die Definition:

C#:

 public interface IPostBackDataHandler 
{ 
    bool LoadPostData(string postDataKey, NameValueCollection postCollection); 
    void RaisePostDataChangedEvent(); 
}

Im Beispiel auf der Seite von Microsoft, ist ein ziemlich sinnloses Beispiel zu finden, indem von einem WebControl ein Button nachgebaut wird.

Diese Schnittstelle wird nur existieren, damit Microsoft alle Form-Controls implementieren konnte.
In LoadPostData werden die UniqueID des Controls selber und die komplette Post-Collection angeboten.

Durch <Collection>[postDataKey] kann der Wert des Controls sehr einfach gelesen werden, der Rückgabetyp ist ein bool und bei einer Rückgabe von true wird die RaisePostDataChangedEvent()-Methode aufgerufen und der oder die Events können gefeuert werden.
ASP.NET ruft - auch durch die Interface-Markierung - jeweils die Methode LoadPostData automatisch auf.
Dies jedoch nur, wenn als TagKey bzw TagName des Controls ein bekanntes Form-Control gesetzt ist (Was auch Sinn macht).
Wenn die Methode bei einem eigenen Control trotzdem aufgerufen werden soll, so muss die Methode RegisterRequiresPostBack (Siehe auch: Understanding what Page.RegisterRequiresPostBack does) von der Klasse Page aufgerufen werden und das zu registrierende Control übergeben werden.

Für eine Implementation der Controls: Button, DropDownList, TextBox, etc... ein sehr sinnvolles Interface.
Bei der Implementation eines eigenen Controls, das kein Form-Tag darstellt geht es m.E. einfacher und besser ohne dieses Interface.

Siehe auch:

http://www.dotnetjunkies.com/WebLog/srivallichavalidotnet/archive/2005/11/14/133754.aspx

An dieser Stelle gibt es kein Beispiel, jedoch ist im Download auch ein solches Beispiel vorhanden, dass das Interface benutzt.

Inhalt des Downloads:

Alle hier darstellten Beispiele
IPostBackDataHandler-Beispiel
Alles in einer Solution mit einem Control-Library Projekt und einem Web Application Project zum Testen

Download:

Control Events Sample

Dank geht an:
Norbert Eder für das Review des Artikels

Ich freue mich über jegliche Kommentare!

SelfValidatingControl - CustomControl selber validieren lassen

Peter Bucher — Thu, 21 Jun 2007 22:24:00 GMT

Ich bin in der Newsgroup über die Frage gestolpert, wie man ein sich selbst validierendes Control, ohne ein zusätzliches Custom Validator Control dazu bringen kann, die Eigenschaft IsValid von der aktuellen Page Instanz zu beeinflussen.

Nun, wenn man ein bisschen nachforscht, findet man in der MSDN oder aber dem Reflector die abstrakte Basisklasse BaseValidator.

Folgend die Definition dieser Basisklasse:

public abstract class BaseValidator : Label, IValidator

Eine Klasse die von BaseValidator erbt, so wie das bei allen Validator Controls ausser der ValiationSummary der Fall ist, erben also von Label und implementieren das Interface IValidator.
Okay, für einen Validator an sich, mag es sinnvoll sein, sich wie ein Label zu verhalten, denn wir wollen schliesslich eine Fehlermeldung ausgeben.
In einem CustomControl sieht das aber wieder anders aus, vorallem dann, wenn wir die Validation selber erledigen.

Man kann / könnte die benötigten und schon im Framework vorhandenen Validatoren zu seinem CustomControl hinzufügen, und schliesslich auch veranlassen, dass diese Validatoren bei der Seitenüberprüfung berücksichtigt werden.
Jedoch geht es m.E. leichter von der Hand, wenn man sein CustomControl validationsfähig macht, und die einzelnen Prüfungen, sowie auch die Fehlerausgabe im Control selber erledigt.

Ich möchte euch anhand eines einfachen uns ziemlich sinnfreien Beispiels zeigen, wie man so etwas implementieren könnte.
Eine Klasse das als Validator fungieren möchte, muss das Interface (Schnittstelle) IValidator implementieren, als Basisklasse wählen wir in diesem Fall Control, da wir kein einzelnes Haupt Element brauchen.
Definition unseres CustomControls:

public class SelfValidatingControl : Control, IValidator

Als nächstes definieren wir die benötigten privaten Felder.
_isValid brauchen wir als Hilfsvariable im Zusammenspiel mit der Validierung.

private bool    _isValid = false;
private TextBox _txtSurname;
private TextBox _txtName;

Und jetzt geht es an die Implementation des CustomControls, hierzu erstellen wir im Konstruktor zwei TextBoxen und fügen sie zur Controls Collection hinzu.
Zwischen die TextBoxen schieben der Einfachheit halber, LiteralControls, jeweils mit "Vorname", "Name" und den dazugehörigen Breaks dazu "<br />".

public SelfValidatingControl() {
    this._txtSurname = new TextBox();
    this._txtName    = new TextBox();
    
    this.Controls.Add(new LiteralControl("Vorname:"));
    this.Controls.Add(new LiteralControl("<br />"));
    this.Controls.Add(this._txtSurname);
    this.Controls.Add(new LiteralControl("<br />"));
    this.Controls.Add(new LiteralControl("Name:"));
    this.Controls.Add(new LiteralControl("<br />"));
    this.Controls.Add(this._txtName);
}

Jetzt fehlen noch zwei wichtige Dinge:

Implementation der IValidator Schnittstelle
Weitergabe des Validators an die Validator Collection der aktuellen Page Instanz

Wenn wir die Schnittselle in der Klassendefinition niederschreiben, gibt uns Visual Studio die Möglichkeit, automatisch ein Grundgerüst für diese Schnittstelle zu erstellen. Nette Sache, machen wir :-)
Die Eigenschaft "ErrorMessage" müssen wir implementieren, benutzen sie in diesem Fall aber nicht, deshalb ist auch der Setter leer.
Bei der Eigenschaft "IsValid", geben wir den aktuellen Status anhand der Instanzvariable "_isValid" zurück, oder ändern diese.
In der Validate Methode, wird die Validierung ausgeführt, und die Instanzvariable "_isValid" bei Erfolg auf true, und bei Misserfolg auf false gesetzt.
Im konkreten Fall überprüfen wir nur, ob beide TextBoxen nicht leer sind, thats it.

 
#region IValidator Members 


public string ErrorMessage
{
    get
    {
        return "Surname or Name empty";
    }
    set { ; }
}

public bool IsValid
{
    get
    {
        return this._isValid;
    }
    set
    {
        this._isValid = value;
    }
}

public void Validate()
{
    if (this._txtSurname.Text != String.Empty
       &&
       this._txtName.Text != String.Empty)
    {
        this._isValid = true;
    } else {
        this._isValid = false;
    }
}

#endregion

Und jetzt kommt der ganze Clou an der Sache.
Wenn wir auf der aktuellen Page den Status per Page.IsValid abfragen, durchläuft die aktuelle Page Instanz ihre Validator Collection.
Unser Control muss dort jetzt natürlich rein, da es, ausser einem Control, zusätzlich auch noch die Rolle eines Validators eingenommen hat.
Dies erledigen wir, indem wir die OnInit Methode des Controls überschreiben und dort auf die aktuelle Page Instanz Zugreifen.
Über die .Add Methode der Validator Collection, fügen wir über "this", die aktuelle Instanz unserer Control Klasse hinzu, also das Objekt, in dem wir uns im Moment befinden.

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
    this.Page.Validators.Add(this);
}

Auf der einer beliebigen Seite müssen wir nur noch unser Control deklerativ oder per Code einfügen.
Ab diesem Moment ist die Page.IsValid Eigenschaft auch auf den Zustand dieses Controls sensibel.

Beispielprojekt:

SelfValidatingControlTest

Quellen:

Entwickeln eines Bestätigungssteuerelements (MSDN)

WaitButtonControl - Auf langes Postback warten

Peter Bucher — Thu, 31 May 2007 21:56:00 GMT

Wieder einmal (wie immer :-), wurde ich durch eine Frage im Forum angeregt.
Es ging darum, einen Button zu haben, der nach dem Klicken sofort deaktiviert wird, einen Hinweistext darstellt und trotzdem noch ein normales PostBack inkl. "Absenderadresse" versendet.

Die Lösung war am Ende folgende (Im Page_Load bspw.):

this.<Button>.Attributes.Add("onclick", "this.disabled = true; this.value = 'Bitte warten...'; " + ClientScript.GetPostBackEventReference(<Button>, null));

Nun gut, es funktioniert, ist relativ schnell geschrieben - aber:

Man muss es trotzdem immer wieder schreiben
Es ist schlussendlich Code, der das Gesamtbild aufbläht
Wenn man eine zusätzliche Funktionalität möchte, muss man es überall nachtragen
Schlussendlich endet das in der Copy&Paste Hell ;-)

Genau für so etwas ist ein ASP.NET CustomControl sehr gut geeignet.
Es folgt der Quellcode des Controls und ein Beispiel zum Herunterladen und Probieren.

WaitButton.cs

using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.ComponentModel; 



namespace t4m.Controls
{
    [DefaultProperty("WaitText")]
    public class WaitButton : Button
    {
        private const string DefaultWaitText = "Bitte warten...";

        private bool _wait       = true;
        private string _waitText = DefaultWaitText;

        public bool Wait {
            get { return this._wait; }
            set { this._wait = value; }
        }

        public string WaitText {
            get { return this._waitText; }
            set { this._waitText = value; }
        }

        protected override void AddAttributesToRender(System.Web.UI.HtmlTextWriter writer)
        {
            if (this._wait)
                writer.AddAttribute("onclick",
                    "this.disabled = true;" +
                    "this.value    = '" +
                    (this._waitText == DefaultWaitText ? DefaultWaitText : this._waitText) +
                    "';" +
                    Page.ClientScript.GetPostBackEventReference(this, null));

            base.AddAttributesToRender(writer);
        }
    }
}

Beispielprojekt:

WaitButton Test Projekt

Weiterführende Links:

WaitButton Test Projekt

Peter Bucher — Thu, 31 May 2007 21:49:53 GMT

Identifizierung von Controls: Control.ID / .ClientID / .UniqueID - UserControlTest

Peter Bucher — Mon, 09 Apr 2007 19:49:04 GMT

Control Identifizierung Beispiel

Peter Bucher — Mon, 09 Apr 2007 19:28:00 GMT