[comp.lang.smalltalk] ST/V clockEvent: -- Where?

jhugart@umaxc.weeg.uiowa.edu (Jacob Hugart) (03/19/91)

Headache!

   I'm using Smalltalk/V Mac 1.1, and there appears to be a significant
documentation problem.  I am interested in changing the contents of a
GraphPane every given number of clock ticks, for an analog clock face.  The
manual says there is a method called clockEvent: anInteger (pp. 363) which
will "Perform the clockEvent method in the model.  anInteger is the
cumulative clock interrupts since last clock event."

   Of course, this method does not exist in my class hierarchy.  So I looked
up the method in the method index, and it told me that DemoClass and
InputEvent also implement this method.  Only InputEvent does, but the
documentation for that class (pp. 371) doesn't list the method.

   To what must I resort in order to get this continual message sending?
--
Jacob Hugart  <jhugart@umaxc.weeg.uiowa.edu>
Database Consulting Group, Weeg Computing Center, University of Iowa

cooper@netcom.COM (Ken Cooper) (03/21/91)

Jacob,

>>
>>   I'm using Smalltalk/V Mac 1.1, and there appears to be a significant
>>   documentation problem.  I am interested in changing the contents of a
>>   GraphPane every given number of clock ticks, for an analog clock face.  The
>>   manual says there is a method called clockEvent: anInteger (pp. 363) which
>>   will "Perform the clockEvent method in the model.  anInteger is the
>>   cumulative clock interrupts since last clock event."

>>   Of course, this method does not exist in my class hierarchy.  So I looked
>>   up the method in the method index, and it told me that DemoClass and
>>   InputEvent also implement this method.  Only InputEvent does, but the
>>   documentation for that class (pp. 371) doesn't list the method.

>>   To what must I resort in order to get this continual message sending?

We had the same problem when implementing the blinking cursor in the text 
editor of our Widgets/V Mac product.  Before I continue with this description,
I have to warn you that there is a bug in Digitalk's code that will cause
timer interrupts to potentially overflow the stack, and cause your virtual
machine to crash.  It only happens under certain conditions, such as long,
uninterrupted processes like compressSources, but it's still not a very nice
feature.

Here's the process:  first, you need to have clock events occur.  To get
this to happen, you have to set up timer interrupts, by sending the following
message to the Time class:

    Time clockTickPeriod: milliseconds.

Note that this is the culprit for the bug I mentioned above.  To turn the
clock interrupt off, you send the message 

    Time clockTicksOff.

Once you've set up the interrupts, the input queue will start receiving 
clock events at the interval given in milliseconds.  To actually *do* 
anything with them, you have to deal with the input queue.  As I recall, 
the active dispatcher will automatically send the #clockEvent: message to 
its model if the model implements it.  Note that this is only sent to the 
active dispatcher...

Hope this helps,

Ken Cooper
Acumen Software