Hi Bob,

Thanks for the hint about:

     self addMorph: (MorphB new position: 1 at 1 + self position)

Because I am loading images for the clock face and hands, I have had to do the loading and
definition of the morphs after the #initialize method has exited.  Also, I am only drawing
clock hands if they are not loaded from images.  I have added a #setReady that declares the
clock ready to be opened.  I was lazily initializing the hands.  If a drawn hand was used and
not an picture, this would happen after the clock was opened in world (#openInWorld).  That
caused the rotation point to be off.  I have changed #setReady (which should be called before
#openInWorld) draw the hands if need be.  That puts the rotation point of the hands in the
right spot in all cases.

As far as the setting and later reporting of position not being different, I will take your
word for it.  But it does seem to me that before being open in world, position is 0 at 0 offset
and after words it is offset to the screen.

Thanks again.

Lou

On Tue, 19 Dec 2017 12:30:13 -0500, Bob Arning <arning315 at comcast.net> wrote:

>The setting and later reporting of position are not different and this 
>is a cause of occasional errors. If you have
>
>MorphA>>initialize
>
>     self addMorph: (MorphB new position: 1 at 1)
>
>
>then B will be positioned one pixel from the top left of A. If, however, 
>you do
>
>     self addMorph: (MorphB new position: 1 at 1)
>
>sometime later after A has been added to the World and possibly moved, 
>then you may get something different, like B being one pixel from the 
>Display top left, regardless of where A is currently. If that is the 
>case, and, maybe, as a general precaution, then
>
>
>     self addMorph: (MorphB new position: 1 at 1 + self position)
>
>would be more robust.
>
>
>On 12/19/17 11:41 AM, Louis LaBrunda wrote:
>> It seems odd to me that when the position of a new TransformationMorph is set it is based on
>> where it is to go in its parent morph but if you ask it its position later, it answers its
>> position on the screen.  I say that this disconnection may have something to do with the
>> rotation problem because I think the rotation code does some math based upon the position of
>> the morph.  I expect the code thinks it is using a position based upon the parent and not the
>> screen.
-- 
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon