| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 280.1 | ... | LEDS::ACCIARDI | | Wed Jan 28 1987 15:49 | 3 |
| RSLClock runs at a very high priority. You might want to run
'ChangeTaskPri' in your startup sequence.
|
| 280.2 | Wont Work | TLE::RMEYERS | Randy Meyers | Wed Jan 28 1987 16:14 | 7 |
| Re .1:
>You might want to run 'ChangeTaskPri' in your startup sequence.
That probably wont work. The clock program probably makes a library
call to set its priority. If so, then it doesn't matter what priority
you start it with, it will end up at priority 20 (or whatever).
|
| 280.3 | Strange occurances on 1.2 | KIRK::LONG | | Wed Jan 28 1987 16:27 | 6 |
| Something else I noticed when invoking RSLClock from Workbench.
I started playing with how many of these things I could get
running at once and somewhere over 14 and before I ran out of
memory, I would get the random disappearance of some of the
earlier clocks I had started. Anybody got a guess on what is
happening to the multitasking?
|
| 280.4 | AutoAbort Feature | AUTHOR::MACDONALD | | Wed Jan 28 1987 18:06 | 9 |
|
Ahhh .. remember, RSLClock automatically POPS to the front screen.
Could be some problem there with popping. Also, the task will
automatically abort when you reach a preset amount of remaining
memory (I think the feault is 25K). So, naturally, as you reach
that limit by starting up more RSLClocks, the first ones will start
aborting!
Paul
|
| 280.5 | Got it | AUTHOR::MACDONALD | | Thu Jan 29 1987 08:54 | 10 |
| Priority was the problem. The Clock that comes with Workbench has
a priority of 0, so it really doesn't interfere with anything. The
RSLClock has a default priority of 20, which is the source of the
problem I was having. Using a neat Gizmoz program called SetPriority,
I reset the Task to priority 0. If you do happen to reset the priority,
do so AFTER you have selected whatever RSLClock menu options you
intend to use. Apparently, choosing any menu options resets the
priority back to 20.
Paul
|
| 280.6 | This is a bug in 1.2 | CGFSV1::DREW | Steve Drew | Thu Jan 29 1987 11:01 | 16 |
| You may of fixed the slow mouse problem with the priority, but if
RSLclock does automatic window-to-fronts then your machine is still
very likely to lock up on you, most likely in basic or moveing icons.
There is a definate bug in 1.2 when two windows seem to do a window-
to-front at the same time.
I am able to crash my machine (it freezes) by running smallclock
and making it do a window-to-front once per second. Then all I have
to do is move a icon and it's gone. Or just call up the list window
in basic. This bug was there in 1.1 I believe but did'nt show up
with the icon movement but did with basic.
Of course if the clock program does a window-to-front every 10 seconds
then the chances of a crash are much less.
(Me I just disabled the window-to-front in the clock program.)
Steve.
|
| 280.7 | Sprite Clock | AUTHOR::MACDONALD | | Thu Jan 29 1987 14:04 | 3 |
| The SpriteClock program seems to work flawlessly though.
Paul
|