re-sizing Ellipse shapes by typing Size: X / Y

[tpjctrl]

This is one of those things that constantly drives me nuts, if anyone can repeat the following steps and report back I'd appreciate it:

1. draw an ellipse
2. type in Size X: 200
3. type in Size Y: 200
4. drag and move the ellipse

At this point the ref point will most likely change to a random X/Y coordinate. Why does this happen?

Also, why does typing in Size X / Y typically lead to the typed in value changing by 1? For example typing 200 typically changes to 201 or 199 right after pressing Enter, this happens for both Size X and Size Y. Another thing that bothers me is that even if you somehow successfully type in 200 in Size X / Y, dragging the shape normally changes X or Y and you end up with for example 201 / 200. And finally, if you open up the panel file and locate the shape size / refpoint / geometry, those very often have non-integer values with rather long decimal part (for example instead of 200 it's 200.1298347129846), why is this?

[leoknipp]

I have tested it with WinCC OA 3.18 and I cannot reproduce the problems you have described.
Which WinCC OA version and patch level are you using?

Best Regards
Leopold Knipp
Senior Support Specialist

[tpjctrl]

WinCC OA 3.17 P009, but you have to repeat the re-sizing at least twice, for some reason the first time you do it and move the ellipse it doesn't happen. So check the following:

- create new panel
- draw an ellipse, random size
- click on the Size X value and change it to something else
- drag the ellipse to a new location (after this the ref point remains in the center)
- again click on the Size X value and change it to something else
- drag the ellipse to a new location

After the last step, the ref point should "jump" to a random location. Same thing happens with the circle shape (which is effectively an ellipse anyway).

Can you explain the other two issues I've mentioned? ie. typing the size which almost always leads to the final value "jumping" up by 1 and why the internal xml size parameters almost always are floating values with a long decimal part?

[leoknipp]

I have tested it again with 3.17 P012.
The only thing I could see is that the ref point is not changed in step 4 of your description.
After all the changes the transformation matrix in the panel file still shows integer values not floating point values.

Best Regards
Leopold Knipp
Senior Support Specialist

[tpjctrl]

I've made a short desktop capture showing the bug in real time, is there an easy way to somehow attach a 40mb'ish video here?

[RJM1987]

I know the exact bug you're talking about it and it too drives me nuts!

I've reported it before: viewtopic.php?f=15&t=11055&p=967151#p967151

[tpjctrl]

Ah finally someone who replicated this very often with things like this it only seems to happen when you're not trying to "capture" it.

[kilianvp]

It happens because the values are stored as float.

[leoknipp]

Which "values" are stored as floats?
Always you have to take into account which version and patch level you are using as the functionality may change.

Best Regards
Leopold Knipp
Senior Support Specialist