Posts filed under 'Scripting'
Top tip today from Neel over at Siebel Unleashed: using the IE address bar to enter browser script.
I’ve never thought of this, and the key point is worth repeating: script entered into the address bar after a javascript tag is executed by the browser, in exactly the same way as browser script. This means that if you edit the address to be:
javascript:alert(theApplication().GetProfileAttr("Me.First Name"));
…then the browser will popup a message box with the value of the First Name attribute - exactly as you’d expect if this statement was in browser script. Much faster than navigating to Administration - Personalization > Test, plus it retains current context.
Nice quick-and-dirty hack to check (or set) the value of browser objects. Good work, Neel!
May 20th, 2008
A question on the Oracle discussion forum last week prompted me to dig out a MetaLink article that I’ve never noted here. The question was “How to call a local executable from the browser”: the answer is to use browser script to instantiate a Windows Scripting Host ‘Shell’ ActiveX object, like so:
var objWSH = new ActiveXObject("WScript.Shell");
objWSH.Run("notepad.exe");
More detail on using the ActiveXObject is available in the post on Client-side DLLS.
May 5th, 2008
I had a problem the other day where I needed to share a value between two applets. On a form applet there’s a browser script method that executes on the WriteRecord event, but it’s designed to only fire if certain other events have already run. To control the ’state’ (execute or not), there’s a boolean variable declared in the general declarations of the browser script. This form is used in a number of different views and works as designed.
The challenge was in the screen’s List view: here we have the form applet, which works as elsewhere, but also a list applet for the same business component. The behaviour should be the same for both applets. Easy enough, I figured: just copy the form’s browser script across to the list. And this approach appeared to work well enough.
An alert tester picked up the gap: if the operation was started in the list applet, but then completed in the form applet (or vice-versa), then the browser script wasn’t executing. In the first applet the state variable was set, but in the second applet not. What I needed was for the state to be shared across the two applets.
The usual way to share variables across objects is to use Profile Attributes or Global Variables, but neither solution was an option. Global variables simply aren’t available through browser scripts, while the getting and setting of profile attributes requires a round-trip to the server - too much of an overhead in this case. I thought I was going to have to resort to some sort of hidden control and FindApplet then FindControl methods, but the solution was much simpler.
Turns out that variables declared in the general declarations section of Browser Script are shared for all the applets in the view. Who knew? (See the note about halfway down.) Okay, quite possibly everyone except me, but now I won’t forget.
For my little problem, I was able to prescribe that this list applet be only used alongside the form applet, which meant that in the list’s browser script I could simply set and get state using the form’s variable. The applets now share state and everything works as expected.
March 27th, 2008
A great update on the Script Assist functionality I mentioned a while back. In a comment on my original post, Jake pointed out a “*huge* performance impact when the method listing and autocomplete options were enabled on scripted BCs in v8″.
Now, an anonymous commenter posts that this problem has been recently fixed and “should be available as a QF and in the FixPacks”. The comment also highlights some of the additional scripting improvements in 8.0 that I hadn’t come across - including “Fix & Go” debugging, Siebel’s version of Visual Studio’s “Edit & Continue” - and signposts an “upcoming 8.1 feature, Script Performance Profiler”.
I’m very (inordinately?) pleased with the additional information. Partly because the improvements are all good, legitimate changes that drag Siebel Tools towards with other fully featured development environments, but moreso because it’s great to see an employee of Oracle monitoring and feeding back directly into the development community. This is exactly the sort of thing I was hoping to see when I started the blog… may a thousand geeky conversations bloom 
October 29th, 2007
The browser script Control method ‘SetProperty’ is fairly limited: it only works at all with CheckBox, ComboBox, TextBox and TextAreas, and even with these controls I’ve found behaviour to be flaky. In my experience it’s more reliable to grab a handle to the control and access the DOM properties directly.
For instance, to conditionally show or hide a control using browser script, the code looks like this:
var ctrl = thisApplet.FindActiveXControl("My Control");
if( ctrl != null )
{
if( myFlag )
ctrl.style.visibility="visible";// show control
else
ctrl.style.visibility="hidden";// hide control
}
This approach can also be used to set other display properties - like the font and colors - but you have to be a bit more careful with interactive properties: the standard HTML property disabled does not work the same as Siebel’s Enabled control property, for instance.
The best reference I’ve found to the complete set of DOM properties is on MSDN, with the advantage that everything here should be available to Siebel’s IE-only environment.
July 30th, 2007
Previous Posts