Archiwa tagu: Javascript

SharePoint 2013 Search CSOM default row limit

Could be an interesting hint for those using CSOM search API: why are some of the results not returned?

Is it trim duplicates setting? No.
Is it some wildcard settings of the result source? No.

If you do not set the row limit of the query, you will get by default only 50 items. However, you can increase it like that:

[javascript]
var query = new Microsoft.SharePoint.Client.Search.Query.KeywordQuery(searchContext);
query.set_queryText(‚*’);
query.set_trimDuplicates(false);
query.set_rowLimit(500);
[/javascript]

Last line does the trick. Please note that – by default – 500 is the maximum value.

If you need to increase it, you can do it e.g. via Powershell for the entire search service application:

[powershell]
PS> $mySearchServiceApp = Get-SPEnterpriseSearchServiceApplication
PS> $mySearchServiceApp.MaxRowLimit = 2000
PS> $mySearchServiceApp.Update()
PS> iisreset
[/powershell]

Hope it helps,
Lukasz

“Please wait while scripts are loaded…”

Hello again,

Some of Sharepoint developers might be familiar with this kind of message. It appears in the status bar of Internet Explorer when some action is executed. If the message disappears, fine, but what if it remains there and the desired behavior isn’t executed?

There are a couple of blog entries over the net that describe possible reasons for this issue. What actually causes this behavior are either errors in a masterpage (wrong or missing ID’s of elements that are later referenced), or defective javascript. Well, to be clearer, defective javascript from Internet Explorer’s point of view. And it may take w while to debug and find out at which point the javascript is failing.

I was getting this “Please wait while scripts are loaded” message on a web part page with one particular web part, which had some custom verbs defined. Web part verbs are kind of menu items for a web part, that allow to perform some actions on it. For each verb, one can define server-side and client side action to be performed when the verb / menu item is clicked. And this client side code of the verb was the crux of the matter.

The idea was simple: to open a window via javascript. For the window.open() method two arguments were used, the URL and the name of the new window. The client side code was generated dynamically and the window’s name was put up together, amongst others, from personalizable properties of the web part. Everything worked fine until the property used as part of window’s name contained a hyphen (-). Then, after clicking on web part menu, the message described above appeared, and nothing happened, new window hasn’t been opened.

I replaced the string with an underscore and the problem was solved. At this time I thought that maybe the names or ID’s in aren’t allowed to contain characters like hyphen. But no, according to W3C, hyphens are allowed since they’re not the first character of ID or name. Probably Internet Explorer tries to evaluate the expression, treating the hyphen as a minus sign. And reaches a deadlock at some point (please wait while scripts are loaded…)

Hope this helps,
Lukasz

Single element array initialization with an integer value (javascript)

When initializing a javascript array (with a known number of its elements), one does normally write a simple line of code:

var myArray = new Array("string1", "string2", 123);

This works fine when we have more than one element of the array. However, when we want to declare an array with one element, and the element is of an integer type, we could encounter an odd behavior. The reason behind is that a following command:

var mySecondArray = new Array(12);

…initializes an array with twelve elements, which aren’t filled at this time. And not, as expected, a single-element one. So, in order to declare a single-element array with an integer value, let’s consider a following “workaround”:

var myThirdArray = new Array(1);
myThirdArray[0] = 12;

Declaring an array with a length of 1 element, then assigning the value of the element by finding it by its index should solve the problem.

Best regards,

lukasz

Maintain selected tab position upon postback (jQuery UI Tabs)

Hello,

jQuery UI is a very nice add-on to the standard jQuery library. It provides us with out-of-the-box interactions and client side effects for a rich web application experience. One of the interesting effects are the jQuery tabs. They’re used to split the content into sections and be able to switch between them without having a postback, and also to spare some space within our web page.

The interaction is purely on the client side, so after reloading the page the tab which we selected as last isn’t maintained. What if we have, for example, a file upload control within one of our tab sections? After uploading a file (postback), we lose the focus on the tab in which we were previously.

But the developers of jQuery UI provide us with a couple of methods and events, which we can use to do some kind of workaround for this issue.

We need to have a document element which could store the selected tab index. We can use an input hidden field, value of which would be posted together with other data during page postback. So, let’s put it into our page, setting it’s value declaratively to 0 (the index of the first tab – default selection):

<input type="hidden" value="0" id="theHiddenTabIndex" />

Having the ID of the element, we can set its value from the client side script. Using the show event of the jQuery Tabs (fired when the tab is changed), we can do this at runtime:

$('#tabElmtId').tabs( {
  show: function() {
    var newIdx = $('#tabElmtId').tabs('option','selected');
    $('#theHiddenTabIndex').val(newIdx);
  }
 });

As you can see, when the event is triggered, the currently selected index of our tabs is being stored in a variable (line 3), then assigned as a value of the hidden input field. Now the postback can be performed but the next question is how to tell the tabs control to start from another tab index than the default 0.

First, on the server side, we can use the language which we prefer in order to fetch the value of the submitted hidden input field. For example, in ASP.net, it could look like this:

String hiddenFieldValue = Request.Form["theHiddenTabIndex"] ?? "0";

Now we can put javascript into our page’s source in order to tell have this variable also available for client side scripts:

   1: StringBuilder js = new StringBuilder();
   2: js.Append("<script type='text/javascript'>");
   3: js.Append("var previouslySelectedTab = ");
   4: js.Append(hiddenFieldValue);
   5: js.Append(";</script>");
   6: this.Header.Controls.Add(new LiteralControl(js.ToString()));

The one thing important about this is that it should be injected before the jQuery Tabs are initialised. Now the remaining task is to tell jQuery to use the javascript variable in order to set the selected tab upon loading the controls after postback. We can use the selected option of jQuery UI Tabs in order to assign this value:

   1: $('#tabElmtId').tabs( {
   2:     show: function() {
   3:         var newIdx = $('#tabElmtId').tabs('option','selected');
   4:         $('#theHiddenTabIndex').val(newIdx);
   5:     },
   6:     selected: previouslySelectedTab
   7: });

The only thing that changed from the previous Tabs initialisation is the line 6, where we assign the javascript variable to the selected option.
Now the tabs position should be postback-proof.

Happy jQuerying!