forceSelection doesn't prevent typing, it just forces the user to type one of the options from the list. Perhaps that's what you meant but I just wanted to make sure we're clear on that.
With your current configuration you're allowing users to type in a totally arbitrary value. If they type in a value that isn't in the list then it won't have an id. I'm curious to know how that would work in the context of your scenario?
Apologies if you already understand this but I just want to make sure we're clear about the queryMode setting.
queryMode refers to where the data is filtered, not where it came from originally. It's difficult to know from what you've said so far whether or not you should be using 'local' or 'remote' but it's a common mistake to use 'remote' simply because the data is being loaded from a server.
You may find these articles helpful. They don't address your case specifically but they do give an overview of some of the main config options, including working with remote data:
Thanks for articles you attached, I'll read them to learn more about config options.
Do you know a good book to study Extjs 4 ?
I found some books by surfing the internet, but they are all about Ext Js 3.
Does an ExtJS book published by O'reilly exist ? Books from O'reilly are always well written.
I know this is an old post, but I had a similar problem with a combo box that was configured correctly submitting the displayfield instead of the valuefield. It also returned the displayfield when directly calling "getValue" on the combo.
In my situation, I found that the original displayField data (text) sometimes contained newline characters ("\r\n"), which once removed, caused the combo to act as intended.
Since I didn't find any other posts referring to this odd behavior, I thought I would do my part and put it out there for others. I assume other control characters (e.g., "\t") might also cause the problem, though I did not delve into the Ext framework to find out the underlying cause.