ASP.NET - форсирование дочерних/контейнерных событий для увольнения перед родителем onload?

Вы можете изменить его, чтобы просто загружать элементы управления (без определения каких-либо вещей, зависящих от статуса) в Page_Load, и переместить рендеринг элементов управления, зависящих от статуса, в Page_PreRender.

Динамический пользовательский элемент управления может читать из базы данных в своем событии PreRender (или DataBind), если пользовательский элемент управления является тем, кто несет ответственность за то, что загружать.

Я думаю, проблема в том, что пользовательский элемент управления пытается прочитать статус до того, как загружены все элементы управления и загружено состояние представления. Откладывая отображение, зависящее от статуса, на более позднее событие страницы, вы убедитесь, что оно основано на правильном статусе.

Я гарантирую, что у моих динамических элементов управления всегда будет один и тот же сгенерированный Control.ID

ViewState будет отключен от идентификатора элемента управления. Если вы хотите обрабатывать событие OnClick внутри вашего динамического элемента управления с введенными пользователем данными, вам необходимо восстановить структуру иерархии элементов управления перед событием RaisPostBackEvent, которое сработало сразу после Page_load.

Если вы хотите сохранить свои динамические элементы управления с таким же состоянием в другом месте на странице или хотите иметь доступ к элементам управления после создания других динамических элементов управления , вам НЕОБХОДИМО сохранить иерархию элементов управления .

Итак! Создайте свою первую часть динамических элементов управления в одном контейнере и создайте элементы управления при обратной передаче в другом контейнере.

Например, при отображении запроса страницы:

< asp:placeholder id="iHaveToBeDuringAllRequests1" >
  First dynamic cintrols
< /asp:placeholder >
< asp:placeholder id="iHaveToBeDuringAllRequests2" >
  Empty on first request 
< /asp:placeholder >

На PostBack вы отображаете:

< asp:placeholder id="iHaveToBeDuringAllRequests1" >
  First dynamic cintrols(you can clear or do not load these controls if you don't need it)
< /asp:placeholder >
< asp:placeholder id="iHaveToBeDuringAllRequests2" >
  Second dynamic controls load here
< /asp:placeholder >

И последний совет:

Я гарантирую, что мои динамические элементы управления всегда генерируются одинаково Control.ID

Это необходимо для правильного запуска RaisPostBackEvent (OnClick и т. Д.) Динамическими элементами управления (вы можете использовать контейнер INamingContainer вместо заполнителя).

Хм - жизненный цикл страницы ASP.NET; один из моих любимых :)

Полагаю, это потому, что контрольные звонки пользователя "динамические вопросы" Четко при ответе на статус изменил событие. Это должно как-то убить ассоциацию между ViewState и мои динамические элементы управления, даже если Control.ID последовательный.

Похоже, это воссоздает все из состояния просмотра (включая вопросы «всегда активен»), а затем отбрасывает это в корзину. После элементы управления воссоздаются (без какого-либо состояния просмотра, потому что его воссоздание уже было выполнено). Так что да, я тоже думаю, что Controls.Clear является причиной вашего потерянного состояния.

Это, вероятно, не единственная задача. Я мог представить себе разные подходы.

Однако из-за жизненного цикла страницы в ASP.NET, пользовательский элемент управления "Статус" OnLoad, содержащий правильный статус, необходимый для загрузки правильного вопросы из БД, не попадает выполняется до тех пор, пока после динамического вопросы пользовательского контроля уже были заполнены (с неправильным / устаревшим ценности).

Что вы подразумеваете под «OnLoad содержит правильный статус»? Я бы сказал, что должна быть возможность получить «текущий выбор» из элемента управления статусом во время динамических вопросов «привязка данных» (если у вас есть что-то подобное в вашем элементе управления динамическими вопросами). Причина, по которой я так думаю, заключается в том, что «привязка данных» (в родительском элементе) происходит после пункта 3, упомянутого в статье « Жизненный цикл страницы ASP.NET », приведенной ниже. .Поэтому, если ваш элемент управления динамическими вопросами знает о статусе, который он должен соблюдать, он должен иметь возможность его получить. Если это не сработает, я бы сначала проверил, связана ли проблема с контролем состояния. Если ваш динамический элемент управления вопросами не знает о каком-либо статусе, это явно не сработает.

Другой подход заключается в том, чтобы ваш динамический элемент управления вопросами не удалял всех своих дочерних элементов ( Controls.Clear ), а только тех, которые больше не нужны. Вы могли (и я думаю, что должны) сделать это в PreRender. Таким образом, было бы полезно иметь средство для управления динамическими вопросами, чтобы отличать «всегда активные» вопросы от других. Затем вы можете придерживаться своей текущей тактики и события.

Если вы хотите глубже изучить жизненный цикл страницы ASP.NET и состояние просмотра, но еще не знаете их, эти две ссылки могут предоставить ценную информацию.

Жизненный цикл страницы ASP.NET и ИСТИННОЕ понимание ViewState .

Если это не совсем очевидно, я не смог разобраться с ASP.NET жизненный цикл страницы, несмотря на работу с это за последний год.

Дайте мне знать, если вы найдете кого-нибудь, у кого есть :)