10-23-2012 11:43 AM
Hi, I have a question about slider.
My slider is a qml object that I want to drive programmatically from my C++ application. I've no problem with that, and everything is working here.
My problem is that when my app is calling mSlider->setValue(newpos), the qml send a message onValueChanged and a onImmediateValueChange. As my app is using these message too, I'm stuck in a loop.
I tried to raise a flag before calling the setValue, but when I get the onValueChange message, this flag has already been reset to false.
Any idea how I can manage this?
Solved! Go to Solution.
10-23-2012 12:20 PM
I don't understand what you're trying to explain: AFAIK, onImmediateValueChange is not a method, it's a signal.
I'm calling the setValue method to change the value, but I don't want the onValueChanged signal to be raised (or at least I'd like to have a way to know that it has been changed by my app and not by user interaction)
10-23-2012 05:14 PM
This is kind of what I tried by raising a flag true before calling the setValue and changing it to false right after the call, but it seems that the multithreading is tricking with me because when my slot is called by qml, my flag is already false.
Same if I disactivating the slot and reactivating right after the call.
What I'm trying to achieve is kind of mediaplayer, where the media is updating the slider, but the slider can update the media by user interaction.
10-23-2012 06:15 PM
In my opinion Slider API in BB10 doesn't distinguish between the change made by user and programmatically.
onValueChanged and a onImmediateValueChange should send an extra value (eg. bool fromUser)
fromUser - true if the change was initiated by the user
10-24-2012 07:06 AM
Obviously, this would be the best to me, but given that the flag is not working, I need to dig a bit more here.
The problem may lay in the fact that i'm using a thread to update the slider.
I'm pretty sure solution already exist: I don't see how it would be possible to do a mediaplayer otherwise.
10-24-2012 10:21 AM
why not take advantage of the fact that you know that you will be getting a new signal when you do the update.
set your "ignore" flag when you push your update out, and clear it when the changed signal is received instead of clearing it after you finish your update. This has the advantage of letting you know that everything is synchronized by the time you clear the flag.
the problem is likely that the onValueChanged signal is not being emitted until after your thread completes, at which point you've already cleared your flag.