<!--#include file="filename" -->

Using a server-side include, what do you do when your include file uses functionality from another include file...

Include1.asp

<%
    Public Function Magic(spell)
        Magic = Null ' Something magical
    End Function
%>

Include2.asp

<%
    Public Function Cast(spell)
        Cast = Magic(spell) ' Requires Include1.asp for Magic()
    End Function
%>

I could use a server-side include to bring Include1.asp into Include2.asp, however, if the script that includes Include2.asp has already included Include1.asp then it'll blow up. Otherwise, I could document that including Include2.asp requires that you first include Include1.asp, but I'd prefer a more reliable way...

Do any of you Web developers out there know a solution for this? My solution needs to be specific to IIS.

Wait a minute... I thought you hated both magic and spells

I couldn't think of any short simple examples (that aren't actually in use) so I just made those up... When have I ever said that I hate magic or spells? Afterall, I love Final Fantasy.

Without knowing how ASP Classic works too well, can you enclose the function defintions in an if statement that only executes once?

Ahh my mistake, I remember you saying you didn't like LoTR and Harry Potter because they used magic...

I believe you can, but it's been a while since I've had the unpleasant experience of working with ASP. Server side includes are hacks which is pathetic for language that obviously has a large need for them. For instance, you cannot even (easily) dynamically include files because you cannot insert code in the <!-- directives //-->.

I'm not sure, but I think declarations are first 'executed' and then the code is executed. If I'm right, the function would be declared before the if statement was executed... Damn Web programming!

Nah, the reason I don't like LoTR and Harry Potter is because they're girly...

I don't think you are, because I (think I) remember wrapping IFs around some of my ASP include files.

I wasn't sure myself so I just tried the following...

<%
    If False Then
        Public Function x()
            x = 5
        End Function
    End If

    Response.Write ("x=" & x())
%>

...and the output was...

x=5

Well, don't include Magic on pages where you include Cast. Alternatively, include Magic on every page that includes Cast, and don't include Magic from Cast.

I was hoping for a more user-friendly (less error-prone) way of doing it, but since there doesn't appear to be one we've decided (at least until a better solution is found) to require the developer to manually include Magic when using Cast.

I remember now... I think I created my own include function that read files from disk and "eval'd" them. Ugh, I wish I could completely forget that I ever had to use ASP.

Vaguely Related Rant

VBScript's developers thought it would be clever to crash when VBScript's conversion functions (CInt, CLng, CDbl, CByte, CBool, etc.) received Null as a parameter. Since Null is a very common value when dealing with database data you can imagine the number of Null checks a single script can incur... As such, I wrote wrappers around them to ease their use. I thought I would be out of the woods, but apparently not...

    Public Function ToString(strValue)
        If Not IsNull(strValue) Then
            ToString = CStr(strValue)
        Else
            ToString = ""
        End If
    End Function

I was using ToString() to convert database data to the String subtype and to my frustration the script halted because an unexpected value had been passed to CStr. WTF!? To figure out the cause, I decided to output the subtype just before the IsNull check to determine what the cause could be...

    Public Function ToString(strValue)
Response.Write "strValue = " & VarType(strValue) & "<br />"
        If Not IsNull(strValue) Then
            ToString = CStr(strValue)
        Else
            ToString = ""
        End If
    End Function

Output

strValue = 8
strValue = 8
strValue = 1
strValue = 8

...followed by the HTML... That's right, somehow that one (non-altering) statement managed to alter the data anyway and result in the script executing perfectly. WTF!?!?!?!?! Now I had some idea what the problem was, but to be sure I made the following adjustments...

    Public Function ToString(strValue)
On Error Resume Next
        If Not IsNull(strValue) Then
            ToString = CStr(strValue)
        Else
            ToString = ""
        End If
If Err.Number <> 0 Then Response.Write "strValue = " & VarType(strValue) & "<br />"
Err.Clear()
On Error GoTo 0
    End Function

Output

strValue = 1

...followed by the HTML. So the subtype of the problem value is 1, which corresponds to... WTF!?!??!?!??!??!?!!?? vbNull!?!??!1111

That's correct, ladies and gentlemen, apparently IsNull() only catches Null when it wants to...

The Fix

    Public Function ToString(strValue)
        If Not IsNull(strValue) And strValue <> Null Then
            ToString = CStr(strValue)
        Else
            ToString = ""
        End If
    End Function

I'm sure that I read somewhere that you shouldn't use the comparison operators (=|<>) on Null because either it doesn't work correctly or it can cause bad things... It seems to be working so I guess this is how it is until it halts the script again. :'(

**EDIT**

Update

That didn't last long... Passing a string ("06/27/2007") into ToString() results in evaluating strValue <> Null as False... :'( Therefore, ToString(.Item("Date")) = "", even though .Item("Date") = "06/27/2007". So I guess that's why you can't use comparison operators for Null... :-/ Maybe if I just forget about IsNull and check that VarType(strValue) <> vbNull... :-/

**EDIT**

Solution (I Hope :'()

Negative. Somehow that doesn't catch Null and it slips through anyway... :-/ There must be some serious bugs in VBScript's subtype system... :-/ Why would I say that? Well, on a hunch (read: out of desperation) I tried the following...

    Public Function ToString(strValue)
        If Not IsNull(strValue) And strValue <> "" Then
            ToString = CStr(strValue)
        Else
            ToString = ""
        End If
    End Function

So far, it appears to be work... You can safely pass an Empty String ("") into CStr() without problems. So if checking that the parameter doesn't equal an empty string ("") catches the problem that means that somehow Null and Empty String ("") overlap or something in VBScript's subtype system... WTF!? >:(

** EDIT **

Giving In To Insanity

' F**K <-- WHO WROTE THAT!??!??!

Apparently the empty string check (see Solution (I Hope :'() above) is not enough to evade the demons of VBScript... The only reliable way I can think of to avoid script halting and still convert to a string subtype is to disable script halting (On Error Resume Next), clear any errors (Err.Clear()), attempt the conversion (CStr()), check for errors (Err.Number <> 0), clear any errors (Err.Clear()), and re-enable script halting (On Error GoTo 0). When you put it all together it looks something like this...

    Public Function ToString(strValue)

        On Error Resume Next ' Evil.
        Err.Clear()

        ToString = CStr(strValue)

        If Err.Number <> 0 Then ToString = ""
        Err.Clear()
        On Error GoTo 0

    End Function

I'm so sorry you had to see that... :-/

Switch to .NET

I used the On Error method as well.

Managers who insist that their employees use ASP obviously have absolutely no programming knowledge. There is no reason to use it. PHP is better than ASP in every way. (I use PHP as the example only because of its similar page-based approach.)

Or, as Ryan suggests ... switching to .NET is better. Switching to anything else is better.

The problem is that it's a rather large system and switching technologies now (while very desirable for developers) will require convincing clients that we should redo what we've already done...

If we do get the chance to rewrite it in another technology it will probably be .NET.

I've already used the On Error method to wrap array functionality... It's just a horrible way to develop...

Try using Javascript instead of VBScript if possible. I just only wish I thought about that when I was programming ASP.

That would again require switching technologies... It could be done, but then you'd have 99% of the server-side system done in VBScript and 1% done in JavaScript. On top of that, I doubt any of us currently know how to use JavaScript server-side so it would require a slight learning curve... Anyways, if we're gonna switch languages we would use .NET stuff.

Heh, I'm just glad I don't have a programming job... if I decide to use PHP, then PHP it is...