On 2/18/03, webguy penned:
>Are you sure that variables.shipping is _ALWAYS_ defined? Are you sure there
>is no case where it is not?
Normally it isn't. I usually check whether form.includeshipping is
defined first, then create my variables.shipping variable. Then the
code where the error occurs. To test, I removed the
isDefined('form.includeshipping') check and created the
variable.shipping variable (and the other 4) no matter what.
The thing is, if it WASN'T defined, then CF would tell me it wasn't
defined and tell me the line of code where I was calling it. With
these phantom errors, there is really nothing wrong, so CF just
points to the cfinclude that calls the file. That doesn't help much
when your included file is hundreds of lines long. :)
But as you'll see from my workaround, the error was caused by the
placement of the cfoutput tag, which is totally nonsensical. I mean,
either should be acceptable, but I was taught that the way I had it
first is preferable.
I mean, sometimes it's hard to find errors when your code IS screwed
up. When CFMX creates errors on acceptable code, it REALLY makes it
hard to find them.
--
Bud Schneehagen - Tropical Web Creations
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
ColdFusion Solutions / eCommerce Development
[EMAIL PROTECTED]
http://www.twcreations.com/
954.721.3452
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Signup for the Fusion Authority news alert and keep up with the latest news in
ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
