[ASP.NET] SelectedIndexChanged dynamische ListBox probleem

[hornage]

Ik wil graag in mijn webapplicatie de mogelijkheid hebben om aan de hand van een keuze in een listbox een nieuwe listbox te maken. In de opzet zoals ik het wil kan het dan zo zijn dat er makkelijk zo'n 3 listboxes dynamisch gecreeerd moeten worden.

Het aanmaken en neerzetten van de eerste nieuwe wil wel lukken, maar het gaat mis met het koppelen van de SelectedIndexChanged aan een event.
Dit event wordt namelijk niet getriggerd als ik op een item klik in de nieuwe ListBox. Als ik AutoPostBack op true zet gebeurt er wel wat, maar dat is niet gewenst. Mijn nieuwe ListBox verdwijnt dan namelijk.

De enige aanwijzing die ik tot nu toe online heb gevonden is dat het te maken heeft met dat de ListBox niet automatisch in de ViewState opgenomen wordt. Ik kan alleen nergens vinden hoe ik die er dan in op moet nemen.

Iemand een idee?

[IJsbeer]

Welke versie van .NET gebruik je?

Standaard staat viewstate voor alles aan. Dus als je hem niet bewust uitgezet ehbt (kan op web.config niveau, page niveau, control niveau), dan staat ie aan.

Ook ga ik ervan uit dat AutoEventWireup="true" bovenin je pagina staat.

En je genereert de controls niet dynamisch? Dus gewoon op de aspx pagina?

Mocht je AJAX (kunnen) gebruiken dan is dit nog wel een goed voorbeeld:
http://www.asp.net/AJAX/A...wn/CascadingDropDown.aspx

Mocht je er niet mee uitkomen moet je echt even wat code posten.

[ Voor 14% gewijzigd door IJsbeer op 18-03-2009 12:36 ]

[Verwijderd]

Ik weet niet precies of ik je hiermee help, maar ik heb zelf een pagina gemaakt waar aan de hand van een database verschillende vragen dynamisch worden toegevoegd.

Ik maakte hiervoor gebruik van de dynamiccontrolsplaceholder van Denis Bauer:

http://www.denisbauer.com...cControlsPlaceholder.aspx

[hornage]

IJsbeer schreef op woensdag 18 maart 2009 @ 12:34:
Welke versie van .NET gebruik je?

Ik gebruik Visual Web Developer 2008 Express Edition

Standaard staat viewstate voor alles aan. Dus als je hem niet bewust uitgezet ehbt (kan op web.config niveau, page niveau, control niveau), dan staat ie aan.

Ik heb hem niet bewust uitgezet ergens.

Ook ga ik ervan uit dat AutoEventWireup="true" bovenin je pagina staat.

Dat staat bovenaan mijn pagina ja

En je genereert de controls niet dynamisch? Dus gewoon op de aspx pagina?

De controls genereer ik dus dus dynamisch zoals aangegeven. Hierin ligt dus ook het probleem.

Mocht je AJAX (kunnen) gebruiken dan is dit nog wel een goed voorbeeld:
http://www.asp.net/AJAX/A...wn/CascadingDropDown.aspx

Zoiets wil ik dus maken, maar dan met listboxes en bij mij zijn de aantal keuzes variabel.

Mocht je er niet mee uitkomen moet je echt even wat code posten.

code:

    protected void lbTargetCategories_SelectedIndexChanged(object sender, EventArgs e) {
      ListBox ListBox = new ListBox();
//      lbSecondCategoryChoice.Attributes.Add("SelectedIndexChanged", "lbTargetCategories_SelectedIndexChanged");
      ListBox.SelectedIndexChanged += new EventHandler(lbSecondCategoryChoice_SelectedIndexChanged);
      ListBox.AutoPostBack = true;
      
      phCat.Controls.Add(ListBox); //phCat is een PlaceHolder
      //Er worden items in de listbox gezet adhv de database

[IJsbeer]

Dynamisch genereren is altidj lastig. Wellicht is het beter om ze wel gewoon in je aspx op te nemen, en dan visible op false te zetten.

Als je ze gaat genereren zorg er dan voro dat ze wel weer eerst gegenereerd worden in de init of load van je pagina. Als je ze niet opnieuw gegenereerd hebt, zal het event idd niet afgevuurd worden omdat het control simpelweg in in de control collectie zit.

ps Visual Web Developer is de ontwikkelomgeving, die heeft minimaal .NET 3.5 nodig.

[gorgi_19]

Je moet de control toevoegen in de init / createchildcontrols. Vervolgens moet je IEDERE request (let dus op met een check in Page.IsPostback, meestal in je load) het eventhandler koppelen aan de control.

Met die code gaat het inderdaad mis. Je gaat eenmalig je controlcollection aanpassen; de state kan niet onthouden worden. Oplossingen kan je voor kijken met bijvoorbeeld GET en aan de hand hiervan je controlcollection opbouwen.

[ Voor 36% gewijzigd door gorgi_19 op 18-03-2009 13:21 ]

[IJsbeer]

En ik ben wel benieuwd waarom je de controls perse dynamisch wilt laden. Dat is vaak niet nodig en wel vragen om problemen.

[hornage]

Verwijderd schreef op woensdag 18 maart 2009 @ 12:39:
Ik weet niet precies of ik je hiermee help, maar ik heb zelf een pagina gemaakt waar aan de hand van een database verschillende vragen dynamisch worden toegevoegd.

Ik maakte hiervoor gebruik van de dynamiccontrolsplaceholder van Denis Bauer:

http://www.denisbauer.com...cControlsPlaceholder.aspx

Ik heb de dll toegevoegd aan mijn project en de DynamicControlsPlaceHolder toegevoegd. Als ik dan net zoals hierboven de nieuwe ListBox toevoeg en daarna het geheel draai gebeurt er nog steeds hetzelfde. Moet ik misschien nog iets setten ofzo? Ben al bezig met de help aan het doorlezen...

[hornage]

IJsbeer schreef op woensdag 18 maart 2009 @ 13:23:
En ik ben wel benieuwd waarom je de controls perse dynamisch wilt laden. Dat is vaak niet nodig en wel vragen om problemen.

Er moet een product gekozen worden aan de hand van een boomstructuur die variabel is in lengte. Er is dus geen maximum aan keuzes.

[hornage]

gorgi_19 schreef op woensdag 18 maart 2009 @ 13:20:
Je moet de control toevoegen in de init / createchildcontrols. Vervolgens moet je IEDERE request (let dus op met een check in Page.IsPostback, meestal in je load) het eventhandler koppelen aan de control.

Met die code gaat het inderdaad mis. Je gaat eenmalig je controlcollection aanpassen; de state kan niet onthouden worden. Oplossingen kan je voor kijken met bijvoorbeeld GET en aan de hand hiervan je controlcollection opbouwen.

Het component waar josjen naar verwijst zou dit toch ook op moeten lossen? (Niet dat ik die nu al werkend heb )
Maar kan je mij een link of tip geven over hoe je dit allemaal doet? Ben namelijk nog steeds ontdekkende in deze materie

[IJsbeer]

Is daar de tree niet voor bedoeld
Zolang je niet mag stellen dat er maximaal 3 of 4 niveau's gerenderd worden moet je idd dynamisch.. ruk...

Je kan dus niet in de SelectedIndexChanged de controls renderen..dat moet echt op load of init niveau. Pas daarna zal de indexchanged event worden afgevuurd, waar je ws. dan niets meer mee hoeft te doen omdat ze al gebind zijn.
Hier trouwens een aardige handleiding: http://www.singingeels.co...d_Controls_in_ASPNET.aspx

[ Voor 13% gewijzigd door IJsbeer op 18-03-2009 13:38 ]

[hornage]

Ik zie nu pas dat er ook een TreeView component is. Eens even kijken wat ik daarmee kan. Is denk ik wel een stuk simpeler.

[gorgi_19]

hornage schreef op woensdag 18 maart 2009 @ 13:34:
[...]

Het component waar josjen naar verwijst zou dit toch ook op moeten lossen? (Niet dat ik die nu al werkend heb )
Maar kan je mij een link of tip geven over hoe je dit allemaal doet? Ben namelijk nog steeds ontdekkende in deze materie

Je zal dan via GET je state moeten bijhouden (handmatig, dus listbox1=2&listbox2=5&listbox3=-1); die is beschikbaar in je Init en kan je een en ander gaan opbouwen; na het klikken voer je dan een Response.Redirect uit (of je gaat met een clientside onclick naar de nieuwe pagina navigeren).

Wat eerder al genoemd is en ook kan: drie listboxen op een pagina neerzetten. Eventueel kan je dan met ajax ook je data ophalen en vullen.

[IJsbeer]

Het hoeft niet via je get... het kan 'gewoon' via de viewstate, je moet alleen zorgen dat alle controls wel (op dezelfde manier) gerenderd worden.

[gorgi_19]

IJsbeer schreef op woensdag 18 maart 2009 @ 14:44:
Het hoeft niet via je get... het kan 'gewoon' via de viewstate, je moet alleen zorgen dat alle controls wel (op dezelfde manier) gerenderd worden.

Dus je wilt het feit dat er controls zijn in de viewstate opslaan, en deze vervolgens in de init weer gaan uitlezen om dan toe te voegen? Automatisch zit je dan ook gelijk dat je de controlcollection in de page_load pas in orde kan maken; eerder zou deze niet beschikbaar zijn

[IJsbeer]

Als je dezelfde controls weer aanmaakt in de page init dan wordt het SelectedIndexChanged van die dropdown ook afgevuurd. Blijft een situatie die je zoveel mogelijk moet vermijden, maar het werkt wel.

[gorgi_19]

IJsbeer schreef op woensdag 18 maart 2009 @ 15:21:
Als je dezelfde controls weer aanmaakt in de page init dan wordt het SelectedIndexChanged van die dropdown ook afgevuurd. Blijft een situatie die je zoveel mogelijk moet vermijden, maar het werkt wel.

Je zal dan nog steeds op voorhand al de controls moeten aanmaken (in de init) en ze dan bijvoorbeeld op false zetten; is inderdaad ook nog steeds een oplossing

[IJsbeer]

En de tree was in dit geval ook nog een oplossing (blijkbaar)... Wat konden die Romeinen toch een wegen bouwen naar Rome

[hornage]

Naja, ik zit nog wel wat te klooien met die treeview, maar dit lijkt me een betere oplossing. Als ik nu alleen op een node klik klapt ie niet open Misschien nog een idee?

[IJsbeer]

Dan moet je echt even code laten zien wat je aan het doen bent. Heb je geen javascript fouten?

[hornage]

Ook alweer opgelost. Mijn gehele tree van keuzes wordt mooi ingelezen in de TreeView en werkt allemaal mooi!
Ik ga voor andere dingen in mijn project denk ik nog wel gebruik maken van de DynamicControlsPlaceHolder als ik erachter kom hoe ik dat precies kan gebruiken.

Allen dank voor de hulp

[R4gnax]

Verwijderd schreef op woensdag 18 maart 2009 @ 12:39:
Ik weet niet precies of ik je hiermee help, maar ik heb zelf een pagina gemaakt waar aan de hand van een database verschillende vragen dynamisch worden toegevoegd.

Ik maakte hiervoor gebruik van de dynamiccontrolsplaceholder van Denis Bauer:

http://www.denisbauer.com...cControlsPlaceholder.aspx

Hmm.. Die control ken ik nog, maar in mijn ervaring is ie nodeloos complex en kan in sommige gevallen nog steeds bugs opleveren met het deserialiseren van de viewstate. (Dit treed met name op wanneer je templated controls in templated controls hebt zitten en andere van dat soort meer exotische scenario's.)

Wat deze dynamisch control doet is de complete child control structure recursief opslaan in de viewstate. Dat vreet ruimte en leidt al heel snel tot een zgn. viewstate explosion, want -let op!- elke HTML tag die je in een user control neer zet wordt door asp.net in de control tree opgenomen. En laat user controls nou net die dingen zijn die je vaak dynamisch wilt inladen.

Eigenlijk is deze hele control onder asp.net 2.0 ook nergens meer goed voor. Enige wat je met asp.net 2.0 hoeft te doen om de viewstate een dynamisch ingeladen control automatisch te laten herpopuleren is deze control in Page_Init of Page_Load (of de custom control equivalenten daarvan) opnieuw aan te maken en dezelfde ID te geven als die tijdens de originele request had. Daarna zorgt het framework er zelf voor dat recursief alles geinstantieerd wordt en alle viewstate informatie daarna meegeladen wordt.

Deze hele control is eigenlijk een left-over van de asp.net 1.0 tijd toen het framework dit automatisch, recursieve herpopuleren nog niet goed afhandelde wegens de volgorde waarin de init, load en loadviewstate componenten van de pipeline plaatsvonden. (Sommige ingebouwde asp.net 2.0 controls hebben hier trouwens nog steeds last van.)

[TeeDee]

De zgn. viewstate explosion kan je natuurlijk ondervangen door iets als een ViewStateProvider die Session Based het één en ander in het Webserver geheugen opslaat. Nadeel: veel geheugen gebruik server-side.

Ook hier geldt: meerdere wegen richting de mooie stad Rome.

[R4gnax]

TeeDee schreef op donderdag 19 maart 2009 @ 23:42:
De zgn. viewstate explosion kan je natuurlijk ondervangen door iets als een ViewStateProvider die Session Based het één en ander in het Webserver geheugen opslaat. Nadeel: veel geheugen gebruik server-side.

Ook hier geldt: meerdere wegen richting de mooie stad Rome.

Maar waarom? Je hoeft namelijk niet die hele control tree op te slaan of naar de client te sturen; je hoeft alleen maar bij te houden wat de top level dynamische control was die je neer gezet had en deze met hetzelfde ID te herconstrueren in het Page_Load event. Deze controls zullen na afloop van het Page_Load event alsnog hun LoadViewState uitvoeren

Feitelijk ben je met het soort zaken als die DynamicPlaceHolder en custom ViewStateProviders een vierkant-wiel-oplossing aan het uitvinden voor een probleem wat niet bestaat.