R
Ryanker
I recently had a problem is loading InfoPath forms on my MOSS site in
Internet Explorer. (No error when testing in Firefox.) The prblem ocurred
after I deployed a LOT of changes including user controls, javascript and CSS.
When the page loaded, IE showed a javascript error:
Line: 4997
Char: 1
Error: Object Expected
Code: 0
Url: <my URL>
Of course IE didn't bother to tell me which file the error was in, just the
line number. Real helpful.
After adding blank lines to various files to see what changed the reported
line number, I found that the error was in INC\Core.js in the
ComputerAbsoluteLeft function. This method is used to, among other things,
add the red asterisk to required text fields. The while loop in that
function takes one of the IP input object as an argument, and uses the
offsetParent property to walk up the tree of HTML DOM elements until it gets
to the <body> tag. In Firefox, the offset parent of one of my DIVs was
correctly determined to be the <body> tag. In IE (6 and 7), however, the
offsetParent of my DIV was the top-level HTML element. The error ocurred
when the code in the while loop condition tried to get the offsetParent of
the HTML element.
I won't bore you with all the nitty gritty details of my Google searches and
funky javascript workarounds in Core.js, but the problem came down to having
style="position:relative" in one of my DIVs.
I'm kinda disappointed that the javascript is so fragile that it fails if
your have (what seems to me to be) a perfectly reasonable style on one of the
DIVs. You would think they would add a try/catch to ComputerAbsoluteLeft and
ComputeAbsoluterTop so that IF it gets an error in the while, it doesn't
completely fail. I haven't worked out the details, but I'm sure there's a
way to make those functions return the correct value, even if one of the DIVs
in the tree has position:relative.
Bottom line: if you get an error on line 4997 and you don't see red
asterisks on your required fields, check for either position:relative or
position:absolute on one of the HTML elements above your InfoPath form.
Internet Explorer. (No error when testing in Firefox.) The prblem ocurred
after I deployed a LOT of changes including user controls, javascript and CSS.
When the page loaded, IE showed a javascript error:
Line: 4997
Char: 1
Error: Object Expected
Code: 0
Url: <my URL>
Of course IE didn't bother to tell me which file the error was in, just the
line number. Real helpful.
After adding blank lines to various files to see what changed the reported
line number, I found that the error was in INC\Core.js in the
ComputerAbsoluteLeft function. This method is used to, among other things,
add the red asterisk to required text fields. The while loop in that
function takes one of the IP input object as an argument, and uses the
offsetParent property to walk up the tree of HTML DOM elements until it gets
to the <body> tag. In Firefox, the offset parent of one of my DIVs was
correctly determined to be the <body> tag. In IE (6 and 7), however, the
offsetParent of my DIV was the top-level HTML element. The error ocurred
when the code in the while loop condition tried to get the offsetParent of
the HTML element.
I won't bore you with all the nitty gritty details of my Google searches and
funky javascript workarounds in Core.js, but the problem came down to having
style="position:relative" in one of my DIVs.
I'm kinda disappointed that the javascript is so fragile that it fails if
your have (what seems to me to be) a perfectly reasonable style on one of the
DIVs. You would think they would add a try/catch to ComputerAbsoluteLeft and
ComputeAbsoluterTop so that IF it gets an error in the while, it doesn't
completely fail. I haven't worked out the details, but I'm sure there's a
way to make those functions return the correct value, even if one of the DIVs
in the tree has position:relative.
Bottom line: if you get an error on line 4997 and you don't see red
asterisks on your required fields, check for either position:relative or
position:absolute on one of the HTML elements above your InfoPath form.