See ddemo.zip from this folder for an example of using this. DialogInit: 4C06h: Initializes the dialog context. Inputs: HL is address of parser callback for any numbers entered. A is page of parser callback for any numbers entered (must be non-zero). This installs a RawKey hook which resets bits 1 and 2 of iy+28h, and sets bit 1 if a context key was presssed. There appears to be no "DialogKill", so make sure you uninstall its RawKey hook. StartDialog: 4C03h: Stores zero to (8033h), resets key override, draws dialog, and it starts waiting for a keypress. Inputs: ramCode: menu structure. RestartDialog: 4D3Eh: Stores A to (8033h), resets key override, draws dialog, and it starts waiting for a keypress. Inputs: ramCode: menu structure. A: value to store to (8033h) (I'm really not sure what this is, it seems irrelevant). StartDialog_Override: 4C21h: Calls SetDialogOverride, then StartDialog. DialogStartGetKey: 4C1Eh: Waits for a dialog keypress and then acts on it. This doesn't return until you press [2nd]+[QUIT]. You pass the address of a table in HL...if you pass a bID=3 table, it just returns. And the dialog has presumably already been displayed. It doesn't use the table for anything other than this, which is odd. ForceDialogKeypress: 4C1Bh: Forces a key to be pressed on dialog menu. It doesn't return and waits for another keypress. Inputs: A is keypress (and potentially (keyExtend)). GetDialogNumOP1: 4C09h: Gets a floating-point number from the dialog context to OP1. Inputs: A is zero-based index of number. Outputs: OP1 is number. SetDialogNumOP1: 4C0Ch: Sets a floating-point number in the dialog context to the value in OP1. Inputs: OP1 is number. Outputs: number stored. GetDialogNumHL: 4C0Fh: Gets the address of a floating-point number from the dialog context. Inputs: A is zero-based index of number. Outputs: HL points to number. SetDialogKeyOverride: 4C15h: Sets a callback routine to handle keypresses. Inputs: HL is address of callback routine. A is page of callback routine. Keys kSolveRoot (SOLVE EDITOR), kStatEd (list editor), and kInfStat (inferential statistic editor) are not passed to this routine. It is up to you to handle everything else, including [UP], [DOWN], [ENTER], and [2nd]+[QUIT]. Bit 1,(iy+28h) set is probably an indicator to this routine that the user attempted to press a context key. ResDialogKeyOverride: 4C18h: Disables the callback routine to handle keypresses. CallDialogCallback: 4C24h: Calls the dialog callback routine. This apparently is never used by the OS. SetDialogCallback: 4C27h: Sets a callback routine which can be called by you at any point. Inputs: HL is address of callback routine. A is page of callback routine. ResDialogCallback: 4C2Ah: Disables the dialog callback routine. CopyDialogNum: 4C2Dh: Copies one floating-point number from the dialog context to another. Inputs: B is zero-based index of source number. C is zero-based index of destination number. Outputs: Number C overwritten by number B. DialogKeyHook: 4FE1h: This is the key hook used by the dialog routines. It actually runs "add a,e." *sigh* To start this context, load a menu structure* to ramCode, BCALL DialogInit and then BCALL StartDialog. You choose whether the run indicator is displayed and whether contexts are allowed (appAllowContext,(iy+appFlags)). It is imperative that (cxCurApp) be one of the allowed values (use 58h=kExtApps). If kSolveRoot (SOLVE EDITOR), kStatEd (list editor), or kInfStat (inferential statistic editor) are pressed, the entire screen is redrawn and then the parser callback is called with A=1. If [UP], [DOWN], or [ENTER] are pressed, any entered number is parsed*. If [2nd]+[QUIT] is pressed, whatever has been entered will be parsed* (no errors thrown nor anything displayed) to OP1, the previous context vectors are restored, SP is restored from (spSave), and the run indicator is turned off. * Parsing the number: ParseInp is called on the data entered, and OP1 is checked to make sure it is REAL (error thrown if not (and this may return to the edit)). A=0 is passed to the parser callback. B (8006h) is the index into a prompt structure (probably bID = 3). It is expected to return a value in A. Return zero to display the current line (string and number). It also copies the number in OP1 to the spot bNumIndex points to. If 0,(iy+2Eh) is set, the rest of the line is not erased (then NewLine). * Menu structure: Load as many of these structures, one after the other (zero-terminated), to ramCode in the order you want it displayed. Store the length-indexed strings in RAM as well (right after this structure, in ramCode). bID can be from 1-6: bID = 1: display string (cannot select). bID = 2: display highlightable choices (as in the MODE context). A byte table at 8009h has to do with what is selected here. bID = 3: display prompt string and number. bID = 4: display highlightable string. bID = 5: display menu number (ex. "1:") and prompt string. bID = 6: hidden, skip displaying this entry. Prompt structure when bID = 1: DB bID ; DB bNumChoices ;probably always 1 DB bUnknown ; DW wStringOffset ;offset from start of ramCode Prompt structure when bID = 2: DB bID ; DB bNumChoices ; DB bUnknown ;I think this is the number of rows to skip for next item, or something DW wStringOffset ;offset from start of ramCode / DB bColumn ;column to display string (this is probably ignored) \ There are bNumChoices of these. Prompt structure when bID = 3: DB bID ; DB bNumChoices ;probably always 1 DB bNumIndex ; DW wStringOffset ;offset from start of ramCode Prompt structure when bID = 4: DB bID ; DB bNumChoices ;probably always 1 DB bUnknown ; DW wStringOffset ;offset from start of ramCode Prompt structure when bID = 5: DB bID ; DB bNumEntries ;probably always 1 DB bMenuItemNum ;1 for "1:", 2 for "2:", etc. DW wStringOffset ;offset from start of ramCode Prompt structure when bID = 6: DB bID ; DB bNumChoices ; DB bUnknown ; DW wStringOffset ;offset from start of ramCode < There are bNumChoices of these. 8038h: bNumIndex above is an offset into a list of floating-point numbers: DB 00h,80h,00h,00h,00h,00h,00h,00h,00h