Thanks Marcel,

That should get me pointed in the right direction. I will report back if
I find something of general interest.

Dave

On Thu, Sep 28, 2017 at 08:32:57AM +0200, Marcel Taeumel wrote:
> Hi Dave,
> 
> in short, take a look at??Morph >> #clearArea to honor the Sugar navigation bar.
> 
> You can find a longer explanation by navigation the following code snippets:
> 
> SystemWindow >> #justDroppedInto:event:
> SystemWindow >> #assureLabelAreaVisible
> RealEstateAgent class >> #maximumUsableAreaInWorld:
> Morph >> #visibleClearArea
> Morph >> #clearArea
> 
> The avoidance of the docking bar on window-drop is new. But the actual logic behind it is very old, from 2004. It has been used for maximizing a window.
> 
> To verify, try maximizing your window and see if it also interferes with the Sugar navigation bar.
> 
> Maybe the SugarNavigatorBar should respond to #isDockingBar with true. Might do the trick. ;-)
> 
> Best,
> Marcel
> 
> Am 28.09.2017 04:26:08 schrieb David T. Lewis <lewis at mail.msen.com>:
> When I use the mouse to move a SystemWindow to a new position, the mouse
> down produces a square frame that moves with the hand position, and the
> mouse up makes the frame go away with the SystemWindow being relocated
> to the new position.
> 
> In most cases, the new position of the SystemWindow is the position to
> which it was moved with the mouse. However, if the new position is at the
> top of the world PasteUpMorph, possibly conflicting with the world main
> docking bar or the Sugar navigator bar, then the new SystemWindow position
> is modified to avoid the top region.
> 
> Where is the code that figures out the new position in the case of a
> SystemWindow being dragged to the top of the world PasteUpMorph? I am
> trying to debug a window positioning problem in one of my images, and
> I cannot figure out where the magic happens.
> 
> Thanks,
> Dave
>