Подскажите, чем отличается EnableViewState от IsTrackingViewState.

Вот их описания из MSDN:

Вроде бы сам разобрался...

EnableViewState указывает, следует ли сохранять значения данного объекта во ViewState. IsTrackingViewState указывает был ли вызван метод TrackViewState, т. е. была ли записана информация во ViewState на самом деле.
IsTrackingViewState зависит от EnableViewState. Если EnableViewState равен false, то и IsTrackingViewState будет равен false. Если же EnableViewState равен true, то IsTrackingViewState может быть равен и true, и false. Так, например, до вызова smth.Controls.Add(dynamicControl) у объекта dynamicControl IsTrackingViewState будет равен false, после вызова - true.

EnableViewState обеспечивает сохранение и устанавливает IsTrackingViewState  в true. И когда он впоследствии загружает эти данные, то он спросит по IsTrackingViewState загружать/сохранять из или нет.

Mymik, не совсем так.


EnableViewState не устанавливает IsTrackingViewState.
Если EnableViewState равен true, то в процессе вызова TrackViewState() устанавливается IsTrackingViewState. Именно поэтому при создании динамических компонентов после этапа десериализации ViewState изменения свойств компонента записываются во ViewState только после добавления его в Controls (т. к. Controls.Add() вызывает Track ViewState).

Idsa, главное отличие в том, что EnableViewState - это public, а IsTrackingViewState - protected. Для стандартного TextBox-а, например, ты сможешь только EnableViewState использовать. Когда ты страницу разрабатываешь (такой же в принципе контрол, как и другие), то это незаметно, поскольку тебе доступны и public и protected члены. Но когда ты покупной контрол используешь, то только public. Вывод: EnableViewState - для юзания, а IsTrackingViewState - для разработчиков контролов, т.е. для записи в ViewState твоей информации, как разработчика контрола.

Я еще сам не до конца все понял... Но на данный момент, больше согласен с Idsa, чем с Mymik. Нагуглил такой диалог:
Вопрос: "Now I am confused by FpSpread1.ActiveSheetView.IsTrackingViewState and EnableViewState property of SFW control. What's the relation between them? 
I tried to set FpSpread1.ActiveSheetView.IsTrackingViewState as False and EnableViewState as true, paging is not working(basically return an empty sheet when navigating pages)"
Ответ: "Setting IsTrackingViewState to false prevents the current view models being saved.  So even if you had EnableViewState set to true you would get the same behavior as if you had it set to false."

Ну а теперь по тому, что раскопал Idsa:
А что тогда делает метод SaveViewState()? Записывает "понарошку"?    

Допустим, говорим только о странице. В процесе инициализации страницы (ProcessRequest->ProcessRequestMain-> this.InitRecursive->) последней операцией идет вызов  this.TrackViewState(). И если внутренняя коллеция состояния _viewstate != null, то для нее вызывается  _viewstate.TrackViewState(), где (весьма хитрым способом, однако!) устанавливается IsTrackingViewState.
А LoadViewState (она вызывается только если запрос - постбек) и SaveViewState (вызывается всегда и проверяет только _viewState) работают сами по себе и независимо ни от чего. Их вызовы в ProcessRequest происходят... 

Для чего вся эта карусель? Да просто чтобы минимизировать размеры ViewState, гоняемого туда-сюда. Состояние элемента в ViewState можно записывать только после определенного момента. Поскольку это состояние может за цикл обработки страницы поменяться несколько раз (при создании элемента, его инициализации после создания), то среда ASP.NET разрешает реально сохранять состояние элемента после окончания всей инициализации(вернее, ее самым последним действием)
Таким образом ты, время от времени опрашивая IsTrackingViewState, узнаешь, включен ли трекинг ViewState в данный момент, или нет. Если ты убедился, что IsTrackingViewState=true, то все, что ты с этого момента будешь ручками писать в ViewState, будет в нем гарантированно сохранено.

вот еще интересный пример

Я имел в виду, что EnableViewState - лишь отражает намерение сохранять ViewState, а IsTrackingViewState констатирует факт, сохраняется ли ViewState. Это особенно четко прослеживается при создании динамических контролов. Но это все следствия. Причина же ниже.

Есть очень хорошая статья про ViewState. Я приведу интересную цитату оттуда:



Если кого-то смущает обилие буржуйских буков , кратко изложу суть дела. Нагромождение в виде IsTrackingViewState и EnableViewState необходимо для корректной обработки значений по умолчанию для элементов управления во время разработки. Происходит присвоение значений по умолчанию, вызов TrackViewState(), десериализация ViewState и присвоение значений согласно инфомрации из ViewState. Таким образом, значения по умолчанию не "загрязняют" (dirty) ViewState.

Единственное, что меня смущает, так это, каким же образом происходит обращение к ViewState и TrackViewState(), ведь оба они объявлены как protected. Видимо, это происходит скрыто через public свойства и методы... но, честно говоря, в Рефлекторе я этого не отрыл.

М-да, пальцастый чел, этот автор статьи.... 
 "как чуваки мучались, пока меня не встретили!!! Да, повезло им, несказанно повезло. А вот теперь, счастливчики, и вам повезло, что надыбали где-то мою статью..."   Ну ладно...
