Using Page Object in VB Class File

  • Thread starter Thread starter Bijoy Naick
  • Start date Start date
B

Bijoy Naick

My project contains multiple aspx pages. Many of these pages have
code-behind that use several helper functions.

Instead of copying each helper function into each aspx page, I am
thinking of using a VB Class file to store these.

Questions -

- How would I "include" this class in each aspx page?

- How would I call the functions?

- One of my functions does a "Page.FindControl". How can I make the Page
object accessible within the class file? When I use Page.FindControl in
my VB class file, VS .NET displays an error = "Reference to a non-shared
member requires an object reference". I've imported system.web in the
class file.

Thx.

Bijoy

*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
 
Bijoy,
- How would I "include" this class in each aspx page?
Click to expand...
Just create a module in your project. It will be in the assembly, and
automatically "included" (accessible) from all your pages.
- How would I call the functions?
Click to expand...
MyModule.MyFunction( arg1, arg2 )
- One of my functions does a "Page.FindControl". How can I make the Page
object accessible within the class file
Click to expand...
Function MyFunction( pg as Page ) As String
Dim ctrl as Control = pg.FindControl("Blah")
If ctrl Is Nothing Then Return "Where Is It" Else Return "Found It"
End Sub

hope that helps!
 
Alex Papadimoulis said:
Bijoy,

Just create a module in your project. It will be in the assembly, and
automatically "included" (accessible) from all your pages.
Click to expand...

I personally recommend against modules, which are a pre-OO feature. Instead,
go ahead and create a Public class with Public Shared subs and/or Functions.
MyModule.MyFunction( arg1, arg2 )
Click to expand...

MyClass.MyFunction(arg1, arg2)
Function MyFunction( pg as Page ) As String
Dim ctrl as Control = pg.FindControl("Blah")
If ctrl Is Nothing Then Return "Where Is It" Else Return "Found It"
End Sub
Click to expand...

Pretty good, but if you make the signature be:

Function MyFunction(ctl as Control)

then you'll be able to handle cases where you don't want to search the whole
page.
 
You can create PageBase class which inherits from web.page and write all functions here..
In aspx page codebehind class inherit this Pageclass..
It is like this
Your PageBAse class:inherits web.page
write all ur functions
end class

ur aspx.vb code behind class
public class urpagename:PageBase
u can refer using base.function name...
end class
 
John,

No reason to recommend against modules. If you look at the compliation, a
Module is created as a public singleton class with all methods static
(shared). Modules are therefore OO. Avoiding them because at one point they
were pre-OO is like avoiding methods from the Microsoft.Visualbasic
namespace (such as Left()) -- it really weakens your toolset as a VB
programmer for no reason.
 
Alex Papadimoulis said:
John,

No reason to recommend against modules. If you look at the compliation, a
Module is created as a public singleton class with all methods static
(shared). Modules are therefore OO. Avoiding them because at one point they
were pre-OO is like avoiding methods from the Microsoft.Visualbasic
namespace (such as Left()) -- it really weakens your toolset as a VB
programmer for no reason.
Click to expand...

Alex,

Can one inherit from a module? Can one add nonstatic members?

Since a class can do everything a module can do plus far more, I see no
reason to use modules at all.
 
I agree with John. The problem is, most people coming from a VB background
are not familiar with true object-oriented technology, and using a Module is
an easy way for a non-object-oriented developer to create applications
without knowing too much about the new paradigm. Static methods and
properties should be used with great caution, and only where appropriate.
They can be quite problematic. While ASP and VBScript are very forgiving, a
compiled application using the entire CLR as its back end requires a good
bit more discipline than most people coming from a VB background are used
to, and/or willing to employ. IMO, VB.Net is a bit TOO forgiving, under the
circumstances.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
You make a good point. However, when one creates a utility singleton class,
it is generally final (NotInheritable) by design or in practice. Modules are
ideal for utility functions (which I believe the original poster needed).
What's nice about utility functions is you do not need to specify the module
they are in, which is another VB-convience thing.

I'm not advocating using them as part of an enterprise framework, but for
small basic applications (which cover most), they're just an easier path to
the same end.
 
A bad programmer can abuse any language. I get to see it every day at
TheDailyWTF.com. I don't see how advocating against using a time-saver (a
big part of VB) is going to make any difference in the quality of a product.

"Oh, so I have to call my Modules a 'Class' and add the word 'Shared' to my
Subs. Um, whatever"
 
I'd love to know how creating a Module saves time compared to creating a
Class.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Alex Papadimoulis said:
A bad programmer can abuse any language. I get to see it every day at
TheDailyWTF.com. I don't see how advocating against using a time-saver (a
big part of VB) is going to make any difference in the quality of a product.

"Oh, so I have to call my Modules a 'Class' and add the word 'Shared' to my
Subs. Um, whatever"
Click to expand...

More important is the mindset. A module is just some glob of code. The name
of the module doesn't even matter, since you don't need to specify it!

On the other hand, most of the time, even a simple OO design uses very few
cases of public-class-with-only-public-static-members. If those methods have
something in common, then they probably have a class in common, and should
be members of that class.

Really, once you get the hang of it (or once you're taught properly), OO is
just much more natural. In this case, you won't wind up creating some
"Module" which has to do things _to_ various objects, from the outside.
Instead you'll create public methods which do something _with_ the object to
which they belong.
 
Utility.StripHtml() .... StripHtml() ... hmmm ... well ...

Okay. So it doesn't save any significant time. But neither does Left(s,4) vs
s.SubString(0,4) ... I suppose my point is that it's all part of the VB
toolbox. One thing that's nice (debatably?) about VB is that someone without
much background can very easily create a quick & dirty application. You
don't need to make business classes or anything like that if you just have a
simple webpage that loads and saves stuff from a database. And a Module is a
the perfect fit for helper functions to the little web page.

On the subject ... C# folks now (2.0) get a "module" of their own by
allowing classes to be declared static.
 
Back
Top