LabVIEW
Why it can't work?
So another question is why. The fact that a progress bar defaults to u8 must be rooted in very ancient times where memory was tight and very expensive. 😄
@altenbach wrote:
So another question is why. The fact that a progress bar defaults to u8 must be rooted in very ancient times where memory was tight and very expensive. 😄
Its for the same reason most digital o-scopes are 8 bit. They are meant for human eyeballs and 8-bits is finer than the eye can easilly distinguish.
EDIT: Huh? I'm telling that to who?
@Dennis_Knutson wrote:
Well, I'd guess that a progress bar would be used to show 0-100.
Yes, but in 100% of my applications it is based on N and i of a FOR loop, so I32 would avoid a coercion and extra data copy. 😉
I always change the representation to I32.
(Here's what I typically use. For a parallel FOR loop it is a little more complicated as discussed elsewhere....;))
(Also a percent value is generally based on a division, so it is typically not even an integer. What if the progress bar is 300 pixels wide and shows a digital display showing the progress with two decimal digits? Now we need a DBL)
altenbach wrote:
I always change the representation to I32.
(Here's what I typically use. For a parallel FOR loop it is a little more complicated as discussed elsewhere....;))
(Also a percent value is generally based on a division, so it is typically not even an integer. What if the progress bar is 300 pixels wide and shows a digital display showing the progress with two decimal digits? Now we need a DBL)
I also normally change the representation to I32. But I also use a property node before the FOR loop to set the maximum to N. Inside the FOR loop, I then just wire i straight into the progress bar's terminal. It avoids all of the extra math at the expense of writing to a property node once.
Yes, that works if you don't show the digital display.
(It also won't work for parallel FOR loops because [i] will be in random order. 😉 You would still need more advanced code)
