Hi,
While trying to set more than 3 values in BoxSelect,its not showing anything I am sending you with a simple example.

You're using different delimiters for the items. In the two value example, your delimiter is a comma followed by a space. Your multiple value examples use only a comma. Whatever your delimiter is (you can specify it with the 'delimiter' parameter), you need to match it exactly for your values to work.

1.3 Released

1.3 has been released and the first post has been updated. Please see that post for a more complete list of updates.

My continued thanks go out to the various testing and coding contributions that have been made so far from the community for this extension, and also for the thousands upon thousands of thread views and downloads.

Originally Posted by ngd

Bug 1) I have tried your fix and unfortunately BoxSelect just stops working. I am not even able to select values into it.

My apologies for the problems with the previous release introduced by auto-querying. I have been very busy lately and unfortunately have not been able to get this update out more quickly. Thank you for your understanding and taking the time to file these bug reports. The underlying issue for this has been fixed in 1.3.

Originally Posted by ngd

Bug 2) If I use a remote store, and if I set multiSelect to false, the Name corresponding to the value field does not show up in the box. If I set multiSelect to true, it shows up.

This has been resolved.

Originally Posted by ngd

Bug 3) If I set the value to be a CSV e.g. '123, 456' or if I set it to an array, BoxSelect sends me the inital query infinite times. It just doesn't stop.

This has been resolved and also an example of remote querying has been added to the documentation to make sure this functionality remains tested in the future and to provide a demonstration for those wishing to leverage this functionality.

Originally Posted by notjoshing

I'd get errors when I clicked on a newly rendered BoxSelect without a value. To avoid this, I modified the code around 433:

...

I also noticed that the emptyText value was rendering even when values existed for the drop-downs. I looked into the code and changed the code around line 1030 to prevent this:

I am seeing an issue in 1.3 that was not present in the previous version: When I start typing an entry, as soon as the filtered list of choices appears, the text I've typed gets cleared out of the text box area. It just gets totally blanked out. This pretty much negates the ability to type in a value and hurts my usability quite a bit.

1.3.1 has been released and the first post has been updated. Please see that post for a more complete list of updates.

Originally Posted by charlie17

I am seeing an issue in 1.3 that was not present in the previous version: When I start typing an entry, as soon as the filtered list of choices appears, the text I've typed gets cleared out of the text box area.

This was mistakenly introduced in 1.3.1 and I had overlooked testing the remote store querying. I have modified the server side script included in the remote store example to handle querying, and have fixed the over-zealous clearing of the input field.

Originally Posted by sankarbaluz

Could I understand that how we are giving "displayFieldTpl"?

I have added the capability to customize the label template to 1.3.1. The remote store example now shows how to do this. The "tpl" config property is used by ComboBox to create the picker, and a "labelTpl" config property has been added to BoxSelect 1.3.1 to control the rendering of the labeled items. The defaults for these remain as being built off of the combo's displayField config property.

I'd rather keep the not-type-converting comparison operator and fix the code that puts strings rather than numbers into the array.

I agree with this. However, after looking on implementation of Ext.data.Store.findExact (which is used as an alternative way of getting record in the code of BoxSelect.findRecord) I decided to go for the same way of comparison, to be consistent.

I agree with this. However, after looking on implementation of Ext.data.Store.findExact (which is used as an alternative way of getting record in the code of BoxSelect.findRecord) I decided to go for the same way of comparison, to be consistent.

Further observation on Ext.data.Store.findExact implementation. It had non-type-converting comparison in Ext 4.0.6, and was changed to type-converting comparison in Ext 4.0.7.
My proposal seems to be consistent with Store's findExact behavior in 4.0.7, but not in 4.0.6.