From: "Cyrano Jones" <cyranojones_lalp@...>
Jul 31, 2006
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 ar=
e 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 ma=
tch my idea of "event", such as signal #0d
which means "draw yourself". Ma=
ny of the signals are what
I would call "commands" rather than "events".
T=
hese 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
0=
2 - ???
03 - go prev
04 - go main
05 - timer
06 - keydown, top keyrow (may=
be should call it buttondown???)
07 - keyup, top keyrow
08 - keydown, norma=
l key
09 - keyup, normal key
0A - menu event???
0B
0C
0d - draw
0e - creat=
e 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
1=
4 - exit???
15 -
16 - for "change font"???
56 - download email??? [19:=
7f4c]
From: "John R." <jhoger@...>
Aug 1, 2006
On 7/31/06, Cyrano Jones <cyranojones_lalp@...> wrote:
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.