Ticket #141 (closed defect: wontfix)
Volume bounds are not reset upon call to setEmpty
| Reported by: | cneumann | Owned by: | unassigned |
|---|---|---|---|
| Priority: | minor | Milestone: | 1.8 Release |
| Component: | System | Version: | 1.8 |
| Keywords: | Cc: |
Description
for a non-empty DynamicVolume vol, calling vol.setEmpty(), vol.getBounds(min,max) will give the old min,max values, not the expected (0,0,0), (0,0,0).
Reported on the users list by Josef Grunig, message titled "updateVolume strange behaviour"
Attachments
-
testVolumeBug.cpp
(1.7 KB) -
added by cneumann 6 years ago.
- small test to demonstrate the problem
Change History
Changed 6 years ago by cneumann
-
attachment
testVolumeBug.cpp
added
comment:1 Changed 6 years ago by cneumann
- Status changed from new to closed
- Resolution set to invalid
Dirk has clarified that this is intentional, code has to deal with empty volumes by explicitly checking with Volume::isEmpty()
closing as invalid.
comment:2 follow-up: ↓ 3 Changed 6 years ago by dirk
- Priority changed from major to minor
- Status changed from closed to reopened
- Resolution invalid deleted
Followup: Generally true, an app that wants to handle empty volumes need to check flags. Nonetheless, we could set the bounds to 0 on set empty. I don't like it very much, as setState() would circumvent it...
comment:3 in reply to: ↑ 2 Changed 6 years ago by cneumann
Replying to dirk:
Followup: Generally true, an app that wants to handle empty volumes need to check flags. Nonetheless, we could set the bounds to 0 on set empty. I don't like it very much, as setState() would circumvent it...
me neither; if we did it, it would be even harder to find the bug next time. So let's close this ticket and open one to add documentation to the volume stuff that explains this ;)
small test to demonstrate the problem