Skip to main content

I’d like to write a script for the scripting block that includes instructions on first-time usage. Folks won’t need to be reminded of this every time they run the script, so rendering it constantly is not ideal.


I’ve experimented with using the input.buttonsAsync method without awaiting the returned promise. My thinking was that by registering a resolution handler via .then, I could append help text at any time during the script’s execution. Unfortunately, this causes a progress indicator to be overlaid on the scripting block’s interface indefinitely.


If that indicator were not displayed, then my use case would be satisfied. Alternatively, the HTML <details> element could be used for this purpose. That element produces a UI for toggling the visibility of content in a way that is familiar to web developers and web users. The output.markdown currently escapes all markup, but if it could be made to allow the <details> element, that could also satisfy the use case.

Hi @Mike_Pennisi - possible workaround - have another table which records the user who ran the script. Then your script could check this table at the start of each execution for the current user and, if present, don’t display the help text, but if not present, display the help text and update the users table with the current user.


JB

Hi @Mike_Pennisi - possible workaround - have another table which records the user who ran the script. Then your script could check this table at the start of each execution for the current user and, if present, don’t display the help text, but if not present, display the help text and update the users table with the current user.


JB


That could work @JonathanBowen, but it’s somewhat contrary to the underlying goal. The reason I’m trying to document the usage is to eliminate the need for a priori knowledge of the script’s requirements. If doing this means users have to first create a table with a certain name, then I’ll need to document that requirement somewhere. In a way, I’ll have traded one kind of out-of-band instruction for another.

That could work @JonathanBowen, but it’s somewhat contrary to the underlying goal. The reason I’m trying to document the usage is to eliminate the need for a priori knowledge of the script’s requirements. If doing this means users have to first create a table with a certain name, then I’ll need to document that requirement somewhere. In a way, I’ll have traded one kind of out-of-band instruction for another.


I think you could do this within the script. The first question could be “What’s your name?” and then if they select their name. The script can add them to the table. Another option is to ask a Yes/No question at the beginning of the script to ask if they’ve ever run the script before. Then show them the text depending on their answer. This gives that added benefit of letting someone who’s run the script before read directions again if they wish to.

That could work @JonathanBowen, but it’s somewhat contrary to the underlying goal. The reason I’m trying to document the usage is to eliminate the need for a priori knowledge of the script’s requirements. If doing this means users have to first create a table with a certain name, then I’ll need to document that requirement somewhere. In a way, I’ll have traded one kind of out-of-band instruction for another.


Hi @Mike_Pennisi - very possible I don’t understand the usage “setting” here, but I imagined that the table to record first time users wasn’t something that the user added, but that you, as the author of the base, added. It couldn’t be a hidden table (as you can’t hide tables), but it could be a “DO NOT TOUCH” table that’s always part of the base. The script would know about this table, but the users could ignore it. Just a thought - might not work in your scenario.

Reply


Terms & Conditions