Set Tab layout order defect 8.1.1.2

Last year i looked at a Siebel feature that prevented tab orders from being adhered to on Popup Form applets.

This was tested in 8.1.1.1, but under 8.1.1.2, this solution dosnt work anymore. The background on this can be found here.

[Problem]

The root cause this time around, is just as obscure but with our background on this problem in 8.1.1.1, the reason why it is broken in 8.1.1.2, is more easily identified.

If you recall from last time, Siebel generated the HTML Tab index in the browser source code, but failed to provide it with an identifier.

In 8.1.1.2, Siebel dosnt generate the tabIndex property or its value at all, so the solution i'm about to provide is a going to be another UI hack.

Although it is not as elegant as the last solution, it has the advantage of being backwards compatible and should be quite future proof.

[Solution]

Since Siebel dosnt generate the HTML Tab index anymore, we need to find a way to make this information available to the browser. To be thorough, you should turn on all the hidden properties in Tools, by setting this option in your tools configuration.

ClientConfigurationMode = All

After that exercise, i've found that only the Height/Width properties work. So we are going to pick one, and for this example i'm going to use the control height property and ask that developers populate that with the desired HTML sequence.

When Siebel renders the controls on this applet, it will be stretched out of proportion, because we used the control height property as our HTML Sequence indicator.

To get around this problem, we will manipulate the DOM on applet load and inject the tabIndex property, with the height value that we have configured above, and at the same time restore the height to the standard 24 pixel, for all the field controls on the applet, before the user has a chance to see it.

Heres how its done, copy the following code and put it into your browser applet load.

fixTabOrder8112(this,"any valid control name");

function fixTabOrder8112(that,ctrlName)
{
try {
var oControl = that.FindActiveXControl(ctrlName);
oControl.document.body.style.display="none";
var oObject = oControl.document.body.getElementsByTagName("object");
for (var i=0; i < oObject.length; i++){
oObject[i].tabIndex = oObject[i]["height"];
oObject[i].height = "24";
}
   oControl.document.body.style.display="block";
} catch(e){
} finally {
}
}

If you look carefully, you'll notice that i hide the entire contents of the applet, ensuring that all the controls are invisible while the code re-draws all the controls, and re-displays the content when the routine is finished.

You may or may not notice a small moment of flicker as the applet is being worked on, but it should be un-noticable. To get a second opinion, I asked a BA to watch it in action and watch out for the flicker, and when it was over, she stated "I didnt see any flicker!" If you are testing this, try it out on both thin and thick client to see the behaviour.

This will work for the majority of cases, but if you have a Popup form applet with varying control heights such as text areas, then you have to work a bit harder to get this solution to work.

The basic idea, is to append the HTML sequence to the end of the height property, split the values to get your separate properties values and use the above method to alter your HTML source.

The original defect was discovered in 8.1.1.1, and i was told a fix was pushed for 8.1.1.2. We have discovered that it is still outstanding, and 8.1.1.2 has also broken our fix for 8.1.1.1, but customers who are still suffering from this defect, now have a new solution.

SHARE