You can apply the out-of-the-box XMLFormView webpart to embed an InfoPath form within a SharePoint page. This way, the form displays as a visual integrated part within the SharePoint application, maintaining for the user the full application context (branding, navigation menu's). However, upon doing this (after applying the required infrastructure initialization steps, see this whitepaper), I continuously encounter a runtime Javascript eror when browsing the page in Internet Explorer. The error occurs in INC\Core.js in the ErrorVisualization_ComputeAbsoluteLeft function, used to position an error asterix within the form. Within this method, the DOM-tree is traversed up to the HTML-root. At least that is the intention, but somehow this goes wrong with IE; and the OOTB script is not made robust. This article gives more background details.
So, the problem cause is known. What about the resolution? I don't intend to sacrifice the correct CSS handling, just because IE doesn't handle it well. I see multiple options:
- Making the HTML robust by wrapping the relative positioned DIV within an absolute positioned Body-container
- Runtime overloading the OOTB ErrorVisualization_ComputeAbsoluteLeft function to fix it for IE behaviour
- Use the PageViewer webpart iso XMLFormView to embed the InfoPath form
- Inspect the Core.js code, and find a proper, and more localized solution
Your guess is right, I applied the latter. It appears that although the runtime errors occurs within the ErrorVisualization_ComputeAbsoluteLeft function, the solution can be found within the invoked helper ErrorVisualization_IsPositionCausingElement function. That function returns true if the inspected style object has its overflow property set, and in that case the loop within ErrorVisualization_ComputeAbsoluteLeft stops. The solution is therefore to assign an overflow setting to a proper container element of the XmlFormView. Since CSS styles are applied afterwards, it's not possible to assign this property via CSS. Options are to either place the style inline, or to add it via code - before the ErrorVisualization_ComputeAbsoluteLeft will be invoked. I applied the last. Rationale for this is that I only want to apply the IE-hack / resolution when it is needed. That is, when an XmlFormView is rendered within either IE 6 or 7. Inline style does not allow me to that, javascript does:
<script type="text/javascript">
function fixInfoPathFormView()
{
/*@cc_on
@if (@_jscript_version <= 5.7)
var objFormView = document.all["__XmlFormView"];
if (objFormView != null)
{
var objFormViewContainer = document.all["wrap-center"];
if (objFormViewContainer.style != null && objFormViewContainer.style.overflow == "") objFormViewContainer.style.overflow = "auto";
}
/*@end
@*/
}
</script>
function fixInfoPathFormView()
{
/*@cc_on
@if (@_jscript_version <= 5.7)
var objFormView = document.all["__XmlFormView"];
if (objFormView != null)
{
var objFormViewContainer = document.all["wrap-center"];
if (objFormViewContainer.style != null && objFormViewContainer.style.overflow == "") objFormViewContainer.style.overflow = "auto";
}
/*@end
@*/
}
</script>
<UPDATE>The above workaround is dependent on the installation of SharePoint SP2 in your environment. Prior SP2, the ErrorVisualization_ComputeAbsoluteLeft function does not check via the ErrorVisualization_IsPositionCausingElement function; but just tries to traverse the offsetParent hierarchy until reaching the document.body object. Remedie then to avoid the runtime error is option 1: set the position of the document.body container to static.</UPDATE>
No comments:
Post a Comment