[tmcneillParticipant]

Regardless of how the search filtering is done, the main point of making this post is to point out the bug with the ‘val’ method of jqxComboBox. You did not acknowledge this bug at all in your reply. Specifically, when calling .jqxComboBox(‘val’, str) where str is a property of Array.prototype, no value is set.

So while it’s possible that using a data adapter would obviate the need to use the ‘val’ method, as I mentioned, I’ve already found a workaround for this bug for now. I’m not asking for a workaround. I’m asking for the bug to be fixed so the ‘val’ method functions correctly.

[tmcneillParticipant]

After a little more investigation, I’ve found the same problem also sometimes occurs with the jqxDropDownList and jqxComboBox widgets. It’s just less noticeable. There are probably other affected widgets as well.

[tmcneillParticipant]

Thank you for your reply. However some of the reply doesn’t make much sense, like this:

“If you would like could try to use Input with change the source but I cannot warrant to get better solution.”

Regardless, After fiddling around with things for a few more hours, I found a solution. I’ll put it here in case anyone else is trying to do the same thing.

The new code looks something like this:
<div id='widget'></div>

var widget = $('#widget');
widget.jqxComboBox({
  minLength: 1,
  remoteAutoComplete: true,
  source: [],
  search: function(query){ // This function gets called after a short delay each time the search string changes and is longer than the minLength property.
    $.ajax({
      url: *web_service_url*,
      method: 'POST',
      data: {query: query},
      dataType: 'json',
      beforeSend: function(xhr){
        xhr.setRequestHeader(*header_for_authentication_token*, *header_value*);
      },
      success: function(data){
        var items = [];
        for (var i in data){
          items.push({
            label: *label*,
            value: *value*
            *other_properties*: *other_data*,
          });
        }

        // Preserve the search string. (Not necessary, but it gets wiped out when updating the source.)
        var search_string = widget.jqxComboBox('searchString') // Undocumented function that I found by chance in one of the jsfiddle demos.

        // Update the source.
        widget.jqxComboBox('source', items);

        // Restore the search string.
        widget.jqxComboBox('val', search_string);
      }
  },
  *other properties*
});

I’m now able to also use the renderer property to custom render the list items. It looks something like this:

renderer: function(index, label, value){
  var item_data = field_widget.jqxComboBox('getItem', index).originalItem; // This is the object that was created in the items array above.
  var display = '';
  display += *html and stuff from item data*;
  return display
},

No data adapter needed.

[tmcneillParticipant]

That seems a lot like a “it’s-not-a-bug-it’s-a-feature” explanation. Arbitrary style rules are now off-limits? Is this documented anywhere?

The problem isn’t even with the CSS though. Setting both width and box-sizing in CSS works just fine. The problem is that under certain circumstances, the width property set on the widget is translated incorrectly and unintuitively to CSS.

I mean, no reasonable person would assume that by setting width: '100%' when initializing the widget and setting box-sizing: border-box; border-width: 2px; padding: 4px; in the stylesheet, the resulting width would be 112%. Intuitively, the width would be 100%, because that’s what was specified. Or at the very least, it should convert pixel to width values. But the current behavior of adding values together and ignoring units makes absolutely no sense. And the fact that margin size, while affecting the overall box size, aren’t compensated for while padding and border size are is just confusing.

I’d be fine with a response along the lines of, “Hrm, this is odd behavior. We’ll look into fixing it. But for now, here’s a workaround.” Or maybe, “Yes, that’s unintuitive, but it’s not going to change. That behavior is documented [here].” But I have a hard time swallowing an answer that is basically brushing off a problem as obvious as directly adding two values with different units. You can’t add pixel values to pecentage values to em values without converting their units first. That’s what the problem is here.

[tmcneillParticipant]

I have found the intended behavior of the dropdownlist widget to be inconsistent with the jQuery API.

From the :

Setting values using this method (or using the native value property) does not cause the dispatch of the change event. For this reason, the relevant event handlers will not be executed. If you want to execute them, you should call .trigger( “change” ) after setting the value.

Example:

<input type='text' name='input1' id='input1'>
<div name='input2' id='input2'></div>
<input type='text' name='input3', id='input3'>
<select name='input4' id='input4'>
    <option value='apple'>apple</option>
    <option value='banana'>banana</option>
    <option value='coconut'>coconut</option>
</select>

$('#input1').jqxInput();
$('#input2').jqxDropDownList({source: ['apple', 'banana', 'coconut']});

$('#input1').val('new value');
$('#input2').val('banana');
$('#input3').val('new value');
$('#input4').val('banana');

In the above example, the change event will be triggered by calling val() on input1 and input2. The change event will not be triggered when calling val() on input3 and input4. This breaks the jQuery API.

I can understand the change event being fired on something like this:
$('#input1').jqxInput('val', 'new_value');
It’s part of the jQWidgets library, so it can behave however it likes. But changing the behavior of the jQuery val() function is quite poor form. Especially since this particular change seems to not be documented anywhere except this thread.

[Author]

Posts