Roku Developer Program

[scottgarner]

I'm trying to provide a mechanism for a user to add/edit more than a trivial amount of text. Using the Keyboard (and hence the TextEditBox) object, if the amount of text exceeds the visible window of the control holding the text, then ellipses are displayed, and the text does not scroll to follow the cursor position. Text that is added using the keyboard does apparently modify the .text value, but since this is happening invisibly, it only creates confusion.

First, is there a way to change this control to behave as one would expect it to? i.e. when the cursor reaches the furthest-right-most bit of the TextEditBox, can the ellipses be disabled, and can the whole line of the text be scrolled to the left while the user is either adding text, or navigating existing text with the directional arrows?

Second, if there is no solution using Keyboard/TextEditBox, what is the alternative? I know there's a way, because I have someone else's channel that uses a text controller with this standard behavior. Is their text control some kind of home-rolled solution they made, and if so, how? I'm not averse to making my own controls, but I don't know how I'd go about cursor navigation through something like a Label object.

[scottgarner]

Because I don't want to use the deprecated roKeyboardScreen, how am I supposed to accomplish this functionality?

[destruk]

........

[destruk]

To get rid of the ellipses ... you'd probably want to set keyboarddialog.keyboard.showtexteditbox=false and then, as the sdk page says, use a different way to display the data entered.  Possibly with an overlaid label field to update where the default texteditbox would have been, or redesign/customize the keyboard itself.

[destruk]

hmm...It will need to be a custom created keyboard entry screen.  Because as long as you're using the built-in widget for it, you'll be stuck with the "..." display.
The maximum length of a working email address is 254 characters (per wikipedia) - and the roKeyboardScreen works the way you describe scrolling the entered text to the left, but it doesn't do that for the scenegraph version.

[destruk]

Alright - so this works.
Double up the variables and routines.  Have the user enter a letter or number for the keyboard with their remote and add that value to both variables.
Then retain the one you want to use, and truncate the second copy and kick it back to the screen - something like m.fieldText2.text=Right(newText,50)

It's confusing but it works.
To explain this better we'll go slow -
Create your keyboard screen.
Set up your variables like you are using now - which works to enter characters into the field.
Double the field you are using for the entry string in the xml -
<field id="fieldText" type="string" value="" onChange="setFieldText" />
<field id="fieldText2" type="string" value="" onChange="setFieldText2" />

Double the child in the xml -
<Label id="fieldText" color="0x101010FF" font="font:MediumBoldSystemFont"
horizAlign="left" vertAlign="center" translation="[4,0]" />
<Label id="fieldText2" color="0x101010FF" font="font:MediumBoldSystemFont"
horizAlign="left" vertAlign="center" translation="[4,0]" />

In the brs script double the routine callback -
m.fieldText=m.top.findNode("fieldText")
m.fieldText2=m.top.findNode("fieldText2")

Then when the user selects a key, add the key value to the main string, and add the key value to the copied string, but only display back the right characters of the second string.

[destruk]

This is ultra-simplified but it works too --

Sub Main()
	showChannelSGScreen()
End Sub

Sub showChannelSGScreen()
	screen=CreateObject("roSGScreen")
	m.port=CreateObject("roMessagePort")
	screen.setMessagePort(m.port)
	scene=screen.CreateScene("KeyboardDialogExample")
	screen.show()
	While(TRUE)
		msg=wait(0,m.port)
		msgType=type(msg)
		If msgType="roSGScreenEvent"
			If msg.isScreenClosed() Return
		End If
	End While
End Sub

<?xml version="1.0" encoding="utf-8" ?>
<!--********** Copyright 2016 Roku Corp.  All Rights Reserved. **********-->

<component name="KeyboardDialogExample" extends="Scene">
	<script type="text/brightscript">
		<![CDATA[
			Sub init()
				m.top.backgroundURI="pkg:/images/rsgde_bg_hd.jpg"
				keyboarddialog=createObject("roSGNode","KeyboardDialog")
				keyboarddialog.backgroundUri="pkg:/images/rsgde_dlg_bg_hd.9.png"
				keyboarddialog.title="Example Keyboard Dialog"
				keyboarddialog.buttons=["OK","Cancel"]
				keyboarddialog.observeField("text","dbText")
				keyboarddialog.observeField("buttonSelected","confirmSelection")
				m.top.dialog=keyboarddialog
				m.cText="" 'initialize variable for this component
				m.cFocused=0 'initialize variable
				m.top.setFocus(TRUE)
			End Sub
			
			Sub dbText()
				Print"Text: "+m.top.dialog.text
				m.cText=m.cText+right(m.top.dialog.text,1) 'Grab the right character of the dialog text
				If Len(m.top.dialog.text)>40 m.top.dialog.text=Right(m.top.dialog.text,40) 'truncate value for display with a limit of 40 characters
				Print"CTEXT:"+m.cText 'Print copied value to screen
			End Sub
			
			Sub confirmSelection()
				m.cFocused=m.top.dialog.buttonFocused
				If m.cFocused=0
					Print"OK"
					Print"Entry complete, use cText value of: "+m.cText
				End If
				If m.cFocused=1 Print"Cancel"
			End Sub
		]]>
	</script>
</component>

[destruk]

Of course you should add a check to see if the user is pressing delete or another special key, or compare the current value's characters to the cText value you're going to use, but you get the idea how to get rid of the "...".

Another stupid rendering issue with the generic keyboard widget - if the highlight box is on the left side and you press left, it ANIMATES all the way to the right instead of popping on the right.  Is it idiocy or just simple laziness for the firmware?  For the most control, use a custom keyboard instead of the stupid widget.

[scottgarner]

destruk, thank you so much for your answers! Yes, in order to finish the control so that all text navigation makes sense, I had to add a lot of stuff to handle forward/backward carat, and also backspace. That meant I had to map all the keys on the virtual keyboard, and then only worry about 'OK' key presses when those certain buttons were focused. Had to do things to make sure my buffered text matched the screen window, etc. But you sent me off in the right direction. Thanks, again. Really.

[destruk]

It's a lot more work than it should be Scott.  To replace the roKeyboardScreen which worked fine as it was with this, well...at least it can be worked around.