focus yourself glad to have found a quick solution for a possibly common requirement. Users are trained to use the Account name field in the opportunity list to search for opportunities. However, when they use ALT+Q to enter query mode, the first column in the list has the focus, so they have to tab to the Account column. They want to have the cursor in the Account column once they enter query mode, irrespective of the placement of the column. Here is a simple way to implement this. It introduces the DefaultFocus Applet User Property, which, if memory serves me correctly, has been introduced in Siebel 7.8. First we add a new Applet User Prop to the Opportunity List Applet. We use DefaultFocus_Query = Account to define the default focus column for the Query Mode. Note that you can use DefaultFocus_Edit for Base, Edit and EditList mode and DefaultFocus_New for the New mode. After compiling the .srf file, we can run a test.... And voilá, click Query and you find the focus on the Account column. So you can speed up your work by simply entering the search string and hitting the ENTER key. There also was another requirement to have the focus on the Query button. However, using DefaultFocus_Edit = NewQuery did not yield the desired result. The funny thing was that the Query button only got focus after pressing ALT+ENTER (or invoking the ExecuteQuery command). Maybe the answer to that problem is somewhere out there......
once and for all Hierarchical picklists in Siebel CRM... It's a long story. There are numerous approaches (even in the standard repository) and myths out there how to implement them. A hierarchical picklist is one that allows a user to pick a value for the first field and then shows only values for the second field that are dependent on the first one and so on. Here is a cookbook style example (tested on Siebel Industry Applications 8.1) how to implement a hierarchical picklist with indefinite levels: 1. Create the list of values data Use the Siebel Web Client to enter the data for the picklist. You should use the same TYPE and distinguish the levels using the Parent field. Note that the first level does not have a parent 2. Create the business component fields Create one field for each level. For all levels but the lowest set the property Immediate Post Changes to true (for resetting the lower fields when changing the value in the applet). 3. Create picklist objects Use the Picklist wizard to create a static bounded picklist object for the new fields. Create separate picklist objects for the first level and all subsequent levels (you will use 2 different picklist objects). When the wizard is finished, navigate to the picklists and make the following changes manually: For the first level picklist, change the Business Component property to PickList Hierarchical and set the Search Specification property to [Parent Id] IS NULL. For the second (and subsequent) level picklist, change the Business Component Property to PickList Hierarchical. PickList Hierarchical is a standard BC used for example in the BC Service Request to implement the Product, Area and Sub-Area hierarchy. 4. Edit pick maps Navigate to the Pick Map specifications for the new fields and set the following: For the first level field add pick map records for all dependent fields and enter Dummy as the picklist field. Dummy is a calculated field (evaluating to an empty string) in the PickList Hierarchical BC. For the subsequent fields add the Dummy mapping for all remaining dependent fields and add an additional record for the upper level field where you set the Picklist Field to Value and the Constrain flag to true. Do not add a dummy mapping for the last field in the hierarchy. The screenshot should give you the general idea: 5. Expose the new fields as controls/list columns in an applet Do the UI work as usual and test. The dropdown for field 1 should only display the highest level values and lower level fields should be constrained to the child values of the higher level field value. When changing an upper level field, the lower level fields should be reset to empty strings. Users should not be able to select values in "wrong order". have a nice day @lex...
It has been a view years or Siebel versions that a nice little feature named "Rapid Unit Test" has been introduced. If memory serves me correctly it was 7.5.3.2xx. The feature allows you to start a compile in Siebel Tools while the Developer Web Client (siebel.exe) is still running. The effect is such that the browser closes and siebel.exe releases the srf. When the compile process completes, siebel.exe starts up again from its suspended mode (gray icon in the system tray becomes colorful again) and the browser launches AND navigates to the previously opened view. So developers can continue testing without having to shut down the Siebel client and restart it, hence "Rapid Unit Test". So far so good. Then - out of a sudden in version 7.8 - a bug prevented this feature to work. Most of us are familiar with the gruesome error message of wrong username and password. I am not sure if the bug has been fixed in the latest patch release, but there is a generation of developers who either do not know about that feature or have a version running which contains the bug. I have developed a workaround (it is nothing more) which goes as follows (the following being a script you can run on your windows workstation after applying the correct installation folders): rem rename sscfsaodbc.dll to sscfsaodbc.dll.orig ren %SIEBEL_INSTALL_DIR%\client\bin\sscfsaodbc.dll sscfsaodbc.dll.orig rem make a backup copy of sscfsadb.dll to sscfsadb.dll.backup copy %SIEBEL_INSTALL_DIR%\client\bin\sscfsadb.dll %SIEBEL_INSTALL_DIR%\client\bin\sscfsadb.dll.backup rem rename sscfsadb.dll to sscfsaodbc.dll ren %SIEBEL_INSTALL_DIR%\client\bin\sscfsadb.dll sscfsaodbc.dll Basically, we have to swap the database connectivity dll files. All I can say is that it works for me, you have to try it for yourselves and of course download and install the latest patch. have a nice day @lex...
gotcha! Whenever you wish to use an external script such as browser script (which IS external because it runs in the browser) to call a method of a Siebel Business Service, you have to declare this Business Service so that the application accepts the call. This is a security feature which has been introduced in Siebel 7.5. Because otherwise any script kiddie could inject javascript code into the Siebel Web Client, call any Business Service and wreak havoc. Most of you are familiar with the odd entries in the applications .cfg file ClientBusinessServiceN = Name of the Business Service (where N is a sequential number) However, during some upgrades to Siebel 8, things went bump in the night.That is, their browser scripts didn't work anymore, and adding the line to the .cfg file didn't help either. Here is the solution, and it is in fact related to the year-long effort to get away from text files to configure server components. So since Siebel 8 you have to declare the Business Services which you would like to call from external scripts as an Application User Property. Migration is rather easy, because they have the same syntax as in the .cfg file. As you can see in the screenshot below, also PDQDisabledViewN made it into the Application User Props....
If you use an RSS reader, you can subscribe to a feed of all future entries tagged 'Siebel Tools'.