I use Stephen Lebans modReportToPDF...

[MLH]

I use Stephen Lebans modReportToPDF. In it is a function
declared as Boolean. Inside the FN, there's a line assigning
the FN name a value that's not True and not False. I'm thinking
that's an oversight so I changed it from "" to False. Just wanna
make sure there's not some support of the use of the ZLS value.

Public Function ConvertReportToPDF( ... ) As Boolean
....

If Len(RptName & vbNullString) = 0 Then
' No valid parameters - FAIL AND EXIT!!
ConvertReportToPDF = ""
Exit Function
End If
I think the assignment line should be...
ConvertReportToPDF = False
and that setting it to a zero-length string was
an oversight.

Would there be any reason that assigning the
null string value would be logical?

[Albert D. Kallal]

the If Len(RptName & vbNullString) = 0 Then

' No valid parameters - FAIL AND EXIT!!
ConvertReportToPDF = ""
Exit Function
End If

Would there be any reason that assigning the
null string value would be logical?

The comments *right* before that line say "FAIL" and exit.

They don't just say *exit*.

That assignment will fail, and trigger the error handling code. If you look
at the error handling code, there is a Significant amount of cleanup and
release of variables and other things that occur.

I suppose one could have actually put in a goto to the jumping of the error
handling code, but the above code means that you fail regardless of the name
of the subroutine name given to the error handling code you've setup.

It is also entirely possible that this is a typo on Stephens part, but I'm
not sure, since the error handling code does seem to do a fair bit of
cleanup and then exits. just reading the code, my bets are this is an
intentional forced error. (I should also that the compiler does not catch
this error, as you can legally assign a strained to a Boolean variable, as
long as that string is yes, no, true, false, 0,-1 etc.).

Hopefully Stephen will chime in, but my spider sense tells me that is an
intentional error trigger.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[Stephen Lebans]

Unfortunately, I cannot remember that far back in time. It certainly looks
like a typo to me. The function signature return value is Boolean so it
should return a Boolean value, period!

Poor engineering Doug. Please don't tell my brother!<grin>

--

HTH
Stephen Lebans
http://www.lebans.com
Access Code, Tips and Tricks
Please respond only to the newsgroups so everyone can benefit.
"Albert D. Kallal" <Pl*******************@msn.comwrote in message
news:GQ5Sj.103945$Cj7.3949@pd7urf2no...

>
the If Len(RptName & vbNullString) = 0 Then

> ' No valid parameters - FAIL AND EXIT!!
ConvertReportToPDF = ""
Exit Function
End If

>Would there be any reason that assigning the
null string value would be logical?

The comments *right* before that line say "FAIL" and exit.

They don't just say *exit*.

That assignment will fail, and trigger the error handling code. If you
look at the error handling code, there is a Significant amount of cleanup
and release of variables and other things that occur.

I suppose one could have actually put in a goto to the jumping of the
error handling code, but the above code means that you fail regardless of
the name of the subroutine name given to the error handling code you've
setup.

It is also entirely possible that this is a typo on Stephens part, but I'm
not sure, since the error handling code does seem to do a fair bit of
cleanup and then exits. just reading the code, my bets are this is an
intentional forced error. (I should also that the compiler does not catch
this error, as you can legally assign a strained to a Boolean variable, as
long as that string is yes, no, true, false, 0,-1 etc.).

Hopefully Stephen will chime in, but my spider sense tells me that is an
intentional error trigger.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[MLH]

Albert, I think you are correct. Stephen does have
ConvertReportToPDF = False embedded in his
error handler under ERR_CREATSNAP:
That ensures a correct Boolean setting when the
procedure ends. Likely intentional. Nice.

Thx to both of you for the input.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxx