Bob and keystrokes

[Ed Heil]

I've got a wiki going on where I keep track of information for a tabletop roleplaying game.  I've got it set up with Bob so everyone can see it at once.  It's pretty great.

One thing that I'm finding is that sometimes Bob doesn't seem to pick up all the keystrokes it's being sent in edit text boxes.  For example, I have a box where you can type in a number and then hit a button, and that number will be added to an existing value somewhere.  Somebody might type 100 and hit the button, but then only 10 will be added to the other value.  It's as if one of the keystrokes never made it to the server and back.

Of course, having every keystroke in this given edit text box get sent to the server is how TW/Bob works, but it seems like it's causing more trouble than it's worth.  I'm wondering if there's anything I could be doing to make this simpler.  Like, if it were a regular form on a normal page, you could type all you wanted in it and nothing would go to the server unless you submitted it.  So there would be no way what was in the box could get "out of sync" with what was on the server.  That's not how TW works -- everything typed in an input field immediately affects the TW, and in a Bob context, it immediately affects the state of the app as known to Node on the server.  But...  I wonder if there's a way around this problem.

It seems like by typing very slowly and carefully the problem is minimized, but I'd love it if there's a way to actually solve it.

I think (not sure) the problem is worse when multiple people are looking at the wiki at once so there's more to update.

[TW Tones]

Ed,

Great to hear your application.

You should be able to design around this. Editing the current tiddler or others can cause

1. loss of focus (due to edit self)

2. Delays if the entry causes a refresh elsewhere (on screen), or even if displayed in the current tiddler.

I expect you can reduce this by using a similar approach to html forms, such as edit a temporary tiddler/field and have to hit a submit style button, that copies the value in one hit to the destination. Since bob synchronises on a per tiddler basis such a submit kind of occurs anyway.

If none of the above are your issue, have a look at this https://tiddlywiki.com/#Hidden%20Setting%3A%20Typing%20Refresh%20Delay or if possible making use of the draft mechanism.

Regards

Tones

[PMario]

Hi Ed,

You can create a form, that uses a temporary tiddler. Those tiddlers are not synced. Once your values are written you can hit a button, that copies the temp values to the real values. --> done

-mario

[Ed Heil]

Thanks, TW, PMario.   What defines a temporary tiddler for these purposes?  Being under $:/temp/ ?

[PMario]

On Tuesday, July 6, 2021 at 4:29:30 AM UTC+2 Ed Heil wrote:

Thanks, TW, PMario.   What defines a temporary tiddler for these purposes?  Being under $:/temp/ ?

Yes. ... It depends how your form looks like and how the tiddler you need looks like. I would define a view-mode for the form, where the edit fields are not active, but show the content of the "form tiddler".  This can be done with the "disabled" parameter since 5.1.23. ...

A button eg: [Config] will copy the "form tiddler" into the "temp tiddler". If the temp tiddler exists, the "disabled" state will be switched to "no" and the values can be changed. [OK] [Cancel] buttons that replaces the [Config] button will be shown.

Cloning the "form tiddler" can be done with ActionCreateTiddlerWidget, which has $template and $overwrite params since 5.1.22

A disabled filter can look like this: disabled={{{ [[$:/temp/form]is[tiddler]then[no]else[yes]] }}} 

hope that helps

-mario

[PMario]

uups forgot something,

Clicking the [OK] button will work the other way around. Clone temp -> form and delete the temp.

The edittext-widgets tiddler parameter will need to be a variable. ... depending on which tiddler is active atm. form or temp

-m

[Ed Heil]

This is all great info, and clearly what I need to do.  I didn't realize that there was special behavior for $:/temp tiddlers with respect to saving.  (The only mention I can find on tiddlywiki.com is in "Naming of System Tiddlers" which I thought was just about naming conventions, not names which trigger special behavior.)  Now I've got to figure out whether it's doable to fix my app piecemeal -- which has tons of editing fields which act directly on the tiddler they're on -- or whether I need to somehow start over with a temp-tiddler-based editing flow.  Ah well.  You live and learn.

Thanks again for pointing me at $:/temp.

[TW Tones]

Ed,

A long answer is there are ways to edit the current tiddler, even without a temp tiddler. I am building a solution which does this now, it involves a little gymnastics and is hard to explain with too many different aspects to it. I will eventually publish something. 

One handy way is to have a tiddler dedicated to editing other tiddlers. In there you select the tiddler you want to edit, and all your editing takes place on the not visible selected tiddler.

Regards

Tones

[Ed Heil]

Thanks, Tones.  I will be interested to hear it when you are ready to make your plans public.

I've been working on the "edit in a temp tiddler" thing and made some big ugly macros that do the job swimmingly.  I should be able to get the app converted over to using temp tiddlers for editing, in general, soon.

[PMario]

Did you test it with 1 field first?

-m

[Ed Heil]

I haven't had a chance to test it live with multiple people using the wiki (which is where problems seem to arise) but "click to edit this value in a temp tiddler and save to the real tiddler" stuff I've made seems to work so far so theoretically I'm on the right track!