Possible Bug?

--===============5105898879839521779==
Content-Type: multipart/alternative; boundary="94eb2c08d23c1868f60563b4dfbb"

--94eb2c08d23c1868f60563b4dfbb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I haven't investigated it into the Etoys source, but I found this bizarre
bug, likely appearing due to a number being turned into an integer when
it's odd, but I cannot figure out why it would be called at all...

Included is a project that demonstrates this bug.  I looked at the
individual pieces and they aren't 'personally' responsible, but when
working as a unit, they then exhibit the bug.

=E2=80=8B
 custom window demos.013.pr
<https://drive.google.com/file/d/1nefep7r-gSbJ5xyLGKbWUU54ozFlzNid/view?usp=
=3Ddrive_web>
=E2=80=8B

Basically what seems to cause it is resizing nested playfields via script.
R=E2=80=8B=E2=80=8Besizing with morphic handles works fine, but when sendin=
g an Etoys
'LENGTH' change, somewhere along the line, things go wrong.  Again, my
guess is that some number is getting changed into an integer from a
floating point, and thus getting rounded up, which would shift it up when
it's not a floating point number any longer.  However, this doesn't explain
why it doesn't have the same symptom when changing WIDTH.

Thanks for any insight into dealing with this.  I'm not exactly sure where
to begin looking within the Etoys Source to make things work as expected
since there's likely 30 reasons (read: random object methods) why this
might occur and only for vertical change/LENGTH change.

--94eb2c08d23c1868f60563b4dfbb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I haven&#39;t investigated it into the Etoys source, but I=
 found this bizarre bug, likely appearing due to a number being turned into=
 an integer when it&#39;s odd, but I cannot figure out why it would be call=
ed at all...<div><br></div><div>Included is a project that demonstrates thi=
s bug.=C2=A0 I looked at the individual pieces and they aren&#39;t &#39;per=
sonally&#39; responsible, but when working as a unit, they then exhibit the=
 bug.</div><div><br></div><div>=E2=80=8B<br><div class=3D"gmail_chip gmail_=
drive_chip" style=3D"width:396px;height:18px;max-height:18px;background-col=
or:#f5f5f5;padding:5px;color:#222;font-family:arial;font-style:normal;font-=
weight:bold;font-size:13px;border:1px solid #ddd;line-height:1"><a href=3D"=
https://drive.google.com/file/d/1nefep7r-gSbJ5xyLGKbWUU54ozFlzNid/view?usp=
=3Ddrive_web" target=3D"_blank" style=3D"display:inline-block;overflow:hidd=
en;text-overflow:ellipsis;white-space:nowrap;text-decoration:none;padding:1=
px 0px;border:none;width:100%"><img style=3D"vertical-align: bottom; border=
: none;" src=3D"https://drive-thirdparty.googleusercontent.com/16/type/appl=
ication/x-zip">=C2=A0<span dir=3D"ltr" style=3D"color:#15c;text-decoration:=
none;vertical-align:bottom">custom window demos.013.pr</span></a></div>=E2=
=80=8B<br></div><div><br></div><div>Basically what seems to cause it is res=
izing nested playfields via script.=C2=A0 R=E2=80=8B=E2=80=8Besizing with m=
orphic handles works fine, but when sending an Etoys &#39;LENGTH&#39; chang=
e, somewhere along the line, things go wrong.=C2=A0 Again, my guess is that=
 some number is getting changed into an integer from a floating point, and =
thus getting rounded up, which would shift it up when it&#39;s not a floati=
ng point number any longer.=C2=A0 However, this doesn&#39;t explain why it =
doesn&#39;t have the same symptom when changing WIDTH.</div><div><br></div>=
<div>Thanks for any insight into dealing with this.=C2=A0 I&#39;m not exact=
ly sure where to begin looking within the Etoys Source to make things work =
as expected since there&#39;s likely 30 reasons (read: random object method=
s) why this might occur and only for vertical change/LENGTH change.</div><d=
iv><br></div><div><br></div><div><br></div><div><br></div></div>

--94eb2c08d23c1868f60563b4dfbb--

--===============5105898879839521779==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3F1ZWFrbGFu
ZCBtYWlsaW5nIGxpc3QKc3F1ZWFrbGFuZEBsaXN0cy5zcXVlYWtsYW5kLm9yZwpodHRwOi8vbGlz
dHMuc3F1ZWFrbGFuZC5vcmcvbWFpbG1hbi9saXN0aW5mby9zcXVlYWtsYW5kCg==

--===============5105898879839521779==--