I have both a speech and text Prompt in a Scene and in the Scene that is transitioned to. The separate speech prompts are spoken with just a brief break between them. The text prompts are displayed as sentences in the same paragraph. Ideally, I would like a pause between the speech prompts, and a new paragraph between the text prompts.
How might I do this?
Scenes represent logical separations - not necessarily discrete UX elements. Each scene can put one or more prompts into the prompt queues (there are multiple queues - more on that in a moment). They're taking out of each queue in the order they were put in, unless you clear the queue before you add another item. However - the system treats all of the prompts in the queue as building towards a single reply. So there is no automatic way to visually or audibly separate them.
However, there are a couple of tricks you can use, with caveats.
Audibly, you can add a brief pause using the SSML break tag. So you might set your On Entry "speech" prompt response to something like:
<break time="250ms"/> Welcome to another scene.
However, splitting the response visually is more difficult. There is no formatting allowed in the text response. There are a couple of tricks you may be able to try, however, but they're not guaranteed to work on all visual displays.
The easiest might be to send the first part of your response as a firstSimple prompt, and the second part in a lastSimple prompt. Typically you'd use the first to give results from what the user might have just done, and the last to prompt them for further action, but they may be rendered as separate "bubbles" on some platforms.
You could also consider a rich response card. You an format the contents of the card a little, but you can't use two separate scenes to fill the contents of a single card. On some platforms, you can only show one card.
Related
I want to use an editor to display a log from a program, I just need a very basic text field:
With a vertical scrollbar
With a contextual menu for copy/paste
Prevent the user from changing the text
In order to activate the copy/paste menu, I use the class racket:text% from framework rather than the basic one.
How to prevent the user from changing the text?
I read the documentation, as far as I understand the closest thing I found is lock method:
https://docs.racket-lang.org/gui/editor___.html?q=lock#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._editor~3c~25~3e%29._lock%29%29
But it is not convenient, as it also prevent my program to write the data.
I also find get-read-write? but cannot find set-read-write.
Use the lock method, and just unlock the editor around any modifications that you want to do. You may find it useful to write a call-with-unlock helper function or with-unlock macro.
If you do your updates from the eventspace's handler thread (and you probably should; use queue-callback if they originate from another thread), then as long as you re-lock the editor at the end of an update, the user will never be able to interact with the unlocked editor.
I'm trying to use MATLAB to create a stand-alone application for an interactive fiction game (where the player is presented with a text prompt and responds by entering text, e.g. "You are being choked by a creepy squid. >> " "Stab squid" "The squid dies, leaving behind an inky pile of gold. >>" etc.).
When I compile the game and install it, everything works smoothly, but there's nowhere for the game's prompts to appear, and nowhere for the user to type in responses.
Who has a good solution for this? Do I use a GUI with text boxes, or is there a way just to have a text scroll with user inputs like this? The latter would be preferable.
Thanks!
I have to maintain a part of an old Windows VB6 project (so, don't tell me to migrate-it to VB.NET). This program embeds the well known webbrowser control (IE) in which it loads local HTML files (containing different stats, but doesn't matter). Knowing we don't want any scroll bar in the web browser view (even if HTML page is longer than the webbrowser window, we just need to see what it's on top), we manage DOM on DocumentComplete event like this :
Private Sub wb_DocumentComplete(ByVal pDisp As Object, URL As Variant)
wb.Document.documentElement.Style.overflow = "hidden"
ProcessWithDStats
End Sub
All sounds right and the vertical scrollbar well disappear, but now, I need to add some stuff in the ProcessWithDStats sub (a big sub calling a lot of functions) which need to be sure the previous DOM operation is totally completed (I mean : scrollbar hidden and it's content re-justified accordingly to this new width w/o scrollbar).
So, how to do ?
At this time, ProcessWithDStats is executed before DOM management really finish to be rendered !
Until now, here are my attempts :
I've tried to add a scrollbar testing (comparing doc width and browser client area one) between the two lines, but it doesn't work : test is OK, but reflow of text (because of this change of width when scrollbar disappear) has not enough time for being applied before ProcessWithDStats is engaged.
I've tried to Sleep(), but it locks entire program (webbrowser rendering included)
Well is there a way to wait for real application of the given DOM management in this WebBrowser control ?
I mean something like :
Do
Doevents
Loop Until [DOM modification and rendering completed]
you need to do this... at the very least.
Do
Sleep 100
Doevents
Loop Until wb.Busy = False And wb.ReadyState = 4
On your version the .Busy may be called .IsBusy but are the same thing.
Also, there are additional things you should do if you want to truely know if a browser is done loading, read some of my previous answers if you want to know more, or need more accuracy than the above, but what i have included for you is for sure a much better solution than you currently have. Let me know if you need it to work on 100% of websites or just a select few, if a select few than this simple method may be enough.
Let me know hwo it goes anyway, cheers.
It seems for me that best place for validation of user input is in focus-out-event handler of entry type widgets (but this is only my thinking). I try to return TRUE from focus-out-event with idea that this will avoid to transfer focus to next control and keep focus on current widget, but this is not OK (not work as needed).
Which is proper way to suppress of transfering focus to next control in case when validation don't pass and where to put validation code on such widgets (gtkEntry, gtkSpinButton, etc) to be usable with signals invoked with both - mouse and keyboard actions?
That is hardly a good idea... Focus is (should be) always owned by the user. That is, the users should be able to move the focus wherever they see fit. If you try to direct the focus, or prevent moving it, based on any logic you can imagine, you will likely frustrate them.
It will surely frustrate me! Say for example that I wrote a wrong data in a box, and then I say, "hey, that's wrong! I want to select that data over there, copy it and paste it here". But I cannot do that because the program will not let me leave the box where I am now without writing an acceptable data. I have to delete the wrong data and enter something... just not good.
The best way to validate the user entry is when you actually do something with it. Either when you save it or when you make it effective. Then you can even make a pop-up saying that there is an error, and when it is close, move the focus to the first error.
If you feel that the user can benefit from an early warning that he is doing wrong, you can use colors (paint the box yellow/red if there is an error), or add a small error icon next to the box. That is waaaay less disruptive than moving the focus around.
I'm trying to implement a kind of "guided typing" widget for data entry, in which the user's text entry is highly controlled and filtered. When the user types a particular character I need to intercept and filter it before displaying it in the widget. Imagine if
you will, a Unix shell embedded as a webapp; that's the kind of thing I'm trying to implement. I've tried two approaches.
In the first, I extend a TextArea, and add a KeyPressHandler to filter the characters. This works, but the browser-provided spelling correction is totally inappropriate, and I don't see how to turn it off. I've tried:
DOM.setElementProperty(textArea.getElement(),
"spellcheck", "false");
But that seems to have no effect- I still get the red underlines over
"typos".
In the second approach I use a FocusWidget to get KeyPress events, and a separate Label or HTML widget to present the filtered characters back to the user. This avoids the spelling correction issue, but since the FocusWidget is not a TextArea, the browser tends to intercept certain typed characters for internal use; e.g. FireFox will use the "/" character to begin a "Quick Find" on the page, and hitting Backspace will load the previous web page.
Is there a better way to accomplish what I'm trying to do?
You might just be able to use event.preventDefault() on your keypress events to avoid these browser behaviors. Otherwise, maybe a hybrid of the two approaches? Have a hidden TextArea with focus, accepting key events, and then post the typed characters to a separate Label.
There is no specific GWT method on TextBox for this, but this simple line of
GWT code fixes the problem for Chrome (for other browsers, YMMV - it may depend upon how completely they implement HTML5) by setting an attribute on the underlying input element:
myTextBox.getElement().setAttribute("spellCheck", "false");
Perhaps this attribute is a relatively new feature.