Archived SystemWindow questions
Last updated at 7:24 pm UTC on 15 May 2018
Questions moved here from page SystemWindow
Question: How to make sure System Window is always activated? August 16, 2004 I have a
containing a TwoWayScrollPane
containing a PasteUpMorph
[As expected, t]he window is activated (moved to the top) if I click the SystemWindow header.
It is not activated if I click in a visible corner of the PasteUpMorph.
I have tried making the PasteUpMorph keep the event WasHandeled at =false, but it doesn't help.
Answer: Hernan Tylim
You should check DiagramBrowser. In there I have the same structure as you (SystemWindow, TwoWayScrollPane and PasteUpMorph) but without the problem you are describing.
How are you handling the events? With #on:send:to: or overriding #handlesMouseDown: and #mouseDown: ?
Because If you return false in #handlesMouseDown: I am pretty sure that the event should reach the SystemWindow and get it activated.
BTW, you can always send the #activate message from the event handler to the SystemWindow yourself.
Question: And why use so many layers of morphs? Trygve Reenskaug
Problem resolved. Many thanks for putting me on the right track.
The problem was that TwoWayScrollPane>>handlesMouseDown: returned true and the event did not reach up to the SystemWindow.
Changing it to false solved the problem.
Jacaranda was my starting point for the present programs, but I have tried to simplify the morph structure.
Corresponding to my three levels, I find 6 levels in Jacaranda:
a Morph (Morph default)
a Diagram (handlesMouseDown: returns evt yellowButtonPressed, i.e., false)
a TwoWayScrollPane (handlesMouseDown: returns true)
a TransformMorph (Morph default)
a HJPasteUpMorph (handlesMouseDown: returns true)
I haven't quite penetrated the rationale behind the many layers in Jacaranda, but it seems as if I could have introduced a dummy layer below the SystemWindow for the purposes of returning false. My solution is to use my own sco of TwoWayScollPane that returns true. This may be a hack since I there may be a deep reason for ScrollPanes to return true.
Answer: Hernan Tylim
It was a long time ago but I think the rationale was this.
The DiagramBrowser SystemWindow is composed of 3 panels.
The two on the left and the one on the right where the Diagrams appear.
This last one isn't a Diagram but a simple Morph acting as a container because if it wasn't in that way then the SystemWindow would change the Diagram's color to match the one of the window.
Another reason for using SystemWindows in this way is that I found it more convenient for adding and removing submorphs. Here you just add and remove submorphs from the container and you forget about the SystemWindow. Without the container you would have to be careful about how you add and remove the morphs so as to not mess up the LayoutFrames and resizeability (does exists that word?) of the SystemWindow panels.
Inside Diagram what we have is:
To reduce one level of composition we could make Diagram to be a subclass of TwoWayScrollablePane, but I did it in this way because a Diagram do not only holds the TwoWayScrollablePane but also an extra annotation panel which is not visible by default (right click on the diagram and select: 'shows annotations panel').
The TransformMorph is part of the TwoWayScrollablePanel so we cannot get rid of it. The last level is the PasteUpMorph which holds the shapes, and thatís it. Those were the six level.