当 0.0 < 时 UIProgressView 不会改变进度< 0.03

发布于 2024-08-16 17:14:17 字数 720 浏览 8 评论 0 原文

我有一个 UIProgressView,用来直观地表示一分钟计时器。其宽度为 280 像素。我正在使用 NSTimer 逐渐减少“进度”的值,从进度 = 1.0 开始。 “进度”每十分之一秒更新一次。除了最后两秒之外,它完全按照我的意愿进行。

一旦“progress”的值低于 0.03,UIProgressView 的移动就会停止(显示大约 0.2cm 的条形),直到“progress”达到 0.0,此时 0.2cm 的条形就会消失。

有谁知道为什么 UIProgressView 会这样?这是设计使然,还是我做错了什么?

编辑:

mjdth,

我不认为这与舍入有关,因为在 NSTimer 调用的方法中,我使用 NSLog 来显示“进度”的值,并且它打印有六位有效数字,例如

2009- 12-31 21:13:22.462 XXXXXXX 0.101669
2009-12-31 21:13:22.562 XXXXXXX 0.100003

此外,如果是这样的话,所有的运动都会变得不稳定,而不仅仅是最后两秒。这是 NSTimer 调用的代码:

- (void) updateProgressBar {
    timerProgressBar.progress = [playEndTime timeIntervalSinceNow] / 60.0;
    NSLog(@"%f", timerProgressBar.progress);
}

I have a UIProgressView that I'm using to visually represent a one-minute timer. Its width is 280 pixels. I'm using NSTimer to gradually decrease the value of 'progress', starting at progress=1.0. 'Progress' gets updated once every tenth of a second. For all but the final two seconds, it does exactly what I want it to.

Once the value of 'progress' goes below 0.03, the movement of the UIProgressView stops (showing about .2cm of bar) until 'progress' reaches 0.0, at which point the .2cm of bar simply disappears.

Does anyone know why UIProgressView is behaving this way? Is this by design, or am I doing something incorrectly?

edit:

mjdth,

I don't think it has to do with rounding, since in the method that NSTimer calls, I'm using NSLog to show the value of 'progress', and it gets printed with six significant digits, e.g.

2009-12-31 21:13:22.462 XXXXXXX 0.101669
2009-12-31 21:13:22.562 XXXXXXX 0.100003

Besides, if that were the case, all of the movement would be choppy, not just the last two seconds. Here is the code that NSTimer calls:

- (void) updateProgressBar {
    timerProgressBar.progress = [playEndTime timeIntervalSinceNow] / 60.0;
    NSLog(@"%f", timerProgressBar.progress);
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

旧城烟雨 2024-08-23 17:14:17

我相信这是设计使然,因为进度条的圆形端盖无法部分绘制。低于某个阈值但高于零时,仅绘制两个端盖,只有当它高于某个阈值时,才会绘制并扩展图像的中间部分。

如果您按照正常的前进方向使用进度条,它会起作用吗?它可以正常绘制最后几秒钟,因为它在另一端没有这种限制。

I believe it's by design because the rounded end caps of the progress bar can't be drawn partially. Below a certain threshold, but above zero, just both the end caps are drawn, and only when it gets above a certain level does the middle part of the image get drawn and extended.

Would it work if you used the progress bar in its normal, forward direction? It can draw the last few seconds normally because it doesn't have that limitation at the other end.

末蓝 2024-08-23 17:14:17

它与您的进度金额的四舍五入或计算有什么关系吗?您能否展示一下代码,以便我们查看。可能只是进度变量本身被计算为 0.3。

您是否在运行时检查过以确保进度变量更新为 0.2 或 0.1 等?

Does it have anything to do with the rounding or calculating of your progress amount? Can you show the code for that so we can look at it. It might simply be that the progress variable itself is being calculated to 0.3.

Have you checked during runtime to make sure that your progress variable is updating to 0.2 or 0.1 etc?

北城半夏 2024-08-23 17:14:17

如果你(和苹果)不介意颜色反转,你可以水平翻转视图,开始为空,然后逐渐填满。它也会有同样的问题,但是是在开始而不是结束时。

If you (and Apple) don't mind the colors being reversed, you could flip the view horizontally and start it empty and gradually fill it up. It's going to have the same problem, but at the beginning instead of the end.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文