danke, aber das klappt mit Deinem Vorschlag auch nur mit serverseitiger Validierung. Wenn ich die Gruppen setzte, dem Button im UserControl die Gruppe zuweise und clientseitig validiere habe ich das gleiche Verhalten, sprich der nächste PostBack aus der Masterpage wird unterdrückt....
Ich lade in eine Page ein UserControl (über LoadControl(string Pfad).
Das klappt natürlich auch.
Weiterhin möchte ich die einzelnen Seiten meiner Applikation über UserControls nachladen.
Also hönge ich mich in ein Event eines Menüs und cleare mein Panel und lade ein neues Control. Klappt auch.
Nur: Wenn ich innerhalb eines UserControls 2.0er ValidationControls nutze, die fehlschlagen ist es nicht mehr möglich, einen PostBack innerhalb der MasterPage zu machen. Sprich eine Navigation ist nicht mehr möglich.
Wer hat eine sinnvolle Architektur auf Lager um UserControls per PostBack aus einer MasterPage zu laden, die Validierung unterstützt?
Nochmal: Natürlich soll die Validierung fehlschlagen wenn Eingaben falsch sind, allerdings nur innerhalb des UserControls (z.B. in dessen btnClick), nicht ausserhalb des UserControls.
ich habe für WindowsForms eine DataBinding Abtraktion geschrieben und auf DataView - Ebene Methoden wie GetCurrentRowIndex implementiert. Das ganze läuft in WinForms als Komponente.
Nun zu WPF:
In WPF weiß ich noch nicht sorecht, was der beste Weg ist, um gegen ein DataSet zu binden. Vor allem:
Habe ich eine Chance ohne geben eine BindingListCollectionView zu binden Änderungen der Position innerhalb der View ausserhalb meines Windows mitzukriegen. In WinForms errreiche ich das relativ einfach, indem ich den BindingContext meiner Komponente übergebe.
Auch finde ich leider im Netz sehr wenig über System.Windows.Data
Bis auf die üblichen einfach DataBinding Beispiele eigentlich gar nichts.
Ich würde als gerne Wissen:
- Was passiert genau beim Binden gegen ein DataSet (bzw. gegen eine Klasse, die IBindingList und IList implementiert) ?
- Kann ich den DataContext nutzen um änderungen an der View in meiner Komponente zu übergen?
- Gegen was wird optimalerweise gebunden (CollectionView?) und welche Interfaces muss ich implementieren, um aus ADO.NET nahe an eine CollectionView zu kommen?
Jep, das gilt aber nur für visuelle Controls...
Generell scheint MS damit ein Problem zu haben, DataSet etc. sind ja ebenfalls nicht in der ToolBox sichtbar...
Der IE hat mal wieder extreme Probleme sich an Standards zu halten.
Er zaubert einfach genau 3 pixel nach dem links stehenden div. Warum weiß kein Mensch.
interessanter Ansatz ;-) Grundsätzlich müsstest Du Testen ob das Speichern des DataSet des Kunden in der Applikation sinnvoll ist. (Was passiert zb wenn Die Anwendung dummerweise genau nach einem Bestellvorgang resettet?!).
Grundsätzlich würde ich eher eine Datenbank abfragen.
Das Problem mit dem Timer kannst Du z.B. mit AJAX lösen:
Telerik´s RadCallBackTimer (http://www.telerik.com) kann dies z.B., muss aber keine kommerzielle Komponente sein.
Sounds kannst Du dann z.B. nach einer Prüfung (ist das DataSet gefüllt) abspielen:
ich möchte in einem neuen Projekt WebDav nutzen um meine Daten auf einen Windows 2003 Serverzu schaufeln (als Ersatz für FTP).
Mit stellt sich jedoch die Frage, wie ich dies am einfachsten einrichte:
Ich möchte natürlich nur, dass authentifizierte User Daten speichern, löschen usw. können.
Verbiete ich jedoch den anonymen Zugriff im IIS6 für das entsprechende Web kann die Seite ansich nicht mehr abgerufen werden.
Muss ich also zwei Webs anlegen, eins für WebDav und eins für den eigentlichen Web-Server Betrieb?
Wie würde ich die Verzeichnisse dann mappen?
dann bilde Dir Dein Delete selber. CommandBuilder ist nicht wirklich gut!
Und wie gesagt, zu liebe des Ablaufplans NIEMALS "SELECT *" verwenden!
Bilde Dir selbst Deine Abfragen (INSERT UPDATE DELETE) und vergiss in jedem Fall den CommandBuilder... Vermutlich ist Dein Problem dann vergessen....
Der Builder erzeugt nicht gerade optimale Abfragen / Statements
Ich nehme an, dass Du irgendwo Personalnummern mit Login´s verbindest (zb Datenbank).
Da Du Security des .NET Frameworks nutzt wirst Du innerhalb Deiner Session eindeutig indentifiziert.
Context.User.Identity
Somit kannst Du ordentlich prüfen ob der aktuell authentifizierte auch der User ist, denn Du mit Deiner Personalnummer erwartest. Das prüfen der IP geht zwar, aber wirklich schön ist es nicht (und läst sich natürlich auch faken).