How do I reach the Limits on a DBL Slider

[AStankov]

---

altenbach wrote:

If you want a solution that does not require any code changes, make an Xcontrol that handles all desired rounding internally and use it as a drop-in replacement.

Frankly, I don't understand your hangups here. As others have mentioned, 0.1 cannot be accurately represented in binary and there is no way around that. Do you really want LabVIEW to ignore standards that everybody else has agreed on? If you want different behavior, you need to program around it and there are plenty off suggestions.

If compilers would start correcting numbers internally by making assumptions about intent, chaos would ensue.

---

I don't want LabVIEW to ignore any standards and I do not want NI to rewrite the compiler. I think you don't understand where the problem is. It only concerns the way how the controls work, not the compiler. If LabVIEW lets me set a minimum and a maximum for a double, of course I want to be able to go to that minimum and maximum and not just to some value one increment above the minimum or one increment below the maximum. It is a simple matter of making LabVIEW set the value to the maximum when it sees that incrementing the value by the increment will be greater than the maximum instead of ignoring the new value as it does at the moment. At least there should be an option for making it work that way.

So far none of the workarounds propsed works perfectly for my problem. If I coerce manually I will need to allow the user to set the value to a value which is actually not allowed (e.g. with the slider) and than to jump back to the value allowed. This also involves an interface update delay which is visible. Additionally, setting the limits to -45.0001 and 45.0001 involves another ugly problem: 0 shows up as -0.0 This is not an elegant solution at all. The proposed solution using an integer slider on top of the double slider is also not what I call elegant. This workaround also does not allow me to enter values into the digital display.

Thank you for the suggestion regarding XControl. I will check that option if I have more time although I doubt that it will solve all problems described above.

From my point of view I want to emphasize again that it should be the task of the developers to make this standard control work. We are not talking about open source here. We are talking about expensive software I paid for. Being able to easily configure visual controls and indicators is one of the main advantages of LabVIEW. I think that making these things work is much more important than adding new features like automatic block diagram cleanup etc.

[AStankov]

Ooops, looks like XControls are only available in LabVIEW Professional Development System. I am not going to pay more for something that does not work...

[billko]

---

AStankov wrote:

---

altenbach wrote:

If you want a solution that does not require any code changes, make an Xcontrol that handles all desired rounding internally and use it as a drop-in replacement.

Frankly, I don't understand your hangups here. As others have mentioned, 0.1 cannot be accurately represented in binary and there is no way around that. Do you really want LabVIEW to ignore standards that everybody else has agreed on? If you want different behavior, you need to program around it and there are plenty off suggestions.

If compilers would start correcting numbers internally by making assumptions about intent, chaos would ensue.

---

I don't want LabVIEW to ignore any standards and I do not want NI to rewrite the compiler. I think you don't understand where the problem is. It only concerns the way how the controls work, not the compiler. If LabVIEW lets me set a minimum and a maximum for a double, of course I want to be able to go to that minimum and maximum and not just to some value one increment above the minimum or one increment below the maximum. It is a simple matter of making LabVIEW set the value to the maximum when it sees that incrementing the value by the increment will be greater than the maximum instead of ignoring the new value as it does at the moment. At least there should be an option for making it work that way.

So far none of the workarounds propsed works perfectly for my problem. If I coerce manually I will need to allow the user to set the value to a value which is actually not allowed (e.g. with the slider) and than to jump back to the value allowed. This also involves an interface update delay which is visible. Additionally, setting the limits to -45.0001 and 45.0001 involves another ugly problem: 0 shows up as -0.0 This is not an elegant solution at all. The proposed solution using an integer slider on top of the double slider is also not what I call elegant. This workaround also does not allow me to enter values into the digital display.

Thank you for the suggestion regarding XControl. I will check that option if I have more time although I doubt that it will solve all problems described above.

From my point of view I want to emphasize again that it should be the task of the developers to make this standard control work. We are not talking about open source here. We are talking about expensive software I paid for. Being able to easily configure visual controls and indicators is one of the main advantages of LabVIEW. I think that making these things work is much more important than adding new features like automatic block diagram cleanup etc.

---

To be fair to Stankov, it seems that the increment/decrement button suffers from a split-personality disorder.  The help file would have you believe it was meant to be a course control, while the fact that the representation of the increment value itself (dbl) suggests that it is a fine-tuning mechanism.  The final implementation seems to be as a course tuning control.

This is a valid complaint, although a very minor one.  I think Stankov is just a LabVIEW hater.  😉

I'd hate to hear his thoughts on Windows, the OTHER software that he paid a lot of money to use.   😮 😉

Bill

Message Edited by billko on 09-11-2009 02:11 PM

