Subject: mailstation signals & events

From: "Cyrano Jones" <cyranojones_lalp@...>
Date: Tue, 01 Aug 2006 01:33:57 -0000

I don't really know what these should be called.  I
named the "event type" field as "signal" in my notes.
There is a queue that the events and such are placed in.
At first I was calling it "msgQ", when I didn't have any 
idea what the messages were.

When I realized some of them were keyboard input, I
changed it to "eventQ".  But then I noticed some of the
items did not match my idea of "event", such as signal #0d
which means "draw yourself".  Many of the signals are what
I would call "commands" rather than "events".

These are the signals that I have figured out so far.
Some are just guesses, based on what *seemed* to be
happening where I saw them used.  (I am quite sure that
01 thru 0d are correct.)  These values are passed
to your apps "handleevent" function, in the "signal" param.

;; signals:
01  - init app
02 - ???
03 - go prev
04 - go main
05 - timer
06 - keydown, top keyrow  (maybe should call it buttondown???)
07 - keyup, top keyrow
08 - keydown, normal key
09 - keyup, normal key
0A - menu event???
0B
0C
0d - draw 
0e - create file???  widget 4
0f - close file???  widget 4.  also sent before setting widget as
avail. (removing widget)
10 - init????  or maybe to focus???
11 -  clean up???? or maybe to un-focus???
13  -  check dataflash??? 19:7b88
14  - exit???  
15  -
16  - for "change font"???
56 - download email??? [19:7f4c]

--CJ

---

From: "John R." <jhoger@...>
Date: Mon, 31 Jul 2006 22:19:26 -0700

> named the "event type" field as "signal" in my notes.

Great detective work.

I think you had it right in the first place: looks like a garden
variety message queue. Having all events placed on the queue allows a
simple idle loop where your app is just a big switch case in which you
process the next message from the queue. Most GUI programs are
architected this way: your application is associated with a window
which is associated with a message queue. All mouse and keyboard
events typically go into the queue; the same for paint events, button
clicks, etc. It looks like init/cleanup (lifecycle) also go through
the event queue.

The reason for a message queue like this is typically to keep
interrupt latency low (post to queue and process messages on idle
and/or bottom half of interrupt handler, i.e. run only when it is
safe). It also facilitates cooperative multitasking since the "kernel"
can easily switch between processing the queue for one application to
another without disruption.

--  John.