'picker.hide()' hides the picker, but does not do everything to
properly keep track of the picker state in the combobox class.
This lead to a bug when we reselected an entry, we had to click the
picker again twice to open it again.
Use the 'collapse' method of the combobox instead, which does the
necessary book-keeping.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
by introducing a errorHeight config property. This is necessary when
the ComboGrid has e.g. a toolbar and we show the error in the grid body
only, 100 pixels is not enough then. To solve that without hardcoding
different heights, let the subclass/caller configure that
also set this when the store load fails completely (was not done until now)
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
for most of the combogrids, this does not make a difference, but we
want to have a node selection in some of their toolbars. There
having the error over the whole grid makes it impossible to select a
different node (which might be necessary to get rid of the error), so
we show the error on the view (which is the grids content body only).
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
firing 'refresh' in 'clearLocalFilter' was wrong, since that triggers
too often, for example when selecting an entry (since the field lost
focus). This lead to the picker refreshing and not registering the
click and thus not selecting the desired entry.
Instead refresh the view when we really need it: when the picker is shown.
The filter is already gone, but the picker grid does not know this yet,
so we fire the event then.
Fixes: 7e47328 ("Combogrid: clear filter on blur")
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Previously, deselecting and reselecting the input field
led to the previous filter still being applied, although the
input field was cleared.
Signed-off-by: Matthias Heiserer <m.heiserer@proxmox.com>
We do not want to trigger an autoSelect if there's a value set, even
if it isn't found in the store, as that hides the fact that an (now)
invalid valid is configured from the user, which can be confusing if
something is not working, as when editing an object it seems like a
valid value is selected.
Further, if a value is set we mark the field as invalid from the
start, at least if it's neither disabled nor allowed to have a
value which is does not exists in the backing store.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
findRecord does not match exactly, but only at the beginning and
case insensitive, by default. Change all calls to be case sensiti
and an exactmatch (we never want the default behaviour afaics).
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
if there occured an error in the api call of the store, show this error
on the picker when opened, instead of just showing an empty picker
this makes it possible to see that there was an error while accessing the api
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
