Question about speed dial decimal point
Why is the decimal point being removed from the millisecond box when it sends the value to speeddial.cpp? Meaning, if the box says .99 speeddial.cpp gets the value as 99. So if the value in the box is .09, then speeddial.cpp gets the value as 09, which of course QT will strip the 0, which isn't a bug with QT at all. The problem is, if .09 is in the box, the actual value .09 should be received by speeddial.cpp. This is what is messing it up.
Dude, you're flooding my email box by posting something every ten minutes.
Please calm down with code blind shooting and judgements on something you don't understand.
We understand there is something not right on speed dials, so have patience and we'll fix it.
No need for all this noise.
Please calm down with code blind shooting and judgements on something you don't understand.
We understand there is something not right on speed dials, so have patience and we'll fix it.
No need for all this noise.
Start with reading [this](https://github.com/mcallegari/qlcplus/b ... l.cpp#L159) and then check in [QT documentation](http://qt-project.org/doc/qt-4.8/qspinbox.html) what the various methods do (e.g. setPrefix()).
You'll see that the decimal point is not a part of the number, just a decoration. The spinbox works with integers. We could use QDoubleSpinBox, but it would contain leading 0 before decimal point. With integers, 09 and 9 is the same thing.
The straightest way to implement this IMO is described in my other comment. For more hint see the accepted answer for [this question](http://stackoverflow.com/questions/2653 ... s-4-digits).
You'll see that the decimal point is not a part of the number, just a decoration. The spinbox works with integers. We could use QDoubleSpinBox, but it would contain leading 0 before decimal point. With integers, 09 and 9 is the same thing.
The straightest way to implement this IMO is described in my other comment. For more hint see the accepted answer for [this question](http://stackoverflow.com/questions/2653 ... s-4-digits).
I have another idea. When ms value < 10 the spinbox prefix should be ".0"
Makes sense ?
Makes sense ?
OK, Point taken. But while I may not understand everything about your code, I have found some things that I KNOW are wrong. Hope you find them.
Good luck!
Good luck!
Another suggestion from my side, if you have the chance to work on speed dials: I would like to set the minimum value from external input below 1s, but greater than 0s (f.e. ".20". Does it make sense?
Thanks for your effort, guys!
Thanks for your effort, guys!
As an idea, why don’t we get rid of the prefix and just add '0ms' as a suffix?
We could then in speeddial.cpp get rid of:
line 286
QString msText = m_ms->text();
int msInt = m_ms->value();
if (msInt < 10 && msText.contains("0") == false)
value += (msInt * MS_DIV * 10);
else
value += (msInt * MS_DIV);
and just have:
value += (msInt * MS_DIV);
I do think a minimum value is worth while, what it should be I am not sure but I think 0.02s or 20ms is about right considering the DMX frame rate.
We could then in speeddial.cpp get rid of:
line 286
QString msText = m_ms->text();
int msInt = m_ms->value();
if (msInt < 10 && msText.contains("0") == false)
value += (msInt * MS_DIV * 10);
else
value += (msInt * MS_DIV);
and just have:
value += (msInt * MS_DIV);
I do think a minimum value is worth while, what it should be I am not sure but I think 0.02s or 20ms is about right considering the DMX frame rate.
I already stated (maybe in wrong place) what I think it's needed to do: https://sourceforge.net/p/qlcplus/discu ... 33e3/#dccb
Regarding the minimum: one thing is that indeed 20ms is reasonable minimum, but you have to handle cases when seconds/minutes/hours are >0 the 0 is allowable minimum for ms (to be able to enter e.g. 3.0s).
Regarding the minimum: one thing is that indeed 20ms is reasonable minimum, but you have to handle cases when seconds/minutes/hours are >0 the 0 is allowable minimum for ms (to be able to enter e.g. 3.0s).
I will have a look into working something out here.
I will have to brush off my skills a bit
I will have to brush off my skills a bit
Also, the minimum should only be for Hold duration, as a 0 for fades is often desired and causes no problems.
Then you must be using fade-ins and/or Fade-outs.
Jano, this is another situation where 0ms holds are acceptable. So, if hold seconds/minutes/hours are >0 or if fade-in or fade-out ms/seconds/minutes/hours are >0 then 0ms is allowable.
But then a 20ms hold between fades would be virtually imperceptible, so it may not be necessary.
Jano, this is another situation where 0ms holds are acceptable. So, if hold seconds/minutes/hours are >0 or if fade-in or fade-out ms/seconds/minutes/hours are >0 then 0ms is allowable.
But then a 20ms hold between fades would be virtually imperceptible, so it may not be necessary.
It may be be imperceptible, but it could be critical for exact timing in a show sync to audio situation. More flexibility with QLC+ is better than locking everything down for simplicity. This isn't an Apple product.
> Then you must be using fade-ins and/or Fade-outs.
Not necessarily.
> It may be be imperceptible, but it could be critical for exact timing in a show sync to audio situation. More flexibility with QLC+ is better than locking everything down for simplicity.
Yes.
> This isn't an Apple product.
Hahaha
Not necessarily.
> It may be be imperceptible, but it could be critical for exact timing in a show sync to audio situation. More flexibility with QLC+ is better than locking everything down for simplicity.
Yes.
> This isn't an Apple product.
Hahaha