Here's an ugly workaround I did on my CustomComboBox
ComboBox
{
...
// Ugly workaround model change reset current index selection
property int __lastValidIndex: 0
onCurrentIndexChanged:
{
if(model.length > 0 && currentIndex > 0 && currentIndex != __lastValidIndex)
__lastValidIndex = currentIndex;
}
onModelChanged:
{
if(model.length > 0 && __lastValidIndex > 0 && currentIndex !=
__lastValidIndex)
currentIndex = __lastValidIndex;
}
}
It's still oscillating between the index 0 and the real value on model
change, but at least I end up with the proper value in the end. Still a
problem performance wise if that combo box entry control some workflow or
some options of the workflow.
On Wed, Dec 10, 2014 at 11:11 AM, Jérôme Godbout <jer...@bodycad.com> wrote:
> Hi,
> I'm having some problem with i18n along with the ComboBox controls. Here's
> something I'm doing with it:
>
> ComboBox
> {
> model: [ qsTr("Choice A") + I18n.revaluate,
> qsTr("Choice B") + I18n.revaluate ]
> currentIndex: 1
> }
>
> I used the i18n revaluation on a singleton to select current application
> language (would do the same without it, if we change the model from a
> function).
>
> When the language changed, here's what happen:
>
> 1. The list get it's values changed by changed on I18n (trigger
> I18n.revaluateChanged())
> 2. The combo box model changed.
> 3. the model look like a QQmlPropertyList, since it clear it and
> repopulate it after
> 4. The model get clear, the current index goes back to 0
> 5. The new values are displayed but the current selection on all combo
> box are reverted to the first entry.
>
> I stated before, this also happen when assigning the model from a function.
> Is there a way to prevent this or to hook ourself to keep the previous
> value? I cannot used on modelChanged, since it would already imply the
> value have changed (and cannot make sure the currentIndex is already
> changed, since it's also done on the same signal).
>
> The clear and assign of QQmlListProperty give us many problems everywhere
> (performance wise with long list and things like this). I would love to see
> a full copy assignation operator (along the append, clear, at, count). That
> would be way faster and prevent problems like this, since the current index
> would still be valid on changed. Suggestion out maybe use a QVariantList
> instead for the model? not sure what it would imply underneath.
>
> Thanks,
> Jerome
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
