Do you have an example or can you elaborate on the getRawValue and beforeblur issues that you experienced - I actually haven't looked at or thought too much about getRawValue and how it should work - as this component has multiple values it's not quite the same as combo - if you (or anyone) has thoughts or suggestions, I'd appreciate hearing them.

Try using the newest version of Ext 3 from SVN (maybe RC2). I think you will see that the fields go blank on blur. Not such a great user experience!

Anyhow, when content is changed (valid data that is), a hidden field ought to be updated with the value, and getRawValue would just return that.

Try using the newest version of Ext 3 from SVN (maybe RC2). I think you will see that the fields go blank on blur. Not such a great user experience!

Anyhow, when content is changed (valid data that is), a hidden field ought to be updated with the value, and getRawValue would just return that.

Steve, I can't reproduce your blur issue - it's possible there is a bug or regression in the version of Ext 3 you are using - the recent RC 2 release actually fixed a couple of bugs that occured with this component and RC 1.1.

Your description of how you think getRawValue should work is exactly how getValue currently works - valid values are stored, and when getValue is called it returns those values (delimited).

Your suggestion is also different to how ComboBox (well Field actually) works - the getRawValue method returns the current value of the input el whether valid or not.

Obviously the biggest difference between this component and ComboBox is that there are multiple values - the input el is less relevant from a raw value point of view - it will always be different to the underlying value of the component when selection/s have been made which brings me to the dilemma of what getRawValue should return.

If you have use case/s with example data that explains your thoughts better, I'll be more than happy to have a look.

I'm trying to use the SuperSelectBox with Ext 2.2 in a form and this is basically what I'm doing. I'm disabling the form while the data is updating the form then enabling the form. This causes problems with the box.

1. I cannot use Box.addItem() as you can't set the value if the form is disabled. Don't you think there should be an override feature? Or maybe it really shouldn't be checking for disabled. I would assume the only way in setting a value (if the person is the end user) is through some sort of button. I think the button should be checking for a disabled form rather then in the addItem function....just my thoughts.

@radtad - some good suggestions thanks - I'll consider adding them. I'm not sure I see the use case for mid-word pattern matching (if I understand you correctly), but I like the others.

Let's see if I can give you an example:

I have a name "Chris" I'm trying to find because that's what he told me his name is. But his first name is actually "John" and his middle name is "Chris". So the display field would normally be {First Name} {Middle Name} {Last Name} i.e. "John Chris Doe". With no mid-word pattern matching available, if I didn't know Chris' real name was John, I'd never get his name as a return match.

A big use case for our company comes down to email addresses. Currently I have "Tad Johnston (rad)" as the display field, "rad" being the email address. A lot of people here often times do not know the person's actual name, but they always know their email address because it's something they see often. Now, if I don't have mid-word pattern matching I can never find "rad".

Another suggestion which would be even better would be matching on more then just the displayField, possibly in the store. Then I wouldn't have to worry about mid word pattern matching whatsoever.

I'm trying to use the SuperSelectBox with Ext 2.2 in a form and this is basically what I'm doing. I'm disabling the form while the data is updating the form then enabling the form. This causes problems with the box.

1. I cannot use Box.addItem() as you can't set the value if the form is disabled. Don't you think there should be an override feature? Or maybe it really shouldn't be checking for disabled. I would assume the only way in setting a value (if the person is the end user) is through some sort of button. I think the button should be checking for a disabled form rather then in the addItem function....just my thoughts.

Maybe I shouldn't check for the disabled state when programatically interacting with the component - I'll have a look at the other Ext form controls and follow suit.

I have a name "Chris" I'm trying to find because that's what he told me his name is. But his first name is actually "John" and his middle name is "Chris". So the display field would normally be {First Name} {Middle Name} {Last Name} i.e. "John Chris Doe". With no mid-word pattern matching available, if I didn't know Chris' real name was John, I'd never get his name as a return match.

A big use case for our company comes down to email addresses. Currently I have "Tad Johnston (rad)" as the display field, "rad" being the email address. A lot of people here often times do not know the person's actual name, but they always know their email address because it's something they see often. Now, if I don't have mid-word pattern matching I can never find "rad".

Another suggestion which would be even better would be matching on more then just the displayField, possibly in the store. Then I wouldn't have to worry about mid word pattern matching whatsoever.

Hope this makes sense....

Thanks, It makes sense - I think matching against all store fields would be the best way - I'll see what the effort would be and add it to the list of nice to have's.