move code behind file to module

[Guoqi Zheng]

Dear sir,

If I need to use a function on xxx.aspx page, e.g. on a repeater control, I
have to define this function inside xxx.aspx.vb file, if I put it in the
module class, it will not work so I have to copy the same function into all
aspx page which may need it.

Is it possible that I define this function something in the application, I
can use it on every .aspx page??

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

 

[Karl]

Guoqi:
Yes, the function doesn't have to reside in the codebehind file in order to
be usedin your aspx page.

namespace misc{
public sealed class Utility{
private Utility(){}
public static string FormatDate(object date) {
if (date == DBNull.Value){
return "n/a";
}
try{
return ((DateTime)date).ToShortDateString();
}catch{
return "n/a";
}
}
}
}


can be used from your aspx page, such as:

<asp:Repeater id="repeater" Runat="server">
<ItemTemplate>
<%# misc.Utility.FormatDate(DataBinder.Eval(Container.DataItem,
"Ordered"))%>
</ItemTemplate>
</asp:Repeater


or you can even put:

<%@ Import namespace="misc" %> at the top of the page and then do:

<asp:Repeater id="repeater" Runat="server">
<ItemTemplate>
<%# Utility.FormatDate(DataBinder.Eval(Container.DataItem,
"Ordered"))%>
</ItemTemplate>
</asp:Repeater>


Karl

 

[bruce barker]

the best approach for this is to create a base codebehind page, and have all
you other codebehinds inherit from this page.


the base page (myBasePage.cs):

public class MyBasePage : System.Web.UI.Page
{
// any common functions in here
}

on your code behind page , change the inheritance to MyBasePage:

public class MyCodeBehindPage : MyBasePage
{
}

-- bruce (sqlwork.com)

 

[Guoqi Zheng]

Are you sure? I always meet an error when I do that.

--
Kind regards

Guoqi Zheng
guoqi AT meetholland dot com
Http://www.meetholland.com

 

[Karl Seguin]

It would be helpful if you told us what the error is and perhaps provided
sample code.

 

[Kevin Spencer]

I believe your confusion stems from not thinking in Object-oriented terms.
At run-time, there are no "files" involved in the application process. Files
are compiled into classes, and classes are what you need to think about, not
files. For example, you can define multiple classes in a single file. So,
obviously, the file is irrelevant.

If you need functionality to be available to multiple Page classes, you
define that functionality in a class that is separate from your Page class
code. Then you use that class in your Pages.

This is not something you don't already know how to do. Every time you use a
..Net CLR class, function, or namespace, you are referring to classes that
exist outside your Page class. They exist in DLLs that are stored in the
Global Assembly Cache. When you create a file that defines a class,
regardless of whether you compile it into a DLL or not, you are creating the
same thing.

OOP is all about abstraction. Think of the abstract entities, the classes,
rather than the files and code that define them, and you'll be a lot better
off.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living