[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: trace of Self changes
Interesting--what about input? Timing-dependencies?
that sort of thing??
>While thinking about the consequences of my proposal to use shift-click
>to get references to objects I got the idea that it would be useful
>to write all changes to the Self world to a log file so you can later
>use this information to create module information, return to earlier stages
>by using only the part before some error occured, ...
>To do this you have to store all top messages send by the user to objects,
>i.e. only that from an evaluator or triggered by a menu or a button,
>not the resulting messages.
>For this you need the references to the receiver objects of all the top
>Here you can use the global names of the well-known objects.
>The problem is how to refer to not-well-known objects.
>As you can only send messages to those not-well-known objects which are
>in your GUI you can maintain symbolic references to all those objects
>e.g in an appropriate dictionary or in that one already used by the GUI system.
>In order to be independent from the absolut value of the object reference you
>have to use symbolic references in the log file.
>Every time you show an object (morph or arbitrary outliner) you register
>under an unique symbolic reference
>1) the message that led to this grafical appearance
>2) the concrete object-reference(s) of the created morph object (and of
>the object that
>receives messages through this morph object in the case of an outliner).
>You have to distinguish between messages sent to the outliner
>and messages sent to the object that the outliner stands for.
>I think if you enlarge the functionality of the evaluator or other
>GUI specific stuff that starts sending of messages to the object behind it
>you get it very easy.
>When you dismiss the grafical object than you remove the object-references
>of both outliner and reflectee and they may rest in peace if not longer needed.
>Pointer grabbing and argument picking (great word!) make no problems
>because the referenced object are handled in absolute the same way as
>the receiver objects.