Message Edited by billko on 09-11-2009 02:11 PM

[altenbach]

---

AStankov wrote:
Ooops, looks like XControls are only available in LabVIEW Professional Development System. I am not going to pay more for something that does not work...

---

How do you know the Xcontrol will not work? 😮

However, I agree that every increment/decrement operation should include a coerce to nearest operation (if so configured) so errors don't accumulate if increment is pressed a near infinite number of times in a row :o. Currently, there is a different 44.9 if reached via increments from zero compare to a directly entered 44.9 (the latter allows to go to 45 with an increment while the first stalls at 44.9). Both should be coerced to the same.

This is all ultra cheap UI stuff, so there are no performance considerations needed. It just needs a little bit more code behind the scene)

Feel free to post this as a suggestion in the LabVIEW Ideas Exchange for consideration in a future version of LabVIEW. I would probably vote for it. 😄

Still, there are several trivial workarounds available, so the absence of this feature should not really stall your project.  Good luck! 😄

[AStankov]

---

altenbach wrote:

However, I agree that every increment/decrement operation should include a coerce to nearest operation (if so configured) so errors don't accumulate if increment is pressed a near infinite number of times in a row :o. Currently, there is a different 44.9 if reached via increments from zero compare to a directly entered 44.9 (the latter allows to go to 45 with an increment while the first stalls at 44.9). Both should be coerced to the same.

This is all ultra cheap UI stuff, so there are no performance considerations needed. It just needs a little bit more code behind the scene)

Feel free to post this as a suggestion in the LabVIEW Ideas Exchange for consideration in a future version of LabVIEW. I would probably vote for it. 😄

Still, there are several trivial workarounds available, so the absence of this feature should not really stall your project.  Good luck! 😄

---

Now you seem to realize what my problem is. Actually it has nothing to do with double imprecision directly but with the incorrect coersion (especially at the limits). I can even live with the error accumulation during increment/decrement if LabVIEW could just let me reach the limits. I don't think that I am the only one who has this problem. Most applications use floating point values and it is important to be able to quickly set a value through the slider and than to be able to fine tune this value using the increment/decrement arrows. Not being able to reach the limits with increment/decrement is clearly considered as a bug by the user. I don't think that this is "ultra cheap UI stuff". Whatever workaround I implement it will not be perfect because I have to wait for the value change event before coercing manually. This means that I have to let the user set an out of range value on the slider and then go back to the correct value. This is not what I call professional software. The correct coerce function must be implemnted into the control to be able to work flawlessly. Unfortunately I don't have LabVIEW Professional and I am not able to test if XControls may solve the problem.

I don't think that my problem is something for "Ideas Exchange". I had discussed my problem with the NI application engineers in Germany multiple times and they clearly stated that this behavior is not expected and is considered as a bug. They have reported it to development, at least they told me that they did. This is also why I don't understand why people in this forum try to convince me that this is normal behavior of the control and should not be changed. NI told me that the bug will be fixed in the next version of LabVIEW but it did not happen. Unfortunately I have no confirmation that someone is working on the problem.

Best regards,

Anguel

[Ben]

Any time you report a bug to NI, please ask for a CAR (corrective action Report) number.

THe CARum. let you track a bug. You can call NI support and ask about the CAR and they can get you a status update. I have access to a list of important CARs that R&D keeps updaed for teh LabVIEW Champions (we review and prioritize bugs that are important). enve in that list we are never guarenteed whena bug will be fixed (if testing says no-go for the fix at teh last minute, it does not ship!).

The are many times when CARs get closed as "not a bug" after R&D looks into it.

So the best advise I can offer is to get on the phone to NI and have them go backthrough all of your service requests adn find the CAR. Get a status on it and if it is still active, please share it with us.

It is is not that we will believe R&D but not believe anyone else. It isjust that we have some rules we have to adhede too. The big one is does the code operate as per its design? If it does there is no bug and we have to aks for  design change.... LabVIEW Ideas forum.

Just trying my best to help everyone involved.

Ben

[AStankov]

---

Ben wrote:

So the best advise I can offer is to get on the phone to NI and have them go backthrough all of your service requests adn find the CAR. Get a status on it and if it is still active, please share it with us.

---

Thank you very much for the information Ben! I found the CAR. It is 169623.  I will call tomorrow and ask for the status. If you have some access to the CAR database and check the status please let me know.

 

Best regards,

Anguel

[AStankov]

Update: I called NI Germany and they told me that the status of my problem is "In Work" but there was no additional comment so far 😞

[BenvanSeggelen]

I know it has been a while since the last post, but I had a similar problem using LabVIEW 2014.

Fixed it by changing the DBL control to SGL, try it out