Text edit %focused always reports true

[Neil Bird]

In trying to set a separate background colour of the currently focussed text edit widget, I've found that the %focused variable in the event is always true (both when gaining and losing focus), leading each widget in turn to think it's the one with focus until they all do.

Someone else seems to be reporting this on grokbase as well, with no response.  Is this a legitimate (common) bug or localised to our set-up/devices?

[Pent]

I can reproduce that and will try and think of a way to fix it (it's a difficult timing
issue)

Pent

[Neil Bird]

Cheers.

Weird timing bugs are the worst...

--
Boring .signature #1,423

[Pent]

Looking further at this, turns out it applies to all built-in scene variables
(e.g. element name) when scene tasks are running simultaneously,
because all tasks launched from a scene share the same set of variables
which dynamically update.

So while the 'lost focus task' is just starting running, the 'gained focus' task starts
and sets the scene-shared %focused variable to true, a change which is
also seen by the 'lost focus task'.

I'm amazed this problem hasn't come up before...

Needs a bit of thought. Possibly I could make the built-in scene vars non-shared.

Pent

[Neil Bird]

Could you work around it by assigning each automatic scene task (like focus in and out) a different task priority; that way they'd all run serially our maybe Int auto ones that that *can* run in parallel.

Sorry, shouldn't really suggest anything without knowing the codebase 😃

--
Boring .signature #1,423

[Neil Bird]

Actually while you're around: are the sizes of scenes' portrait and landscape views linked?

I had a decent portrait scene, then when I went to arrange a large-scale version of a slightly different size, the portrait one shrunk a lot.

I was wondering if the scene's core size was common?

On 25 August 2016 10:51:38 BST, Pent <crafty...@gmail.com> wrote:

--
Boring .signature #1,423

[Pent]

Couldn't think of any 'proper' solution to this which isn't extremely painful
in terms of time and probable bugs.

For now, I will add a small delay to the 'gained focus' task, so the
'lost focus' task has a chance to record the value of %focused
via the first action being Variable Set, %this_element_focus, %focused

Pent

[Neil Bird]

On 26/08/16 08:59, Pent wrote:
> For now, I will add a small delay to the 'gained focus' task, so the
> 'lost focus' task has a chance to record the value of %focused
> via the first action being Variable Set, %this_element_focus, %focused

If it works ... :-)

--
[phoenix@fnx ~]# rm -f .signature
[phoenix@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[phoenix@fnx ~]# exit