When you define UserControl in source code the sample I see are often like
that:
============
public string Text
{
get
{
String s = (String)ViewState["Text"];
return ((s == null) ? String.Empty : s);
}
set
{
ViewState["Text"] = value;
}
}
============
Yet I found that this simpler approach work well
============
string text;
public string Text
{
get { return text; }
set { text = value; }
}
============
It also doesn't clutter the web page (as the view state is embeded in the
page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly?
I guess there are reason to do so, like if I want to programatically change
the control property with an event handler and keep on further post back.
Yet that looks to me as a very marginal exemple.
Are there better reason?
And how to mark a control in such a way that it won't store its view state
in the web page.
Such as: I use ViewState to store property (in case they need to be stored),
yet I doesn't output this viewstate to the web page, in case it doesn't need
to be restored (would be equal to value in the aspx)?
Yet that seems quite a marginal 10 1608
All ASP.NET Controls have a property called EnableViewState, you can
disable that if you don't need the viewstate.
Remy Blaettler
The simpler approach will not retain values between postbacks. So you set
the property, the user clicks a button, and there is another request to the
server. At this point, this property no longer has the value you set. This
is because HTTP is stateless, and each request to the server means a new
page object is created from scratch.
The ViewState approach works, because the viewstate is posted back to the
server, so the value saved in it can be retrieved.
"Lloyd Dupont" <net.galador@ld> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... When you define UserControl in source code the sample I see are often like that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly? I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple.
Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page.
Such as: I use ViewState to store property (in case they need to be stored), yet I doesn't output this viewstate to the web page, in case it doesn't need to be restored (would be equal to value in the aspx)? Yet that seems quite a marginal
VieState is used to store per user information among each requests and
postback.
If you don't store the value in the viewstate, the property value will be
lost (since each request instanciate a new webform object), or you will have
to set it up again through your code or aspx pages html content.
There's other "store" you can use (in .NEt 1.1)
- Application : All users store the same Application variables. But
beware... if you use web farm, each serveur will have its own application
collection
- Session : Each user has its own. If you use web farm, you can configure
one of the servers to act as a state server, or you can use SQL Server. If
you don't, requests may hit another server in the farm and you'll loose the
session.
- Context : each request hold a context collection that is lost at the end
of the request. Usefull if you want to share informations accross all your
class and often filed in global.asax
My opinion is that the viewstate should be use as soon as you have a value
in a control that must persist. Storing it on the client side has the
advantage of less memory used on the server (Imagine 100's of variable in
the session * number of users --- it can grow very quickly).
Ok, it's take some KB on the page, but the most weigth in a page comes from
other resources like pictures.
Finally, do not forget that a developper that use a control can use the
EnableViewState to disable the ability to store data on the client side.
Hope that help.
Steve
"Lloyd Dupont" <net.galador@ld> a écrit dans le message de news:
%2****************@TK2MSFTNGP10.phx.gbl... When you define UserControl in source code the sample I see are often like that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly? I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple.
Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page.
Such as: I use ViewState to store property (in case they need to be stored), yet I doesn't output this viewstate to the web page, in case it doesn't need to be restored (would be equal to value in the aspx)? Yet that seems quite a marginal
"Lloyd Dupont" wrote: When you define UserControl in source code the sample I see are often like that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly?
Lifetime control. Essentially, the User Control properties can fall out of
scope after a request. While setting Text, as a property solves the problem
for this request, it does not have lifetime beyond the request. ViewState
does.
You have other options. Session is an option, although I am not too fond of
just throwing things into session as they tend to get "pack ratted" in there
and not cleaned out. You can also use caching mechanisms, including custom
static (Shared for VBers) classes that use session id to store information.
I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple.
It is marginal in some cases, but being able to hold state on a user control
is important when you do postsbacks.
Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page.
In the @ directive you can turn off ViewState.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***************************
Think Outside the Box!
***************************
I disagree.
If it's a valid argument for a textbox, a simple label, which value is
written in the .aspx, would always have its value set by code / .aspx.
A label, for instance, only VERY MARGINALLY need to keep its valu between
postabck.
(Because its value would most of the time be present in the page trhough
code or something, and szeldom come from user event)
"Marina" <so*****@nospam.com> wrote in message
news:uB*************@TK2MSFTNGP14.phx.gbl... The simpler approach will not retain values between postbacks. So you set the property, the user clicks a button, and there is another request to the server. At this point, this property no longer has the value you set. This is because HTTP is stateless, and each request to the server means a new page object is created from scratch.
The ViewState approach works, because the viewstate is posted back to the server, so the value saved in it can be retrieved.
"Lloyd Dupont" <net.galador@ld> wrote in message news:%2****************@TK2MSFTNGP10.phx.gbl... When you define UserControl in source code the sample I see are often like that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly? I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple.
Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page.
Such as: I use ViewState to store property (in case they need to be stored), yet I doesn't output this viewstate to the web page, in case it doesn't need to be restored (would be equal to value in the aspx)? Yet that seems quite a marginal
Let's say it differently.
This control of mine is a simple label, the user has no impact on it. Its
values are set by code (in OnInit()) and markup tag in the page.
Now, why would I need to retain any value between postback?
It's clear to me that (thanks to an other poster) I should set
EnableViewState = false by default (in the constructor) on this control.
"Steve B." <st**********@com.msn_swap_com_and_msn> wrote in message
news:um**************@TK2MSFTNGP15.phx.gbl... VieState is used to store per user information among each requests and postback. If you don't store the value in the viewstate, the property value will be lost (since each request instanciate a new webform object), or you will have to set it up again through your code or aspx pages html content.
There's other "store" you can use (in .NEt 1.1) - Application : All users store the same Application variables. But beware... if you use web farm, each serveur will have its own application collection - Session : Each user has its own. If you use web farm, you can configure one of the servers to act as a state server, or you can use SQL Server. If you don't, requests may hit another server in the farm and you'll loose the session. - Context : each request hold a context collection that is lost at the end of the request. Usefull if you want to share informations accross all your class and often filed in global.asax
My opinion is that the viewstate should be use as soon as you have a value in a control that must persist. Storing it on the client side has the advantage of less memory used on the server (Imagine 100's of variable in the session * number of users --- it can grow very quickly). Ok, it's take some KB on the page, but the most weigth in a page comes from other resources like pictures.
Finally, do not forget that a developper that use a control can use the EnableViewState to disable the ability to store data on the client side.
Hope that help.
Steve
"Lloyd Dupont" <net.galador@ld> a écrit dans le message de news: %2****************@TK2MSFTNGP10.phx.gbl... When you define UserControl in source code the sample I see are often like that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly? I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple.
Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page.
Such as: I use ViewState to store property (in case they need to be stored), yet I doesn't output this viewstate to the web page, in case it doesn't need to be restored (would be equal to value in the aspx)? Yet that seems quite a marginal
mh....
it seeems to be that a much leaner way to define my page would be:
- disable view state for the page
- enable on a per control basis for those control which have properties that
could change from user action (such as text box, gridview, etc...).
So I still get "memory" for the controls that can be modified by the user
and I don't clutter the page with useless info for these controls which are
completely setup in a static way by code or tags.
Except for the potential bug that I could "forget" to activate the view
state for those contrals that might need it, wouldn't it be better (leaner)
way?
"Cowboy (Gregory A. Beamer) - MVP" <No************@comcast.netNoSpamM> wrote
in message news:92**********************************@microsof t.com...
"Lloyd Dupont" wrote:
When you define UserControl in source code the sample I see are often like that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly?
Lifetime control. Essentially, the User Control properties can fall out of scope after a request. While setting Text, as a property solves the problem for this request, it does not have lifetime beyond the request. ViewState does.
You have other options. Session is an option, although I am not too fond of just throwing things into session as they tend to get "pack ratted" in there and not cleaned out. You can also use caching mechanisms, including custom static (Shared for VBers) classes that use session id to store information.
I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple.
It is marginal in some cases, but being able to hold state on a user control is important when you do postsbacks.
Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page.
In the @ directive you can turn off ViewState.
-- Gregory A. Beamer MVP; MCP: +I, SE, SD, DBA
*************************** Think Outside the Box! ***************************
For instance my control is a collapsible table with rounded corner.
It has 6 relevant values:
- expanded state
- show (or not) expand/collapse button
- page color (for rounded boder dynamic picture)
- border & header color
- inside color
- width
Yet only the expanded state would obviously need to be saved (although I'm
not sure I could pass this back to the web server, the viewstate is no good
because that needs to be modified via javascript, maybe through a cookie?)
Save all that stuff in the viewstate seems quite to be useless clutter to
me.
Although I could imagine this control being used in a page, and change its
color according to some user action (for example), I'm sure this state would
be more efficiently stored elsewhere.
So the question is:
- should I (could I?) set EnableViewState = false in the constructor ? (or
OnInit()?)
- should I not use view state at all and use instance variable?
Disagree with what?
Nothing you just said had anything to do with what I was saying at all.
Again, defining a property on a page, does not retain the value in that
property between postbacks.
ViewState is maintained between postbacks, since it is sent down with the
page to the browser, and sent up to the server with the post.
This is just a fact about how things work. There is nothing here about
labels, controls, etc. I'm sorry, but I have no idea what you are talking
about.
"Lloyd Dupont" <net.galador@ld> wrote in message
news:eM**************@TK2MSFTNGP12.phx.gbl... I disagree. If it's a valid argument for a textbox, a simple label, which value is written in the .aspx, would always have its value set by code / .aspx. A label, for instance, only VERY MARGINALLY need to keep its valu between postabck. (Because its value would most of the time be present in the page trhough code or something, and szeldom come from user event)
"Marina" <so*****@nospam.com> wrote in message news:uB*************@TK2MSFTNGP14.phx.gbl... The simpler approach will not retain values between postbacks. So you set the property, the user clicks a button, and there is another request to the server. At this point, this property no longer has the value you set. This is because HTTP is stateless, and each request to the server means a new page object is created from scratch.
The ViewState approach works, because the viewstate is posted back to the server, so the value saved in it can be retrieved.
"Lloyd Dupont" <net.galador@ld> wrote in message news:%2****************@TK2MSFTNGP10.phx.gbl... When you define UserControl in source code the sample I see are often like that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly? I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple.
Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page.
Such as: I use ViewState to store property (in case they need to be stored), yet I doesn't output this viewstate to the web page, in case it doesn't need to be restored (would be equal to value in the aspx)? Yet that seems quite a marginal
..... I misunderstood you!
In fact I knew that (but maybe my explanation were not very good) and
thought you were advocating to use ViewState because of that.
And I was replying: it's not a good reason!
However I don't understand why you say it has nothing to do with control!
If I create a new user control in a web control library, VS.NET creates a
template which uses view state like that:
======
public string Text
{
get
{
String s = (String)ViewState["Text"];
return ((s == null) ? String.Empty : s);
}
set
{
ViewState["Text"] = value;
}
}
======
And I was wondering: should I use ViewState (which clutter the web page) to
store my background color property?
Furthermore I was also wondering:
is there a way to use the code as below (seemingly using ViewState) but flag
the control somehow not to output anything on the page. In such a way
another developer could always flag it back to use viewstate (in the page)?
"Marina" <so*****@nospam.com> wrote in message
news:eQ**************@TK2MSFTNGP15.phx.gbl... Disagree with what?
Nothing you just said had anything to do with what I was saying at all.
Again, defining a property on a page, does not retain the value in that property between postbacks. ViewState is maintained between postbacks, since it is sent down with the page to the browser, and sent up to the server with the post.
This is just a fact about how things work. There is nothing here about labels, controls, etc. I'm sorry, but I have no idea what you are talking about.
"Lloyd Dupont" <net.galador@ld> wrote in message news:eM**************@TK2MSFTNGP12.phx.gbl...I disagree. If it's a valid argument for a textbox, a simple label, which value is written in the .aspx, would always have its value set by code / .aspx. A label, for instance, only VERY MARGINALLY need to keep its valu between postabck. (Because its value would most of the time be present in the page trhough code or something, and szeldom come from user event)
"Marina" <so*****@nospam.com> wrote in message news:uB*************@TK2MSFTNGP14.phx.gbl... The simpler approach will not retain values between postbacks. So you set the property, the user clicks a button, and there is another request to the server. At this point, this property no longer has the value you set. This is because HTTP is stateless, and each request to the server means a new page object is created from scratch.
The ViewState approach works, because the viewstate is posted back to the server, so the value saved in it can be retrieved.
"Lloyd Dupont" <net.galador@ld> wrote in message news:%2****************@TK2MSFTNGP10.phx.gbl... When you define UserControl in source code the sample I see are often like that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type).
So now I wonder, why use the ViewState exactly? I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple.
Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page.
Such as: I use ViewState to store property (in case they need to be stored), yet I doesn't output this viewstate to the web page, in case it doesn't need to be restored (would be equal to value in the aspx)? Yet that seems quite a marginal
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: John Kirksey |
last post by:
I have a page that uses an in-place editable DataGrid that supports sorting and paging. EnableViewState is turned ON. At the top of the page are several search fields that allow the user to filter...
|
by: Steve Drake |
last post by:
All,
I have a CONTROL that contains 1 control (Control ONE), the 1 control that
it can contain 1 or 2 control (Control A and B).
Control A, raises and event and Control ONE receives this event...
|
by: neo |
last post by:
hi,
I am studying ASP.NET and have few questions -
1) The session ID and values of controls is stored in VIEWSTATE
variable. So now when we put EnableViewState="false" in Page directive and...
|
by: Simon |
last post by:
Hi everyone,
I have a quick question that I hope someone can help me with:
I've made a user control that contains a text box and some validation
functionality. This control has a few extra...
|
by: et |
last post by:
I'm not sure I understand the use of the ViewState.
Do I understand correctly that values of controls are automatically held in
a hidden control called ViewState?
If so, then why can't we get...
|
by: RCS |
last post by:
I have an app that I have different "sections" that I want to switch back
and forth from, all while having the server maintain viewstate for each
page. In other words, when I am on Page1.aspx and...
|
by: Mark Broadbent |
last post by:
Been a while since I've touched asp.net but one thing that always seems to
fustrate me is the loss of state on variable declarations. Is there anyway
(i.e. assigning an attribute etc) to instruct...
|
by: hitendra15 |
last post by:
Hi
I have created web user control which has Repeater control and
Linkbutton in ItemTemplate of repeater control, following is the code
for this control
On first load it runs fine but when...
|
by: paul.hester |
last post by:
Hi all,
Does anyone know why the ViewState would be empty?
When I'm receiving a postback, I can access a posted value using
controlName.Value but not ViewState.
I have EnableViewState set...
|
by: Nick C |
last post by:
Hi
How can i reduce the viewstate for my asp.net application. It is getting
very large now. What is a good solution?
thanks
N
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |