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!

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.

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.

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

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.

• Runtime Applet.PreInvokeMethod
• Browser Applet_PreInvokeMethod
• Server WebApplet_PreInvokeMethod
• Runtime BusComp.PreInvokeMethod
• Server BusComp_PreInvokeMethod
• Runtime BusComp.InvokeMethod
• Server BusComp_InvokeMethod
• Runtime Applet.InvokeMethod
• Server WebApplet_InvokeMethod
• Browser Applet_InvokeMethod

Essentially, the Runtime Event occurs before the equivalent server script event for the same object, plus the Applet browser script events ‘wrap’ all server side events.All of which makes perfect logical sense, but it’s sometimes handy to see it written down in a list.

More importantly for the day-to-day life of a hard-coding Siebel developer, the new engine (finally!) offers method listing (known elsewhere as ‘typedown’). This is the feature common to all modern IDEs that pops up a list of child methods of a known-type object, so that the poor developer doesn’t have to remember the precise format of ‘PropertySet.InsertChildAt’. One of those little modern innovations that lets developers get on with concentrating on the flow of their script, rather than the irrelevancies of syntax. Now, Siebel’s implementation is hardly Visual Studio IntelliSense, but it’s useful nonetheless.

To switch on method listing, go to View > Options in Tools, then the Scripting tab, and tick the ‘Enable Method Listing’ checkbox: the associated IDE-improvements ‘Enable Auto Complete’, ‘Enable Warnings’ and ‘Deduce Types’ are also worth having. If you can set all these flags then you’re good to go.

If these settings are all disabled, then you’re not using ST eScript engine. This is an enterprise-wide setting that you might have to sell. Details of the whys and hows are on SupportWeb. In brief: for 7.8 & 8, set the System Preference ‘Enable ST Script Engine’ to TRUE, for 7.7.2.4, change your cfg file to set EnableCLIScripting to TRUE.

Quick answer: use the JavaScript history object.

In Siebel 6 there was the ‘GoBack’ method, but that never made the journey across the thin client chasm. I’ve come across a couple of different methods for Siebel 7, but the history object is by far the most robust and reliable. It’s browser script only, because you’re accessing the native JavaScript object, but that drawback is far outweighed by its simplicity.

To navigate back one step in the history, the code might be:

function Applet_PreInvokeMethod (name, inputPropSet)
{

if( “GoBack” == name )
{

history.go(-1);
return (”CancelOperation”);

}
return (”ContinueOperation”);

}

What we have in the browser is JScript’s ActiveXObject function, which creates an instance of an ActiveX component. For instance, to get the installed version of Microsoft Word, we do:

var wdApp = new ActiveXObject("Word.Application");
alert(wdApp.Version);

No problemo. (Although note that for the function to work, the ActiveX component must be successfully registered).

The big limitation of this function is in the name: it will only talk to OLE Automation (i.e. ActiveX/COM) components. If your client-side object is an old C library then you’ll have no luck. There is a solution, however: open up any installation of Visual Studio (or similar) and whip up a COM wrapper for your old school object. Performance will take a hit, but it saves rewriting applications from scratch.

Siebel’s explanation of ActiveXObject is buried in the upgrade guide – and is missing from some versions of Bookshelf. Find it here. They’ve also got a good technote on creating a COM wrapper, but note that they’re linking the DLL from eScript using COMCreateObject: for browser script use ActiveXObject as above.

The first complication was that the client didn’t want the dashboard visible by default – I needed to have it open up and populate on demand. That turned out to be also not too tricky: there’s an ‘OpenDashboard’ method on the same Persistent Customer Dashboard business service that does exactly what is says on the tin. [Note: 'OpenDashboard' (no space) and 'Update Dashboard' (with space). Intuitive, non?]

The tricky thing was that we needed to open the dashboard, update the dashboard details and update the source applet – all from a single button click. Problem: the dashboard and the source applet are in different frames, and only one frame can be updated from one UI event. So if I updated the Dashboard, the update to the source applet didn’t happen. And if I updated the source applet…

The solution was to create a second button on the applet to trigger dashboard update in a server script. Add in a browser script to handle the method for the first button, opening up the dashboard from there – and allowing the source applet updates to happen – before using FindActiveXControl to programmatically ‘click’ the second button – giving us a second UI event and the opportunity to populate the dashboard.

Code below…

Server script ‘Update Dashboard’

// Populate the persistent customer dashboard
var bsDashboard;
var psInputs;
var psOutputs;
var AccountId;

bsDashboard = TheApplication().GetService("Persistent Customer Dashboard");

psInputs = TheApplication().NewPropertySet();
psOutputs = TheApplication().NewPropertySet();

AccountId = this.BusComp().GetFieldValue("Account Id");

if( AccountId != "" )
{
psInputs.SetProperty("Source Name","Base View");
psInputs.SetProperty("Buscomp Name", "Account");
psInputs.SetProperty("RowId", AccountId);
bsDashboard.InvokeMethod("Update Dashboard", psInputs, psOutputs);
}

Browser script ‘Select Customer’

// Open up the Persistent Customer Dashboard
var svc = theApplication().GetService('Persistent Customer Dashboard');
var inputs = theApplication().NewPropertySet();
var outputs =theApplication().NewPropertySet();
outputs = svc.InvokeMethod('OpenDashboard', inputs);

// Click the custom 'To Dashboard' button
var obj = this.FindActiveXControl("UpdateDashboard");
// obj.all[0].all[0] locates the Anchor tag.
obj.all[0].all[0].click();