Никакого нагромождения нет все ясно, четко и нужно. Все очень стройно и логично. Смотри:
1. Получили самый первый запрос. Проходим инициализацию страницы. В Init страницы она вызывает Init своих контролов, те - своих . Т.е. идет рекурсия. Но в ViewState ничего не сохраняется еще. Да и зачем? Вот работает изначальный базовый конструктор. Он может установить какое-то первичное состояние страницы. Потом анализируется твой конструктор страницы. Вот и изменили состояние. Теперь смотрим что в PreInit страницы написано. Новое состояние. Представь себе, что было бы, если бы каждый раз что-то в ViewState писалось? А есть еще сотни контролов страницы, которые тоже хотят свое состояние писать... И вообще, зачем каждый раз писать в ViewState то, что захардкодано в разметке страницы, в ее CodeBehind? Это и так (при каждом запросе) будет опять отработано вначале инициализации.
Поэтому только после включения треккинга ViewState можно гарантированно писать во ViewState. А IsTrackingViewState как раз и говорит :"да, треккинг включен, теперь писать можно!" Вот и все. С момента включения треккинга все заносимые в ViewState помечаются как Ditry и именно эти, "грязные", данные в итоге и запишутся. Треккинг включается вызовом TrackViewState() перед самым выходом из Init. (рефлектор: Page.ProcessRequest(), ну и дальше - ProcessRequestMain()-> this.InitRecursive()). Для контролов - рекурсивно тоже треккинг включается.
До включения треккинга данные, заносимые в ViewState, получают Ditry=false, при включенном треккинге - Ditry=true; (рефлектор: StateBag.Add()). Все, прошли инициализацию и включили треккинг. Записываем в ViewState что хотим, в любом месте конвейера обработки...

При получении первого запроса ViewState еще нет. Поэтому, если не постбек, то LoadViewState() не вызывается (ProcessRequest. if(!IsPostBack), то LoadAllState() не вызывается). Идем дальше. Перед рендерингом вызываем SaveViewState() записываем все, что у нас накопилось в ViewState, а при следующем запросе (постбеке) уже вызываем LoadViewState().
И все это работает так всегда, одинаково... А смысл в EnableViewState - только в том, что его значение используется в методе SetEnableViewStateInternal(). Устанавливается флаг (flags[4]) и потом он анализируется в SaveViewStateRecursive(). Одним словом, если EnableViewState=false, то мы сразу из SaveViewState() вывалимся, ничего не запишем. А при следующем конвейере - ничего не прочтем (а нету ничего потому что   ). Но все функции, все вызовы, все равно будут выполняться в том порядке, что я описал.

"каким же образом происходит обращение к ViewState и TrackViewState(), ведь оба они объявлены как protected"
Обращение к TrackViewState() - только внутри контрола. Ты, разрабатывая свой контрол, или страницу, можешь вызвать TrackViewState(). А для стандартных контролов - нет. Это же естественно. Можешь сделай свой класс, наследник контрола, и вызывать.
EnableViewState - public. Ты с ним работаешь или программно (это свойство) или как атрибут страницы (или контрола).
Тут - никаких препятсвий. Ну, вроде все...   

Хм... Ну и зачем ты выложил дословный перевод цитаты, которую я привел выше?  Нипанятна... :(.


У меня вызвал вопрос не механизм работы с protected методами, а то, где же вызывается метод TrackViewState в коде (т. е. через какой public-метод).

он вызывается в событии Init внутри класса, а ты его можешь вызвать, обратившись к ViewState или вызвав Controls.Add();



???????
Я с головы писал, с рефлектором пол-дня просидел. ТВОЮ СТАТЬЮ Я НЕ ЧИТАЛ (как прочел ту убойную фразу, так и с наслаждением плюнул на нее)!!!!!!!
Если честно, то я счас просто в шоке.... :( 
Одно только радует: значит я разобрался в вопросе... А ты, Idsa,  - нет...

Тебя смущает эта фраза? Зря. При добавлении динамического контролла, например, в Load, он заново "проживает" инициализацию, в процессе которой происходит вызов TrackViewState.
Таким образом, динамический контролл будет сохранять свои значения во ViewState только после добавления его в Controls.


Да уж... Я привел отрывок из статьи, в котором все объясняется. Ты же отказался его читать, привел свое объяснение, которое совпадается с авторским... и удивлен, моей фразой? Ну чего тут удивляться-то? Ты же ее не прочитал, а я прочитал. Вот и вся разница.


Ну это еще полбеды. Так тебе хватает наглости (не прочитав цитату) утверждать, что я не понял сути. Аргументы в студию.
А вообще мое отношение к такому подходу (видеть и слышать только самого себя; tol05, не первый раз за тобой такой грешок) можно было бы выразить одним словом... да вот цензура не дремлет.

Мои грешки оставь мне. 

Я действительно считаю, что ты еще не разобрался в теме. После всех постов и статей ты задаешь вопрос  

Это что означает??? После всех-то постов, после всех-то статей?

P.S. Ну а почему я утверждаю, что сам понял? Да просто потому, что написал, как ты считаешь, слово в слово с тем, что написал автор твоей статьи. По-моему, это Аргументы

!  Mymik

Остынь.

Модератор: Дальнейшее выяснение отношений карается минусом в репу и бананом на неделю

Это сообщение отредактировал(а) Mymik - 9.7.2007, 13:45