guest_error_dialog opens a dialog with a presenter: the view carries the error
code with one focused OK button, status calls keep it running, a confirm or a
cancel input finishes it, and both update and get status report the result.
sceErrorDialogOpen builds a one-button dialog from the error code and, when the
session accepts it because a presenter exists and no other dialog is showing,
leaves the dialog running until the player confirms it or the title closes it.
With no presenter the dialog still finishes on the first UpdateStatus call. The
log line says whether the dialog was shown.
sceErrorDialogClose closes the session of a presented dialog, so the overlay and
its input capture go away, and sceErrorDialogTerminate resets the session. No
dialog is presented yet.
A dialog marked as presented stays running through sceErrorDialogUpdateStatus
until the modal dialog session reports an answer, a close or a reset, and
sceErrorDialogGetStatus reports the same. Nothing marks a dialog as presented
yet, so every dialog still finishes on the first UpdateStatus call.
libSceErrorDialog calls the modal dialog session that libSceIme hosts, and its
guest test links libSceIme and libc for the tests that follow. Nothing calls the
session yet.
error_dialog_request_tests checks the message with a positive, zero, negative
and small error code (eight uppercase hex digits) and the single OK button.
ErrorDialog::BuildRequest turns the error code of sceErrorDialogOpen into a
one-button dialog that shows the code as eight uppercase hex digits. The wording
is the host's own; nothing in it is taken from a console.
sceMsgDialogGetResult returns the player's button for a shown dialog and 1
otherwise, and a second sceMsgDialogOpen replaces a waiting dialog. Neither is
measured on a PS5.
The key, mouse and pad inputs that drive the message dialog are a host choice.
The mouse has no hit test, and Cross confirms whatever the confirm-button
setting of the console.
The button a player picks in the overlay is stored like the one a dialog without
UI picks, and sceMsgDialogGetResult, which returns it, is exported by
libSceMsgDialog.native only.
The silent stub entry said message dialogs show no UI. Only user message
dialogs with button type 0, 1, 3 or 4 are shown now; the entry lists the kinds
and the situations that still finish on the second status call.
guest_msg_dialog_native closes a shown dialog (the session closes, the status
finishes, the result stays button 1 and a second close fails), opens a second
dialog over a waiting one (the first is closed and the second shown), and
terminates a waiting dialog (the session is reset and releases the input).
sceMsgDialogOpen replaces the previous dialog of the module. A dialog that was
still waiting for an answer is now closed in the session first, so the new
dialog is shown instead of being refused and the old one does not stay on
screen holding the input.
guest_msg_dialog_native checks that a cancel input answers No in a Yes and No
dialog and OK in an OK-only dialog, that dialogs without buttons, progress bars
and system messages finish at open with button 1 and show nothing, and that a
dialog opened with no presenter finishes at open with button 1 even when focused
on No.
guest_msg_dialog_native now opens Yes and No dialogs with a presenter: the dialog
stays running with no result, the focused button is the answer after a confirm,
moving the focus first answers No, and the Yes and No dialog focused on No
answers No.
sceMsgDialogOpen builds a modal dialog request from the user message and, when
the session accepts it, leaves the dialog running until the player answers it
or the title closes it. Every other dialog, and any dialog opened with no
presenter, still finishes at sceMsgDialogOpen with button 1.
sceMsgDialogClose of a presented dialog that is still waiting closes the
session, so the overlay and its input capture go away, and sceMsgDialogTerminate
resets it. No dialog is presented yet.
sceMsgDialogGetResult reports the button id remembered from the session's answer
instead of always answering OK. The id is still 1 for every dialog that was not
presented and for one the title closed.
The status calls and sceMsgDialogGetResult now ask the modal dialog session when
a dialog is marked as presented: it stays running until the session reports an
answer, a close or a reset, then finishes and remembers the answered button id.
Nothing marks a dialog as presented yet, so every dialog still finishes at
sceMsgDialogOpen.
libSceMsgDialog.native calls the modal dialog session that libSceIme hosts, as
libSceMsgDialog does, and its guest test links libSceIme for the tests that
follow. Nothing calls the session yet.
guest_msg_dialog_tests opens dialogs through the exports. Without a presenter a
dialog finishes on the second status call and nothing is shown. With one, the
dialog is shown, stays running across status calls, refuses a second open,
finishes when answered, and a close or a terminate closes or resets the
session. A dialog without buttons, a progress bar, a system message and a
dialog the session refuses because another one is showing keep the automatic
answer.
sceMsgDialogOpen builds a modal dialog request from the user message and, when
the session accepts it because a presenter exists and no other dialog is
showing, marks the dialog as presented: it stays running until the player
answers it or the title closes it. Progress bars, system messages, dialogs
without buttons or with an unknown button type, and any dialog opened with no
presenter keep the automatic answer on the second status call. The log line
says whether the dialog was shown.
sceMsgDialogClose closes the session of a presented dialog, so the overlay and
its input capture go away, and sceMsgDialogTerminate resets the session. No
dialog is presented yet.
A dialog marked as presented stays running until the modal dialog session
reports an answer or is closed or reset, instead of finishing on the second
status call, and an answer sets the button id the dialog keeps. Nothing marks a
dialog as presented yet, so every dialog still finishes as before.
msg_dialog_request_tests checks the buttons, focus and cancel button of the four
presented button types, the decoded message, and that other button types, modes
and parameters without a user message or a message pointer are refused without
touching the output.
MsgDialog::BuildRequest turns a parsed user message with button type 0, 1, 3 or 4
into a ModalDialogRequest: OK; Yes and No; OK and Cancel; Yes and No with the
focus on No. The cancel input picks the last button. Dialogs without a message
pointer, in progress bar or system message mode, without buttons or with a
button type outside those four are not presented, so their callers keep the
automatic answer. The button id of a choice is its index plus one.
msg_dialog_text_tests checks ASCII, two-, three- and four-byte sequences,
the replacement of an invalid lead byte, a stray continuation byte, overlong
forms, an encoded surrogate, a code point past U+10FFFF and truncated or broken
sequences.
The overlay draws UTF-16 code units. MsgDialog::DecodeUtf8 converts a guest
message, replacing each byte of an invalid, overlong, truncated or surrogate
sequence and each stray continuation byte with U+FFFD, and encoding code points
past U+FFFF as surrogate pairs.
video_out_mouse_tests holds a button, opens a dialog and releases it: the title
receives one reset instead of the release, later presses and releases are
dropped, and both reach the title again once the dialog closed.
When the first button event arrives while a modal dialog captures input, MouseInput
publishes a button reset instead of it and drops every press and release until
the dialog is gone, so a button the title saw pressed before the dialog opened
does not stay pressed when its release is dropped.
video_out_mouse_tests checks that a button press made while a dialog is shown
produces no mouse data, and that presses and releases reach the title once the
dialog closed.
MouseInput drops a button press while a modal dialog captures input, so the click
that answers the dialog is not also delivered to the title. Releases still reach
it in this commit.
video_out_mouse_tests checks that the wheel reaches the title without a dialog,
that motion and wheel produce no mouse data while a dialog is shown, and that
motion is delivered again once it closed.
MouseInput drops relative motion and wheel steps while a modal dialog captures
input, so moving or scrolling to answer the dialog does not also move the title's
cursor. Button events are unchanged by this commit. video_out_mouse_tests links
libSceIme for the dialog tests that follow.
keyboard_dialog_tests holds a key, opens a dialog and releases it: the title
receives one reset instead of the release, key presses and releases made during
the dialog are dropped, and both reach the title again once it closed. A dialog
that first takes a key press resets the keys and drops the press itself.
When the first key event arrives while a modal dialog captures input, KeyboardInput
publishes a key reset instead of it and then drops every key press and release
until the dialog is gone, so a key the title saw pressed before the dialog opened
does not stay pressed when its release is dropped.
keyboard_dialog_tests builds KeyboardInput.cpp with libSceIme: a key press made
while a modal dialog is shown is not queued for the title, one made after the
dialog closed is, and a key release still is.
KeyboardInput no longer publishes a key press to libSceKeyboard while a modal dialog
captures input, so the keys that answer the dialog are not also typed into the
title. Key releases still reach it. keyboard_tests links libSceIme because it
builds KeyboardInput.cpp itself.
pad_sdl_tests opens a two-button dialog with a virtual controller: the title reads
only the neutral intercepted state while it is shown, a Cross press answers it
with the focused button, the same press stays hidden from the title until it is
released, and the next press reaches the title.
While a modal dialog captures input, the controller hand-off that already serves
an IME keyboard publishes slot 0's buttons and left stick to the dialog and
returns the neutral intercepted state to the title, and the button held when the
dialog closes stays hidden until it is released. Key presses, mouse button
presses, wheel steps and motion no longer reach the keyboard-to-pad mapping while
the dialog is shown; releases still do, so no mapped button stays pressed.
video_out_dialog_input_tests feeds synthetic SDL events to DialogInput with a
three-button dialog open: every focus key and the wheel, the confirming and
cancelling keys and buttons, repeats, events for another window, unmapped keys
and buttons, and events while no dialog is open.
DialogInput turns window events into modal dialog inputs: Left, Up, Right, Down,
Tab and Shift+Tab and the mouse wheel move the focus, Enter, the keypad Enter and
Space and a left click confirm, Escape and a right click cancel. Repeats of the
confirming and cancelling keys, other windows' events and other keys are
ignored. The presentation thread feeds it with the events it already polls for
the IME text input.
The presentation thread registers itself as a modal dialog presenter while its
window exists and withdraws on exit, so a dialog opened with no window to show
it is refused and keeps its caller's own answer. Before each flip it reads the
pending dialog and passes it to the driver, or clears it. The IME keyboard keeps
the overlay: while it is shown or captures the keyboard or the pad, the dialog
is not read.
The presentation drew the system keyboard from SystemOverlayView and laid it out
inside its own recording. It now asks SystemOverlayLayout for the system panel
at the swapchain extent, which is already validated by then, and records
whichever of the keyboard and the dialog is set through the same overlay pass
and layout transitions. Presentations with neither set are unchanged.
agc_keyboard_overlay_tests now checks the message wrapping (column limit, long
words, line breaks, surrogate pairs, the dots on an overlong message), the
layout of one to three buttons at four target sizes (inside the screen, centred,
buttons in order and not overlapping, the accent border on the focused button),
a long message and a narrow target, the refusal of zero or four buttons and of
an empty target, and the storage of the dialog with the keyboard taking the
overlay from it.
MarcZX10