Is there a way for the text input cursor to automatically be placed in the text input box once a passage loads (so you don't have to click on the text input box to display the text input cursor)? Same way that Google homepage loads the text input cursor upon loading of their page.
Thank You
InsertCoin25
Comments
Preface: In SugarCube, the input element macros give each element a unique ID. Generally, the ID is the name of the macro plus the normalized name of the $variable (normalized here largely means sans the
$
and all lowercase); the <<radiobutton>> macro goes a little farther and appends a group ID as well (since radiobuttons are created in groups). Anyway, what this means is that you should be able to target any input element which was created with the macros easily via its ID. If you're creating your input element by hand, then I'll assume you know how to target it.For example, say that the passage which contained your input macros was titled "
Get Names
" and that it looked something like this: The created selectors for the input elements would be "#textbox-pcname
" and "#textbox-dogname
", respectively.Then to autofocus the
$pcName
textbox, you would add something like the following to thePassageDone
special passage: Make sense?<<if passage() is "Start">>\ --- in a PassageReady, but did not work. Would this render the script before the Start passage loads? If not is there a way to use this script for the Start passage?
Other than this little quirk everything works perfectly!! Thanks again TheMadExile.
InsertCoin25
I'm working in 1.3.5. because I need some specific text input functionality which was removed in later versions.
I have a passage named "begin" with the following content: My PassageDone looks like this: Does PassageDone need a tag or anything like that? I just have a passage literally named "PassageDone".
This isn't giving the focus to the text input field however. Any help would be MUCH appreciated as I know nothing about Javascript so this is pretty hard to debug!
The PassageDone special passage is a feature of the SugarCube story format and does not exist in Sugarcane which I believe you are using by your usage of the <<textinput>> macro.
I believe I mentioned that it should go in the
PassageDone
special passage, notPassageReady
. The element needs to be on the page before it can be focused, and only thePassageDone
special passage is run at the appropriate time (i.e. after the element has been placed on the page).Here's a quote, originally from SugarCube FAQ (reply #23), on how the order of execution plays out during passage rendering in SugarCube:
They and the
prerender
/postrender
task objects are similar in that they both allow you to do dynamic things around the display of a passage (by navigation, the<<display>>
macro does not trigger these). The main differences being:
The order of execution typically looks something like this:PassageReady
/PassageDone
are passages, whileprerender
/postrender
are JavaScript objects used as repositories of functions (which I generally refer to as tasks).PassageReady
/PassageDone
are executed before/after the passage is rendered, while the functions within theprerender
/postrender
objects are called during passage render, just before/after the passage content is generated.[list type=decimal]
State history updated for the incoming passage
PassageReady
executed, if not rendering "offscreen
"Incoming passage is rendered
[list type=upper-alpha]
prerender
tasks calledIncoming passage content generated
postrender
tasks calledTransition from outgoing passage to incoming passage, if not rendering "
offscreen
"PassageDone
executed, if not rendering "offscreen
"Update the UI elements, if not rendering "
offscreen
"Now you know. And knowing is half the wait, my '80s is showing.
I'm unsure if the
<<textinput>>
macro you're using in Sugarcane provides a convenient ID for selection, so your selector might have to change. The big issue, however, is that the vanilla story formats have no analog to thePassageDone
special passage (and you're using an ancient and broken version anyway).Your best bet will probably be to wrap the
<History>.display()
method. For example: (goes in ascript
tagged passage)Yep, I'm aware that I'm using a version that is both old and broken! The reason is that my game needs "press enter to submit the content of a text box", that functionality got removed after 1.3.5. and being a non-coder I wasn't able to figure out how to patch it back in. If you happened to know if that was available in a more recent version of Twine then I could probably move over to that, as I'm still at an early stage.
Anyway, many thanks for offering help to someone using a daft version and also misunderstanding the thread title!
I tried a different route by editing the Sugarcane header.html target and adding the autofocus property to the text field like this: This gives focus to the text field every time one is present when a page loads (which is what I'll want for this game) but frustratingly, the focus disappears soon after! I've tried a couple of other Javascript methods of giving focus to an element within this file but still couldn't get them to work. Not really sure what else I should try at this point.
Thank You
InsertCoin25
I believe that the code is sound, so it may be the case that you do need to change the selector. Ah, yes. If the code above is representative, then the ID of the
<input>
element is simply the name of the $variable, sans the sigil ($).So, in the code example I gave earlier: (assuming the variable really is named:
$prompt
)FIND: REPLACE WITH: As a tip, most browsers ship with developer tools these days, so using those to inspect live elements, to see what their attributes are, may prove beneficial to you in the future.
Unfortunately, the
autofocus
attribute is not yet pervasively supported across browsers, so it's a little premature to try to depend on it (it's not in IE <10, nor is it in iOS at all; according to caniuse.com: autofocus).This close to the holidays here about, I haven't really been working on SugarCube much.
I did try and inspect the element before - as far as I can tell, it came up with the name "input#prompt". I've tried both #prompt and input#prompt in the code you supplied and still couldn't get it to work. I'm sure I've done something stupid!
I thought I'd post the .tws file in case anyone can help out with this. I tried exporting the source but that caused an error and didn't complete.
As I said, I'm using 1.3.5 solely because that's the only version with the textinput macro working in the way I need it to for the kind of fake command line interface I want to use in the game. Perhaps if there's a more sane way of doing this in a more current version that someone could kindly suggest, I can try that instead of this? I really want this particular effect - I'm sure there are arguments against using Twine for it, given that what I'm doing effectively breaks the input paradigm, but Twine's back-end is perfect for this sort of game and there will be points in the game where I want to use a conventional Twine interface as well.
Here's the 1.3.5. Sugarcane header file with the experimental text macro:
https://drive.google.com/file/d/0B9UbOgQWqQg3UW9RdWlobGZiQkE/view?usp=sharing
Here's the .tws file:
https://drive.google.com/file/d/0B9UbOgQWqQg3Rm1WTVZhSGpfNWM/view?usp=sharing
Any help greatly appreciated!
<input type="text">
element within the incoming passage, so it should work on all passages without tinkering. The focus code runs after the "typewriter" effect, and I've set the focus timeout to a fairly long duration (500 ms
), so there shouldn't be any issues now.As a separate issue. The "typewriter" interval delay given as part of the passage tags is in whole milliseconds, so you cannot specify fractional delays. Additionally, the "typewriter" does not handle fractional delays anyway (
t8n-typewriter-0.8
is actually parsed ast8n-typewriter-0
). Beyond that, browsers enforce minimum delays anyway (generally in the range of410 ms
).You also have a syntax error at the end of your
stylesheet
passage: (you've inserted styles within the closing curly-brace of.tab
)I removed the "focus" passage and replaced the typewriter script with your code as per your instructions, but that gives "typewriter: Unexpected token ILLEGAL" - any thoughts? I have triple-checked that I pasted it correctly.
tweego
that is compatible with your version of Sugarcane. I suppose I could try importing that TWEE file back into a TWS, however, I'm unsure if it would be compatible with Twine 1.3.x (again, since I'm using 1.4.2).You're really not doing yourself any favors by using the old and moldy (it's hard for anyone to help you since no one is using it anymore). You'd be better off simply using your macros in Twine 1.4.2 and its version of Sugarcane. You'd be able to ditch some of what you're trying to use now, like the
elseif
script, since that functionality in built into newer versions, and replacing the built-in<<textinput>>
with your version, or a version that does what you want, shouldn't be an issue. /shrugIt is a real shame that "submit value to text box on pressing enter" was removed after 1.3.5. though - that's such a nice feature wherever text boxes are employed. Seems like Twine in general has a bit of a weird relationship with text input so it's understandable!
Many thanks for your help with this - it's really great to find a community of people who are willing to help out someone who is just starting / isn't able to do any of the real code side themselves. Hugely encouraging.
Absolutely fantastic - thank you so much! I'm really excited to work on this further now I've got everything displaying just how I want.
Just in case anyone else is misguided enough to do this, here's the script for the textinput macro from 1.3.5. with the oh-so-evil "advance to the desired passage on pressing enter" functionality:
Well, let's not be hyperbolic. I don't think anyone considers the action-on-enter behavior "evil" (case in point, SugarCube's
<<textbox>>
macro optionally exhibits that very behavior). I'm unsure why it was removed from the vanilla story format's<<textinput>>
macro, but I doubt the reason was because it was considered "evil" (it was probably just an oversight).[quote]
The previous <<textinput>> behaviour of triggering the passage change via the Enter key has been removed for now.
I actually completely understand the reasoning for removing it: that it's not in keeping with the normal navigation paradigms of Twine. Can't find it now but I remember reading a quote from a developer to that effect.