Wt

Hey Marios,

(In reaction to your private email), I now see that I interpreted your question wrongly. You diagnosis of the situation is correct:

Here is an example:

WLineEdit* le = new WLineEdit();
le->setTextSize(80);
le->setFocus();

m_pSP = new
WSuggestionPopup(WSuggestionPopup::generateMatcherJS(contactOptions),
               WSuggestionPopup::generateReplacerJS(contactOptions), this);

m_pSP->filterModel().connect(this, &Webphone::filter);
m_pSP->activated().connect(this, &Webphone::select);
m_pSP->forEdit(le);

...

m_pSP->addSuggestion("text", "value");

...

void Webphone::select(...)
{
       // "sug" attribute here is equal to "text" and not "value"
       // this is counter-intuitive.
       // The reason: the default WSuggestionPopup model is an instance of
WStringListModel, which does not implement DisplayRole and UserRole.
}

The problem is not in WSuggestionPopup.C. The problem is in

WStringListModel.C. WStringListModel does not "honor" the DisplayRole

and UserRole properties. If I use setModel to set the WSuggestionPopup

model to, let's say, a WStandardItemModel, then UserRole will work as

expected. But, from a user stand point I would expect the UserRole

functionality (implicitly invoked by a call to "addSuggestion" that

requests for text and value parameters) to work out of the box. Now it

does not. I pass a different text and value string to addSuggestion, and

I get back a "sug" value equal to the text suggestion. The value

suggestion is completely lost.

After looking into the WStringListModel code, I am not sure if the right

thing to do is to extend WStringListModel to use the UserRole property,

or to simply change the default model of WSuggestionPopup to be a

WStandardItemModel instead (I chose this solution for now), or to simple

document this fact and leave things as is, then let the user can change

the default model if they need to use the "sug" value.

I would prefer the improve-the-documentation approach. WStringListModel should be kept simple !

Since you are looking into this, another suggestion is to allow the

users to customize the suggestionClicked and refilter javascript

functions of WSuggestionPopup.js the same way that the user can

customize the matcher and replacer functions. For example, in my

application I search by edit distance and the contents of the popup keep

changing as the user is typing letters. The suggestions are not fixed. I

wanted to refilter anytime a letter was clicked, irrespective of the

filter length. I wanted refilter to keep being called. I was not able to

do that (without changing WSuggestionPopup.min.gs to fit my needs...)

Anyway, just a thought :)

Can this not be done with an insanely long filter length ?

Regards,

koen