Hiding controls in query mode
Jun/094
This issue came up during a UAT phase when testers reported to see two buttons twice when they wanted to query. After investigating this issue, I found out that some controls stayed on the appled even when the applet was in Query Mode.
Problem:
This issue only occurs with controls that invoke a custom method.
Normally when you query in Siebel, you only see the Go, Cancel and Query Assistant buttons but for some reason, buttons that invoke a custom method are also showing on the applet after pressing Query.
In our case this was causing confusion since our custom buttons had the same caption.
Solution:
First I tried to find a solution on Metalink, but there I found the suggestion to use BrowserScripting to hide the buttons but that is like fighting fire with fire.
Then, I’ve noticed that the buttons are not showing in the Query Mode if they are disabled before you press the query button. So the solution is very simple. Set the CanInvoke for the method behind the button to false and the button will not show when you do a query.
To do so, start by setting a Profile Attribute to true on the WebApplet_PreInvokeMethode for the NewQuery method. This Profile Attribute has to be set back to false of course to avoid that you’re button stays disabled. The best place to do this is on the PreInvoke of the methods ExecuteQuery and CancelQuery.
function WebApplet_PreInvokeMethod (MethodName)
{
switch(MethodName){
case “NewQuery”:
TheApplication().SetProfileAttr(“QueryMode”, “TRUE”);
return (ContinueOperation);
break;
case “ExecuteQuery”:
case “CancelQuery”:
TheApplication().SetProfileAttr(“QueryModeBPG”, “FALSE”);
return (ContinueOperation);
break;
}
return (ContinueOperation);
}
Next, you test for this Profile Attribute in the WebApplet_PreCanInvokeMethod to set the CanInvoke for the method to true or false.
If the Profile Attribute is true the Query button is pressed and the button should become disabled so it’s not displayed on the applet. When the query is executed or cancelled, the Profile Attribute is false and the button can become enabled again if other conditions are met.
case ‘StartActivity’:
if( … ){
CanInvoke = ‘FALSE’;
}
else{
if(TheApplication().GetProfileAttr(“QueryMode”) == “TRUE”){
CanInvoke = “FALSE”;
return (CancelOperation);
}
else{
CanInvoke = ‘TRUE’;
return (CancelOperation);
}
}
break;
When you now query, you see that the buttons are no longer displayed.
After running or canceling the query, the buttons are displayed again and will be enabled if they have to be.
Release/Unrelease SmartScripts in batch
Jun/090
In the most recent release on the project I’m currently working on, the customer wanted to work with SmartScripts. Very soon we had over 40 SmartScripts.
The problem with SmartScripts however is that they all need to be released whenever they are created. And since the customer is working with 3 different languages, this means a lot of manual labour.
Therefore, I’ve come up with a simple but clever solution. I’ve added to extra buttons on the top applet called Unrelease All and Release All.

To (un)release all SmartScripts at once, the user simply has to query in the bottom applet for the correct language and click on the Unrelease All or Release all button. The script behind the buttons then performs the action for all SmartScripts for the specified language.
In the customer’s case, you have to perform this action 3 times (for languages ENU, NLD and FRA) in stead of around 100 times for each SmartScript individually.
Debugging in another language
Sep/083
Today we were facing an issue in the French and Dutch version of our application. Strangely enough, the issue was not occurring in the English application.
Since I thought it was related to eScript, I wanted to debug the code.
So I opened the Options windows and entered the path to the config file for the Dutch application. For some reason, the application was using the srf file in the ENU folder in stead of the NLD folder.
At first I thought something was wrong with the config file but it seemed ok. Then I checked the options for debugging again but they were all filled in correctly.
Being confused about it, I asked a colleague for help and he found on Supportweb Metalink that I had to pass the parameter for the language in the argument field. Adding /L NLD finally fixed the issue and I could start debugging our Dutch application


