Loss of focus issue: The Hacky Workaround(tm)

The issue: While typing into an $edit-text, it loses focus.

The cause: One example is, the content of the $edit-text (i.e. the target field of the $edit-text) is being referenced elsewhere, and the moment you type ONE character, TW wants to refresh everything that references that field. When that happens, bang, your $edit-text is refreshed/rebuilt – which to you looks like the $edit-text “lost focus”.

If you have a complex UI (I certainly do), it can be extremely difficult to find where the problem actually lies. In my case, the issue arose in a field called subtitle – this field is a key part of my wiki environment and used heavily throughout each system. It worked fine for years and years, then out of the blue, it suddenly started losing focus. I’ve trawled over recent changes looking for the root cause but… nada.

Hence, The Hacky Workaround™ :

\define handle-change()
 <$action-setfield $field=target-field $value={{!!target-field-buffered}}/>
\end

<$eventcatcher
  selector="input.some-class"
  $change=<<handle-change>>
  tag="span"
>
 <$edit-text tag=input field="target-field-buffered" class="some-class" />
</$eventcatcher>

Yeah. I said it was hacky. When the day comes that I spot the true culprit, I may find a way to remove the hack. And whoever added $eventcatcher to the core: I owe you a :beer:. Seriously.

One more thing:

In my case, where target-field is my subtitle field, I had to find every piece of navigation code where subtitle was involved and pre-populate subtitle-buffered with the current content of subtitle. _Otherwise, I’d end up with a borderline race condition. Thankfully, that turned out to be relatively easy. If you only use inbuilt TW navigation, you won’t have that problem.

Thanks for reading.


@EricShulman This is the hacky thing I mentioned elsewhere. Your response here was interesting. Although it didn’t help me directly, it gave me a few things to check.

1 Like

I have also encountered this before, I think it is in Calendar and Agenda plugin tw-calendar with Mobile frendly agenda page layout

Where I am implementing a EventsCalendarSearchLayout, that have a search bar, here:

My comment was

don’t wrap edit-text widget with set or let, otherwise it will keeps refreshing and auto select all text, cause old chars get deleted.

Not sure why, but I also walkaround it.

That’s certainly happening here: nested let/set/vars all over the place :open_mouth:

@linonetwo

A screen grab showing the render:

1 Like

@CodaCoder Thats an interesting UI in the screenshot. Any public wiki of yours available with this UI.

Thanks.

I’m afraid not. It’s a very purpose-specific UI – and that’s only a third or a quarter of it (I have four monitors).

One day, before they nail the lid on, I’ll get it to the point where it’s usable on just two monitors. But seriously, DON’T hold your breath. Time is all we have, and mine is so encumbered by other things it’s not even funny.

I don’t want to divert the topic in this OP …but out of curiosity, are you using a single wiki on four monitors ? How are you doing it…I remember you mentioning something similar in an old post.

1 Like

Only you and @linonetwo have engaged so what the hell…

Hmm… maybe I should split this out.

Yes. One wiki, 3 or 4 monitors.

For now…

The by-hand method

  1. Open your wiki in a browser
  2. If it’s maximized, restore it (unmaximize it)
  3. Position the top-left corner of your browser to the top-left corner of your “left” monitor.
  4. You know what to do next :wink:

The AHK method (AutoHotKey on Windows)


ResizeWin(X,Y,Width,Height)
{
  WinMove,A,,X,Y,Width,Height
}

;For 2 monitors
^2::ResizeWin(-7, 0, 3853, 1055)

;For 3 monitors
^3::ResizeWin(-1926, 0, 5770, 1055)

;For 4 monitors
^4::ResizeWin(-1926, 0, 7692, 1055)

So if I press Ctrl3 my browser fills 3 monitors.

If you use it, you may need to reconfigure some of the sizes/coordinates to suit your setup.

Have fun :slight_smile:

1 Like