Christoph Reichenbach wrote:
>
> Hi,
>
> > Okay, here's a quick run-down of the SetMenu call:
> [foo: The menu item attribute to modify]
> > 0x6D - Said spec (Yes, you were right!)
> > 0x6E - Item text
> > 0x6F - Key text
0x6F is the scan code, not the key text, BTW. AddMenu() derives it
automagically from the given text.
> > 0x70 - Enabled flag
>
> Are disabled menu entries grayed out or removed in Sierra SCI?
Grayed.
> > 0x71 - Tag value
> > I don't really know about 0x71, but the only thing I can think of is
> > that it is used internally to maintain the state of, for instance, Sound
> > on/off - that's the only place I've seen it used.
>
> Is there any kernel space handling of the tag value, or is it just read
> from and written to from script space?
It's all in kernel space, though the kernel uses the heap to store the
menu structures. This doesn't mean we have to though - the scripts can't
access them.
>
> > The SelectMenu() takes an event record as a paramater, plus an optional
> > boolean value which apparently has something to do with sound being
> > paused or not (It's probably there because SelectMenu() is used in the
> > strange manner seen in Hoyle).
>
> Hmm. What does it return? Does it modify the event? Also, is menu
> navigation handled from within the interpreter (i.e., if ESC is pressed,
> does the interpreter take complete control over the system?)
See the attached text.
> > > So they remove the menus, too?
> >
> > Yes, they would have to do that.
>
> Do they restart the game to do this?
That is my guess too, but I can't say for sure right now.
Lars
-- Attached file included as plaintext by Listar --
-- File: menu.txt
The MenuSelect() function is invoked with an event and an optional boolean
value which has something to do with sound being paused or not.
The event may be of almost any type:
* a click in the menu port causes the appropriate script to call
MenuSelect(), passing that event.
* an unhandled said event will be passed to MenuSelect().
* likewise for unhandled keyboard events.
* The special event type 0x100 (undescribed in the Event section)
also causes the menu to appear.
Incoming events are first checked if they are claimed and if they have a
wrong type. In this case, MenuSelect() returns -1.
Said and keyboard events are checked against each menu item for a match.
If one is found, the event is claimed and SelectMenu returns the position
of the "chosen" menu item. ESCAPE presses or mouse clicks cause the
interpreter to take total control, waiting for the user to take further
action.
MenuSelect() returns a position value similar to the ones used by SetMenu()
if a menu item was chosen. If not, it returns 0.
