Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
1) In detail, describe a problem that you experienced in Squeak. What was the problem? Why did it happen? How did you eventually overcome this problem?
I actually have extensive experience with Squeak... I guess that's a good thing for this class, but it has warped my fragile little mind with respect to programming in other languages. One thing that took me a long time to figure out was how to update morphs that are being placed on-screen by other morphs. That is, morphs that have been created and added to other morphs' submorph lists; especially ones that your code does not add such as the components of provided Morphic classes. Why was it so difficult to update and modify those submorphs and components? Two reasons: Squeak is just written that way and I was still learning all the tricks. The method I finally found seems to be strongly advised against by Squeak's limited comments, but it has given me the most reliable outcome over other ways I have experimented with. This method is primarily related to accessing and modifying submorph lists.
By using the methods in the class Morph labeled 'private', the task of updating and controlling a morph's submorphs is made easier. Also, some other aspects of morphs like position and size can be controlled more.. forcefully with the private methods if you know what you are doing. I mostly use privateRemove: and privateAddMorph: atIndex:. For privateRemove:, you pass in the morph you know for a fact is in the submorphs list and it is removed from that morph. I use privateAddMorph: aMorph atIndex: anInteger to add in updated morphs behind the scenes. After using these private methods, you should execute the command 'changed' on the morph whose submorphs you modified in order for it to update its appearance on-screen.
There are two non-private methods I use in conjunction with these to retrieve indexes of submorphs and references to submorphs. To get the index of a submorph in a morph's submorph list, I use submorphIndexOf: aMorph. Most of the custom morphs you make hold unique submorphs that are of different classes. When you only use one instance of a class in a submorph list, you can retrieve that instance by using the method submorphOfClass: aClass, where aClass is simply the name of a class outside single quotes. I.e.: aMorph submorphOfClass: MyCustomMorph. To put this all together, here is a simplified procedure using these methods:
myMorph <- MyBox new.
myMorph addItem: (MyItem new).
anywhere myMorph is in scope:
| i oldMorph newMorph |
oldMorph <- myMorph submorphOfClass: MyItem.
i <- myMorph submorphIndexOf: oldMorph.
newMorph <- MyItem new.
do stuff to newMorph like initialization, transfering of certain
data from oldMorph such as position, color, size, etc.
myMorph privateRemove: oldMorph.
myMorph privateAddMorph: newMorph atIndex: i.
Using this method, you can be sure that the submorphs of your morphs are being updated when you want them to be.
Derek DeRaps' post discusses the inspect feature of squeak which I feel is a very important feature. I use it all the time and it helped me learn how to program in Squeak.
Courtland Goodson's recommendation is a good one that I have always followed. It's not a good idea at all to edit main classes of Squeak i.e., classes that are included in the original release code.
Amro Mousa had the right idea with this post but the correct syntax to use in class methods which create instances is as follows: instance <- super new. or instance <- super new initialize. The initialize method for the superclass is actually called in that class' new method and the exact words 'super initialize' should not be used but 'super new' should be used instead.
Link to this Page
- Secret Page last edited on 11 January 2007 at 2:26 am by c-71-204-43-27.hsd1.ga.comcast.net