Hi Brad,
How are you doing on this post. Does the suggestions in my last reply helps
a little? If there're anything else we can help, please feel free to post
here.
Thanks,
Steven Cheng
Microsoft Online Support
Get Secure!
www.microsoft.com/security
--------------------
| X-Tomcat-ID: 54974071
| References: <
[email protected]>
<
[email protected]>
| MIME-Version: 1.0
| Content-Type: text/plain
| Content-Transfer-Encoding: 7bit
| From: (e-mail address removed) (Steven Cheng[MSFT])
| Organization: Microsoft
| Date: Fri, 30 Sep 2005 03:38:33 GMT
| Subject: Re: IStateManager in a class object
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
| Message-ID: <
[email protected]>
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| Lines: 111
| Path: TK2MSFTNGXA01.phx.gbl
| Xref: TK2MSFTNGXA01.phx.gbl
microsoft.public.dotnet.framework.aspnet:128162
| NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182
|
| Hi Brad,
|
| My understanding on your question is that you want your custom component
| class be able to automatically be able to utilize the asp.net page's
state
| management, (e.g. persist and load states into/from viewstate).
| If so, I'm afraid a normal class can not automatically hook into these
| process/ events model since the ASP.NET page doesn't know that it need to
| call your custom class's certain state mangement api. To achieve this, we
| need to override page class's LoadViewState/SaveViewState funciton or
hook
| into the Init ,Load, event so as to construct and populate your custom
| class's instance on the page. However I don't think this is possible for
a
| common component class.
|
| So the option left to us is just derive our class from the
| System.Web.UI.Control, and when used on page, it is added into the
asp.net
| page's control collection. So that ASP.NET page will know that it need to
| call your object(control)'s state management methods at the proper time.
| Actually we can find some realworld examples like the DataSource controls
| in asp.net 2.0, though they're only utility components which haven't UI
| related task, they're still designed as Control since they need to hook
| into the asp.net page's runtime event model and state management steps.
|
| Thanks,
|
| Steven Cheng
| Microsoft Online Support
|
| Get Secure!
www.microsoft.com/security
| (This posting is provided "AS IS", with no warranties, and confers no
| rights.)
|
|
|
|
| --------------------
| | Message-ID: <
[email protected]>
| | From: Brock Allen <
[email protected]>
| | Subject: Re: IStateManager in a class object
| | References: <
[email protected]>
| | MIME-Version: 1.0
| | Content-Transfer-Encoding: 8bit
| | Content-Type: text/plain; charset=iso-8859-1; format=flowed
| | X-Newsreader: JetBrains Omea Reader 671.6
| | Newsgroups: microsoft.public.dotnet.framework.aspnet
| | Date: Thu, 29 Sep 2005 14:55:26 -0700
| | NNTP-Posting-Host: host81-153-126-137.range81-153.btcentralplus.com
| 81.153.126.137
| | Lines: 1
| | Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
| | Xref: TK2MSFTNGXA01.phx.gbl
| microsoft.public.dotnet.framework.aspnet:128115
| | X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
| |
| | Right, so you'll create the helper and it will be empty until
| LoadViewState
| | is called. That's why it's important to forward the overrides to the
| helper.
| | So, yes, ViewState won't be loaded until the Page base class calls the
| LoadViewState
| | virtual.
| |
| | -Brock
| | DevelopMentor
| |
http://staff.develop.com/ballen
| |
| | > Thanks for the reply....but you lost me there. If I'm using this in a
| | > page I understand about overriding the pages LoadViewState,
| | > SaveViewState...and calling the helper class LoadViewState, etc...
| | > The paradox I'm lost on is how the instance of the helper is saved and
| | > reinstantiated such that the value in it's statebag persist. The page
| | > needs to instantiate the helper somewhere. And if the helper has a
| | > constructor which instantiates the statebag, the statebag (and thus
| | > the viewstate) is going to be empty.
| | >
| | > | | > This approach is typically done when a control (or the page) needs to
| | > use
| | > a helper object to track the viewstate. So the usage model is for the
| | > control
| | > to instantiate an instance of the helper object and then override all
| | > of
| | > the IStateManager APIs and call into the helper object for each one
| | > (so
| | > override
| | > LoadViewState and the call into the helper's LoadViewState, etc...).
| | > This
| | > is how the helper object gets 'hooked into' the page model. I hope
| | > that just
| | > made sense
| | > -Brock
| | > DevelopMentor
| | >
http://staff.develop.com/ballen
| | >> I am creating a class (not a control) which implements IStateManager.
| | >> I've created the class and all of the implementations (LoadView,
| | >> SaveViewState, etc...). My Question is: How do I instantiate this
| | >> class in a page and then re-instantiate it on post back such that I
| | >> don't lose it's viewstate? If the page always uses x = new myclass
| | >> to instantiate, the myclass constructor is always going to
| | >> reinitialize its statebag.
| | >>
|
| |
| |
|
|
