By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,971 Members | 900 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,971 IT Pros & Developers. It's quick & easy.

Problem declaring "Public Property" and "Friend Shared"

P: n/a
Hello,

I have a problem declaring variables. I need to create an object oRpte
as ReportClass on WebForm1.aspx and be able to use its value on
WebForm2.aspx.
For declaring the property oRpte() on WebForm1.aspx, I use "Public
Property" and I declare variable _oRpte as Friend Shared. That's my
problem. If I don't declare _oRpte as Friend Shared, I can't use
WebForm1.oRpte() on other webpage. If I declare _oRpte as Friend
Shared, I can use WebForm1.oRpte() with its old value, but if there
are two users navigating WebPage2.aspx at the same time, then
WebForm1.oRpte() can get different values, I can't keep the same value
of WebForm1.oRpte() for both users.
How should I declare the variables, please?

Public Class WebForm1.aspx
Inherits System.Web.UI.Page
Friend Shared _oRpte As ReportClass
......
' more code
......
Private Sub MyFunction()
Dim oRpt As New MyCrystalReport
oRpt.SetDataSource(MydataTable)
Me.oRpte = oRpt
End Sub

Public Property oRpte() As ReportClass
Get
Return _oRpte
End Get
Set(ByVal strValor1 As ReportClass)
_oRpte = strValor1
End Set
End Property
End Class

On WebForm2.aspx, I try to use object oRpte of WebForm1.aspx, but no
success:

Dim oRptx As New ReportClass
Dim wform As New WebForm1
oRptx = wform.oRpte
' I get error here:
oRptx.SetParameterValue("param1", strMessageOnRapport)
'I can't call oRptx

Should I declare like:
Protected Shared _oRpte As ReportClass
instead of
Friend Shared _oRpte As ReportClass
??

Aug 8 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
jb*****@gmail.com wrote:
Hello,

I have a problem declaring variables. I need to create an object oRpte
as ReportClass on WebForm1.aspx and be able to use its value on
WebForm2.aspx.
For declaring the property oRpte() on WebForm1.aspx, I use "Public
Property" and I declare variable _oRpte as Friend Shared. That's my
problem. If I don't declare _oRpte as Friend Shared, I can't use
WebForm1.oRpte() on other webpage. If I declare _oRpte as Friend
Shared, I can use WebForm1.oRpte() with its old value, but if there
are two users navigating WebPage2.aspx at the same time, then
WebForm1.oRpte() can get different values, I can't keep the same value
of WebForm1.oRpte() for both users.
How should I declare the variables, please?
WebForms don't maintain per-user state. If you need to maintain
per-user state, use Session variables. If you're using InProc session,
you'll need to make very few changes to your code [just replace
assignments to _oRpte with Session("oRpte") =, and references to _oRpte
with CType(Session("oRpte"),ReportClass)]. If you're using StateServer
or SQL Server state, you'll probably have more issues, since in this
case, ReportClass would have to be serializable.

If it isn't feasible for ReportClass to be serializable, you may have
to go for a more hackish approach (e.g. having a global hashtable using
the users session id to find a reference to the ReportClass - this may
scale poorly, and become unmanageable, and you'll need to have some way
of discarding "old" session information)

Damien

Aug 8 '06 #2

P: n/a
I was using Session("oRpte") for a long time, but I think that it
consumes more memory and down performance (I think Crystal Report in a
Session is too much).

Even if I declare Protected Friend o_Rpte as ReportClass, would I have
the same problem?

Anyway, thank you very much, Damien.

Aug 8 '06 #3

P: n/a
Big George wrote:
I was using Session("oRpte") for a long time, but I think that it
consumes more memory and down performance (I think Crystal Report in a
Session is too much).

Even if I declare Protected Friend o_Rpte as ReportClass, would I have
the same problem?

Anyway, thank you very much, Damien.
Hi George,

You're trying to maintain state between two separate requests to the
server. That's exactly the problem that Session was built as the
solution to. You're question about having a property that's visible to
one page from another suggests to me that you've not quite "got" the
ASP.NET page model yet (apologies if that sounds offensive, or if you
do understand the ASP.Net page model quite well):

In ASP.Net, each request comes in, an instance of the page which is
being requested is created, the page processes the request, and then
the instance goes out of scope (to be Garbage collected at some point
in the future). So when the second request comes in (to WebForm2),
there's no way to get hold of a reference to the *instance* of WebForm1
which processed the previous request for the same user. It may have
been GCed already. As you've already discovered, the only way for
WebForm1 to have a property which you can reference from WebForm2 is
for the property to be Shared. But in this case, there's only one copy
of the property for the entire application, which as you've spotted,
makes it a single user system.

I think you come down to having two (and two half) choices:
1) Store the report in the session.
2) Keep the information in the session to recreate the report
[3]) Store all of the reports in a hashtable, keyed by the session ID.
[4]) Store a reference to WebForm1 in the session.

1 and [3] will keep the entire report in memory (as would your
approach, based on what you were trying to do), so will still have the
memory and performance issues you observed previously.

2 will reduce your memory overhead, but will have a greater performance
effect (probably).

[4] will let you use the property that you've been trying to add. But
it's just going to be even more wasteful of memory that 1, and a small
additional processing overhead.

So you need to decide whether you're optimizing for memory or
performance, and pick the winner from there. ([3] is a poor version of
1, but works for out of process session state. But you need to manually
declutter to prevent memory exhaustion)

Damien

Aug 8 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.