Hello.
Wie es aussieht habe ich das mit dem Lifecycle immer noch nicht kapiert.
Folgendes: Ich erstelle 2 ListBoxen dynamisch,anders geht es nicht, denn es soll daraus eine Funktion werden, welche die Funktionalität der Listboxen kapselt und beliebig in die Seite integriert werden kann.
So.
Also erstelle ich erst einmnal eine leere Testseite.
Erstelle 2x Listboxen im Page_Load und befülle diese mit Testinhalt.
Dazu noch ein paar Buttons mit denen man per Javascript einzelne Einträge verschieben kann (nach oben nach untern, von Box1 zu Box 2 und umgekehrt usw).
Funtioniert.
Nun habe ich einen weiteren Button, welcher einen Postback auslöst bei dem ich die Werte der Boxen auslesen sollte.
Laut Lifecycle ist der Ablauf ja im Groben so:
Page_init
Page_load
Button_event
Page_Prerender
Also erstelle ich die Listboxen und den Inhalt in Page_load, damit ich im Button_Click Event die Inhalte habe und darauf zugreifen kann.
Funktioniert auch.
Nur...ändere ich die Anzahl der Einträge bzw. die Reihenfolge, sehe ich das im Button_Click Event nicht.
Die Reihenfolge ist immer diesselbe, nämlich die, die ich im Page_Load Ereignis zuweise, was ja auch logisch ist denn bei jedem Seitenaufruf wird die ListBox neu erstellt und neu mit Daten gefüllt.
Nur wie kann ich jetzt herausfinden, wie die veränderte Reihenfolge der Items ist?
Was ist mit ViewState?
Wo ist mein SelectedItemIndex?
Sagt jetzt nicht, daß ich die Inhalte in einem Hiddenfield speichern muss, so wie ich es in anderen Foren gelesen habe....das kanns ja wohl nicht sein!
Wo ist noch mein Knoten im Hirn?
moin,
ich bin mir nicht sicher, aber kann es sein, dass bei deinem postback ein objekt aus dem speicher rekonstruiert wird, welches so nicht mehr existiert? (durch deine clientseitige manipulation).
ich weiss dass meine lösung nicht best practice ist, aber ich würde versuchen die listboxen in einem updatepanel zu platzieren und dann statt mit javascript, die listen über einen asynchronen postback zu manipulieren...
mfg hurby
Die Welt hat genug für jedermanns Bedürfnisse, aber nicht für jedermanns Gier.
Hallo Hurby, interessanter Ansatz.
Aber z.B. bei einer Textbox klappt es ja auch, daß ich den Text im Button_Click Event "sehe" und das ist ja auch sozusagen eine Manipulation.
Wenn du die Daten mit JavaScript manipulierst geschieht das Clientseitig, dein Button EventHandler aber Serverseitig, klar dass der nichts mitbekommt.
be the hammer, not the nail!
Hallo,
soll zwar hier nicht gesagt werden, aber bei solchen Clientseitigen Manipulationen verwende ich immer ein Hiddenfield, dass ich dann ebenfalls per Clientscript z.B. in Deinem Fall mit dem selektierten DDL-Wert oder einem berechneten oder dergleichen Wert belege. Beim Postback hat dieses Hiddenfield dann den Wert parat - nicht schön, aber selten 😉
Das Hiddenfield scheint mir da die einzige Möglichkeit zu sein.
Grüße
hm...aber wenn ich eine TextBox Clientseitig per JavaScript manipuliere, steht eben dieser manipulierte Wert auch drin, will sagen den kann ich dann Serverseitig abrufen..
warum hier nicht?
Ja ggf. geht das bei einer TB aber glaube die DDL oder andere Steuerelemente 'zicken' da rum, aber wenn Du z.B. den zuvorbestandenen 'Selected Index' brauchst, speicherst Du eben diesen im Hiddenfield ab, oder Deine die komplette neue Auflistung als Objektliste (geänderte Reihenfolge oder dergleichen, oder z.B. als string '1-2-3-5-4').
kann es evtl. sein dass zb. textfelder automatisch im viewstate landen, listen aber nicht, weil sie einfach nicht für die clientseitige manipulatuion konzipiert sind???
mfg hurby
Die Welt hat genug für jedermanns Bedürfnisse, aber nicht für jedermanns Gier.
Die TextBox hat einen Event "onTextChanged" der geworfen wird, wenn der Text veraendert wird, daher bekommt der Server das auch mit.
be the hammer, not the nail!
Daran kanns aber nicht liege, denn das Ereignis wird nur geworfen, wenn ich das an die TextBox binde...
Hallo,
alle Formularelemente in HTML-Forms werden letztendlich mit einem Name-Wert-Paar übertragen.
Bei Listboxen ist für den Namen die Liste selbst und für den Wert das SelectedItem zuständig (bei mehrfachauswahl werden mehrere Paare mit demselben Namen übertragen).
Da dabei die Reihenfolge der Elemente in der Box keine Rolle spielt, und überhaupt nicht alle Elemente, sondern nur die ausgewählten übertragen werden, kann man clientseitige Manipulationen an Anzahl der Items oder deren Reihenfolge serverseitig nicht feststellen. Die einzige Änderung die man mitbekommt ist wenn man clientseitig die Selektion setzt.
Bei der Textbox klappt das ganze weil der per Script gesetzte Wert eben im Name-Wert-Paar übertragen wird.
Im Viewstate landen die beide nicht, da der Viewstate nur für Controls greift, die keine HTML-Formularelemente sind.
Die einzige Möglichkeit die Funktionalität zu erhalten, ist jede einzelne Manipulation über den Server laufen zu lassen. Eine Möglichkeit dazu wäre das von Hurby genannte UpdatePanel.
Gruß, MarsStein
Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca
Ok, vielen Dank für die Auskunft. Muss ich also doch wieder alles händisch machen.
Dann muss ich das im Updatepanel machen und feststellen, welche Items ausgewählt wurden und diese dann von ListBox 1 abziehen und Listbox B hinzufügen...usw usf...
da ja alles dynamisch ist...
Edit: Nein, ich werds per Javascript lasssen und zusätzlich die Items der Listboxen in separate Hiddenfields speichern.
Ich hoffe das geht auch gut, wenn da dann mehrere hundert Items drin sind.
Danke auch an alle anderen für die mit-Diskussion!
Im Viewstate landen die beide nicht, da der Viewstate nur für Controls greift, die keine HTML-Formularelemente sind.
Bahnhof?
Textboxen und ListBoxen sind doch schlußendlich HTML Formularelemente..
Hallo,
Bahnhof?
Textboxen und ListBoxen sind doch schlußendlich HTML Formularelemente..
genau, und deshalb gehen sie auch nicht in den ViewState - Formularelemente kennen ihre Werte bzw. ihren Zustand ja selbst und übertragen sie beim Postback, eine Viewstate wird also nicht benötigt.
ViewState greift für andere serverseiteige Controls, etwa für Label, Panel, ListView, und, und, und..., damit deren Ansichtszustand mitübertragen wird und wiederhergestellt werden kann, ohne alle erforderlichen Daten in die Sitzung zu packen.
Gruß, MarsStein
Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca