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

Calling a method in different aspx.vb code page

P: n/a
I've got a VB .NET Web application that has several frames (for discussion
sake, let's call them Form1.aspx and Form2.aspx). I want to be able to call
a code module in Form2.aspx.vb from code module in Form1.aspx.vb. How do I
format this statement?
I'm not interested in calling client-side script on Form2.aspx from
Form1.aspx.vb - I want to fire off server-side module in Form2.aspx.vb
Nov 21 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
A Standard Module is part of the server side compilation, and provides a more
reliable place to store commonly used functions. Since a page is
instantiated, it may or may not exist. Page methods are not, to the best of
my knowledge, accessible between pages. The Session is a good place to
store objects that maintain state. You can create an object through a class
module, and store and retrieve that object through a Session variable.
Session variables are available to various pages of a single Session.

"johnf401" wrote:
I've got a VB .NET Web application that has several frames (for discussion
sake, let's call them Form1.aspx and Form2.aspx). I want to be able to call
a code module in Form2.aspx.vb from code module in Form1.aspx.vb. How do I
format this statement?
I'm not interested in calling client-side script on Form2.aspx from
Form1.aspx.vb - I want to fire off server-side module in Form2.aspx.vb

Nov 21 '05 #2

P: n/a
John,

In addition to Charlie,

You cannot call a method in form1 from form2.

Every form is stateless, which means that when it loads it start everytime
again new.

As Charlie stated, you can pass information between forms. There are more
methods for that, however all will in my opinion probably fail in your
situtation except the already by Charlie suggested Session.

Just a little addition.

Cor
"johnf401" <jo******@discussions.microsoft.com>
I've got a VB .NET Web application that has several frames (for discussion
sake, let's call them Form1.aspx and Form2.aspx). I want to be able to
call
a code module in Form2.aspx.vb from code module in Form1.aspx.vb. How do
I
format this statement?
I'm not interested in calling client-side script on Form2.aspx from
Form1.aspx.vb - I want to fire off server-side module in Form2.aspx.vb

Nov 21 '05 #3

P: n/a
On 2004-10-30, Charlie <Ch*****@discussions.microsoft.com> wrote:
A Standard Module is part of the server side compilation, and provides a more
reliable place to store commonly used functions. Since a page is
instantiated, it may or may not exist. Page methods are not, to the best of
my knowledge, accessible between pages.
No, there's nothing special about code-behind modules, they're just
regular classes.

To call a non-shared function inside Form2.aspx.vb, instantiate the
class and call the function. The fact that it's in an aspx.vb as opposed
to simply a .vb file is irrelevant.

Dim frm as New Form2
frm.SomeFunction()

BTW, I do agree that doing this represents a pretty bad design, and it's
much better to move the common code into a "standard" class. Also,
performance will be worse than it should be, since code-behind classes
are fairly heavy since they derive from Page. But there's no technical
reason stopping one from doing this.

The Session is a good place to
store objects that maintain state. You can create an object through a class
module, and store and retrieve that object through a Session variable.
Session variables are available to various pages of a single Session.

"johnf401" wrote:
I've got a VB .NET Web application that has several frames (for discussion
sake, let's call them Form1.aspx and Form2.aspx). I want to be able to call
a code module in Form2.aspx.vb from code module in Form1.aspx.vb. How do I
format this statement?
I'm not interested in calling client-side script on Form2.aspx from
Form1.aspx.vb - I want to fire off server-side module in Form2.aspx.vb

Nov 21 '05 #4

P: n/a
David,

Technicaly you are right, however what is the sense of instansing a complete
New form in or windowsforms or webforms for using a method in that.

By stating as you do people can get the idea that it is possible in Webforms
as it is as well in Windowforms to reference an already used form class
(with setted information), what is in my opinion in a webform impossible,
while it is easy possible in a winform when you pass the sending form (the
one which was first) in an overloaded Sub New to the let say form2. (Not
nice code by the way).

Just my thought,

Cor

Nov 21 '05 #5

P: n/a
On 2004-10-31, Cor Ligthert <no************@planet.nl> wrote:
David,

Technicaly you are right, however what is the sense of instansing a complete
New form in or windowsforms or webforms for using a method in that.
I quite plainly said it was a bad design.
By stating as you do people can get the idea that it is possible in Webforms
as it is as well in Windowforms to reference an already used form class
(with setted information), what is in my opinion in a webform impossible,
while it is easy possible in a winform when you pass the sending form (the
one which was first) in an overloaded Sub New to the let say form2. (Not
nice code by the way).


Perhaps, but I think it's important to be clear about what is
technically impossible and what is really bad design. I was more
focused on correcting the errors in the previous post (not your post),
so perhaps I should do that explicitly.

"Standard Module is part of the server side compilation"

This is true of the code-behind class as well.

"Since a page is instantiated, it may or may not exist."

This is true of any class. It's not true of a VB.Net Code Module, nor
would it be true if the first Form used shared functions.

"Page methods are not, to the best of my knowledge, accessible between pages. "

They are. Methods in Page-derived classes are just as accessible as a
method in any other class. The class is just a bit top-heavy for
regular use.

Anyway, I suppose we should help the original poster a little more
directly, so in response to the top of the thread.

The fact that two forms load as frames on a single page is totally
irrelevant to ASP.Net. The two forms load as two individual page
requests, just as they would if the two pages weren't in a frame at all.
There's no way for one page request to reference another page request,
except by using things like the Session object as has been suggested.

Also, keep in mind that frames don't necessarily load in order. So if
you want Form2 to reference a session variable that Form1 has set, then
you'll have to do something special to ensure that Form1 is loaded
first. (This one will bite you, because *usually* the frames will load
in order, especially when debugging locally).
Nov 21 '05 #6

P: n/a
David,

Very nice message,

I stuffed the part in my messaged where I wrote that you had stated it as
bad code, because for me that was included in my sentence that you are
technicaly right..

Cor

"David" <df*****@woofix.local.dom>
..
On 2004-10-31, Cor Ligthert <no************@planet.nl> wrote:
David,

Technicaly you are right, however what is the sense of instansing a
complete
New form in or windowsforms or webforms for using a method in that.


I quite plainly said it was a bad design.
By stating as you do people can get the idea that it is possible in
Webforms
as it is as well in Windowforms to reference an already used form class
(with setted information), what is in my opinion in a webform impossible,
while it is easy possible in a winform when you pass the sending form
(the
one which was first) in an overloaded Sub New to the let say form2. (Not
nice code by the way).


Perhaps, but I think it's important to be clear about what is
technically impossible and what is really bad design. I was more
focused on correcting the errors in the previous post (not your post),
so perhaps I should do that explicitly.

"Standard Module is part of the server side compilation"

This is true of the code-behind class as well.

"Since a page is instantiated, it may or may not exist."

This is true of any class. It's not true of a VB.Net Code Module, nor
would it be true if the first Form used shared functions.

"Page methods are not, to the best of my knowledge, accessible between
pages. "

They are. Methods in Page-derived classes are just as accessible as a
method in any other class. The class is just a bit top-heavy for
regular use.

Anyway, I suppose we should help the original poster a little more
directly, so in response to the top of the thread.

The fact that two forms load as frames on a single page is totally
irrelevant to ASP.Net. The two forms load as two individual page
requests, just as they would if the two pages weren't in a frame at all.
There's no way for one page request to reference another page request,
except by using things like the Session object as has been suggested.

Also, keep in mind that frames don't necessarily load in order. So if
you want Form2 to reference a session variable that Form1 has set, then
you'll have to do something special to ensure that Form1 is loaded
first. (This one will bite you, because *usually* the frames will load
in order, especially when debugging locally).

Nov 21 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.