HandMorph ShowEvents

Is there a reason that the HandMorph class>>showEvents: feature draws directly on the screen instead of opening a Morph? Am I missing a use case, or would it be okay to turn this into a proper Morph?

On 22-01-2014, at 10:24 PM, Sean DeNigris <[hidden email]> wrote:

> Is there a reason that the HandMorph class>>showEvents: feature draws directly on the screen instead of opening a Morph? Am I missing a use case, or would it be okay to turn this into a proper Morph?
>
If you’re trying to track events without causing extra events that you track causing extra events…. you need to display them without using the very event system that you are tracking. Otherwise a morph would be fine.

It is probably reasonable to write an EventDisplayingMorph that doesn’t confuse the issue by filtering its own events out. Indeed, one that filters out events in various ways would be quite useful. You need to be especially careful to find ways to not disturb the sequence of events; simply adding a morph makes for potentially different execution paths and if you’re wanting to find out what is happening it’s a bit like writing a debugger and having to take care that it doesn’t become the problem.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RDLI: Rotate Disk Left Immediate