0.11-RC3: The expression bar never has focus on start

[Former user]

Originally reported on Google Code with ID 465

Steps to reproduce: Install 0.11-RC3 and start the program. Configure the constants,
functions and/or variables windows to show up. Shut down the program and start it.

Expected behavior: The focus/cursor should be in the expression bar, where you write
the formula. Always been in earlier versions.

Experienced behavior: The focus/cursor never is in the bar, instead it is, in my case,
always in variables' search bar.

Product version: 0.11-RC3

Operating system: Window$ 7 Ultimate 64 tested. If wanted I can test it on Kubuntu
13.04 64.

Additional Information: This never happened in any version before 0.11-RC3. As far
as my graphical programming experience has taught, you can tell the software where
to have the cursor/focus in which order, so this'd sound like the reason for this.

Reported by JouniJarvis on 2014-01-04 23:36:04

[Former user]

I've experienced this but only happens randomly (on Ubuntu 12.04), so it's hard to debug.
Alessandro, do you mind checking on Windows/Mac?

Reported by helder.pereira.correia on 2014-01-11 04:06:54

[Former user]

My revision de81fbc0 from Dec 15 supposedly fixes this, actually. RC3 came out days
later, so I assume the change is in there. Again, Alessandro, do you mind checking
on Win/Mac please?

Reported by helder.pereira.correia on 2014-01-15 08:13:37

[Former user]

JouniJarvis; do you mind trying out the binary available at http://code.google.com/p/speedcrunch/issues/detail?id=463#c14
and let us know if this still happens? So far you're the only one able to reproduce
it, which doesn't help.

Reported by helder.pereira.correia on 2014-01-26 05:41:48

[Former user]

Also, this is the only blocking issue for release 0.11.

Reported by helder.pereira.correia on 2014-01-26 05:45:51

[Former user]

No difference with that binary.

Reported by JouniJarvis on 2014-01-26 11:56:11

[Former user]

JouniJarvis: Thanks for testing it. My request may sound weird, but could you send a
screen shot of your SpeedCrunch. Perhaps a special combination and order of the tool
windows cause that issue.

Helder: Do you think that increasing that timeout from your commit would help? I slightly
doubt it, but as a desperate measure I think we could try with 250ms.

Reported by alessandro.portale on 2014-01-27 08:36:20

[Former user]

Interesting: the cursor's location varies when I don't enable options according to the
order in the menu: with them disabled, enabled Formula Book, then Constants, then Variables,
then Functions, and rebooted SC. The cursor is literally nowhere, but I hit 9 3 times
and close the Functions by the X, the '999' is in Variables's search bar. Confirmed
to work second time too.

Now, after rebooting SC, the cursor in back in the expression bar where it belongs.
Confirmed second time.

I've always ticked the options according to the menu order.

Screenshot of my SC, the following options enabled in the menu order:
- [View] Status Bar
- [View] Menu Bar
- [Settings -> Result Format -> Decimal] Fixed Decimal
- [Settings -> Result Format -> Decimal -> Precision] Automatic [default]
- [Settings -> Result Format -> Radix Character] Dot
- [Settings -> Angle Unit] Radian [default]
- [Settings -> Behaviour] {all except 'Minimize To System Tray' & 'Automatic Result
to Clipboard'}

Reported by JouniJarvis on 2014-01-27 12:23:43

<hr> * Attachment: Untitled0.png<br>

[Former user]

Typo in the last comment: the cursor is back in the expression bar

Reported by JouniJarvis on 2014-01-27 12:38:16

[Former user]

Thanks you for the screen shot and explanations. And indeed, I can reproduce that when
e.g.:
- I open constants then functions
- I click into the search field of the functions
- I close the functions tab

...the cursor is gone. There are other constelletions where the cursor/focus can be
in a tool window which is in the back, so that the input (e.g. 999) lands there.
Helder: Should we try to avoid that?

But I was not able so far to reproduce that the cursor is not in the main entry field
on the bottom when starting SpeedCrunch. Do you have an idea how to reproduce that
behavior?

Reported by alessandro.portale on 2014-01-27 20:49:47

[Former user]

I've tried quite a few different hacks to fix these corners cases. Whenever I think
I found a solution, I managed to get the broken behavior at a random try. I'm convinced
there is some sort of Qt bug here. Again, I'm also never able to reproduce the situation
where the editor doesn't have focus on launch. I've decided this bug will have to wait
for the release after 0.11 and stop being a blocker for now.

Reported by helder.pereira.correia on 2014-01-29 08:47:11

[Former user]

Dunno whether it's intentional, but writing to Variables' search bar, cutting the text
with CTRL+X, clicking on the expression bar and trying to paste with CTRL+V keeps pasting
it into the search bar instead, requiring to right-click on the expression bar to paste.

Reported by JouniJarvis on 2014-01-30 08:49:14

[Former user]

An idea hit me: the expression bar seems to be a custom-made control and doesn't have
focus index or anything regarding focus, so maybe that is at least part of the problem.

Reported by JouniJarvis on 2014-02-05 15:18:48

[Former user]

If text boxes don't have indexes, 1 possible way to circumvent this issue is to create
the controls onto form in specific order. If that's the way, then you're missing some
property from the controls.

Reported by JouniJarvis on 2014-03-29 18:22:53

[Former user]

Reported by helder.pereira.correia on 2014-11-28 17:25:24 - Labels added: Type-Defect

[Felix Krull]

I split off the part about the focus going away when closing dock widgets into issue #637.

---

I can reproduce the start-up issue most of the time (Qt 5.6, Windows 10, master and 0.11) with the set of docks that JouniJarvis mentioned: Formula Book, Constants, Variables, Functions. It seems to be just a race condition: when launching SpeedCrunch with some docks open, several widgets have setFocus called on them; notably the editor, but also the search fields in the variable and function widgets. Depending on how the various timers and the event handling work out, one of these widgets "wins", i.e. gets the final setFocus call and remains focussed. With this combination of docks, it's often the variable list for me.

This should be solvable by letting the dock widgets know when they're being opened during start-up (versus due to user action) so they can appropriately not call setFocus.

[Felix Krull]

Fix docks menu entries update; not all docks steal focus.

Fixes issue #465.

→ <<cset 413b09fc20ed>>

[Helder Correia]

Fix docks menu entries update; not all docks steal focus.

Fixes issue #465.

→ <<cset 413b09fc20ed>>

[Helder Correia]

See pull request #71.