Hi Charles,
Interesting feature! But…
When we allow multiple selections from the listbox, the listbox height will increase, which will increase the height of the whole table header. You can test this by opening the page, edit one of the listboxes and add multiple=”true”. Is this acceptable?
As an alternative, we could change the height of the listbox to something like 30px. But then there is no visual different between single and multiple selection.
Any thoughts…?
Thanks,
Peter
Peter;
I did a quick test and I see your point about the box size. That’s not good so I agree with your idea about one size fits all is good.
But the UI is now a problem as I find when you select one, it fires off a search without pressing enter. Then when you <Ctrl> select another, it fires again and sometimes generates a SQL syntax error. And multiple selecting the implied “All” and a drop down value is illogical.
I think your suggestion is good but it will need some polishing before it’s implemented. I also presume it would be an optional setting.
Then there’s the question of what is displayed in the list box after a multiple selection has been made.
don’t put much effort into this while I think about the side effects.
Thanks, Charles
Hi Charles,
>>> Then when you <Ctrl> select another, it fires again and sometimes generates a SQL syntax error.
You see the error because the back-end currently expect to get one single value only. If you change the listbox to multiple, you need to process the array. That should fix the error.
The on change event on the listbox is the natural way of working with listboxes. If we remove that event, we need to find a way to start a search that works under all condition. That might be a challenge with all the different search options currently supported… 😉
Best regards,
Peter
Peter;
I’ve thought about this and I think it’s best to leave it as it is.
I’m going to explore implementing the requirement by using the Search Builder and a separate “Advanced Search” page.
