Dialogizer runs in a "blocking" manner; Decker won't process click[] events or other interactions with ordinary widgets while Dialogizer is active, so you wouldn't be able to furnish that kind of functionality with ordinary buttons on a card.
You could, however, use the animate[] event that Dialogizer continuously emits while dialog boxes are open, in combination with the Pointer interface- which provides live-updating access to the state of the user's pointing device- to explicitly detect clicks on extra buttons.
If pointer.start and pointer.pos are within a given rectangle and pointer.up is truthy, you'll know the "button" corresponding to that rectangle was clicked. You could even physically have buttons with click event handlers on the card if you want. Presuming a button called "menu", you might have an animate[] script something like:
on within pos rect do min(pos>rect.pos)&(pos<rect.pos+rect.size) end on animate do if within[pointer.start menu]&within[pointer.pos menu]&pointer.up menu.event.click end end
Make sense?
Note that this technique works best when a dd.ask[] dialog is open; ordinary dd.say[] dialogs will automatically advance for any pointer click irrespective of what else happens in animate[]. If you really want fine-grained control here you might need to make minor alterations to the dialogizer module itself. I'll ponder this kind of use-case and possibly make some enhancements to the module in the future.