Bug 33684

[Reproducible] with "LibreOffice 3.3.0 RC4 - WIN7  Home Premium (64bit) German UI  [OOO330m19 (build 6 / tag 3.3.0.4)]". Now to other autofill contents can be scrolled with <ctl>+<tab>.

German Help says TAB will scroll, also English Help for AutoInput does not match with actual behaviour.

In OOo3.4-dev still TAB is used for scrolling to next possible autofill contents.

I believe it will be the same for all OS.

Bug or feature?
Wrong Help or Wrong behaviour?

WIKIHELP <http://help.libreoffice.org/Calc/AutoInput>
also does not match with actual behaviour

This is a feature, and the help needs updating for this.

I filed
Bug 34019 - WIKIHELP does not match with actual behavior for AutoInput
and close this issue due to Comment 2

(In reply to comment #2)
> This is a feature, and the help needs updating for this.
No, its a bug.

(In reply to comment #2)
> This is a feature, and the help needs updating for this.
No, its a bug.

My mother says it is a feature, so there!

(In reply to comment #6)
> My mother says it is a feature, so there!
My girlfried got the big hate and says this is a bug that its changed, so it should be changed. The user should be able to change the default behavior but you never should change the default behavior, that causes a lot of trouble. I got that problem often in history and its NOT surprising for the users.

We believe in Change.

(In reply to comment #8)
> We believe in Change.
Never change a good working thing. To change a default behavior is a bad thing. User which want to want to change it can do it. Ask the users outside... the answer is: no new default behavior.

Oracle bones might hit mother's intuition ;-)

@Christoph Thieleck:
May be you should improve your knowledge concerning UI design for a software that has to work under various OS with common UI without conflicts with default OS UI shortcuts. That might help you to understand the reasons for such changes.

Me and my fingers also dislike those lots of additional new <cntrl> keys for various shortcuts, but as long nobody has a better solution considering a.m. basic conditions, we will have to live with them.

@ Kohei
Could this be added in OpenOffice Legacy key binding ?

(In reply to comment #11)
> @ Kohei
> Could this be added in OpenOffice Legacy key binding ?

I'm afraid not, as this one is unfortunately hard-coded.

What shell we do with this issue? I don't see any simple solution.

The lots of 3-key combinations we currently have are not very user friendly, but may be the only way to get a more or less consistent UI for all OS.

May be we need some "shortkey.cfg" (or .oxt) that will allow to define all shortcuts by user, and may be predefined files available via download that will allow to install a "use MSWORD4.5 shortcuts" easily?

Unfortunately the normal shortcut key scheme doesn't apply in this case, because these key inputs are handled as direct key input i.e. like typing 'a', 'b', 'c, etc into a cell, and you can't assign a shortcut key to direct key inputs.

Of course it's not impossible to make this configurable, but it may create more problems and makes the code less maintainable (the code that handles direct key inputs is very fragile).  And quite frankly I don't know if it's worth the risk.

But I guess we can't close this bug since if we do, it will get re-opened anyway. ;-)  So, let's leave this open for now, but set it to lower priority.

I'll keep this bug for the time being.

Its still not fixed in libreoffice 3.3.2.

I don't want to be the assignee.

Using LibO_3.4.1_MacOS_x86_install_en-US, neither Tab nor ctrl+Tab lets me scroll through the alternatives. (I also tried the other ctrl/option/cmd+Tab combinations I could come up with, to no avail.) I started noticing this changed behaviour in 3.4.0, I think.

The help also mentioned cmd+D to get a list of all the alternatives. That was new to me, but it didn't work anyway.

So is this a bug, or have I overlooked something really obvious?

Same to me on Mac OS X, German Translation. Neither Ctrl-Tab, nor any other combination works. The CMD-D as mentioned above doesn't work, too. It's frustrating that a) the default behavior was changed and b) there is no working alternative. So we still have to continue using OOo on our Macs. And even on the Linux and Win-Desktops, as we can't force our users to use different key combinations on different platforms. Very sadly that one little thing makes the biggest trouble. But being unable to rotate to the AutoInput makes the Calc nearly unusable for us.

Forgot to say: we use LibreOffice 3.4.0 on Intel Mac.

This is still present, even in 360RC2 and, Kohei, it is definitely a bug: on OSX you cannot browse through suggestions nor move to another, next suggestion. It is a broken feature, even if its keyboard shortcut was changed in beetween for other OS where it might work.

AutoInput is used a lot in spreadsheet use cases, i.e. in companies and NGO which might have a negative impact on perception of LO as a truly full-featured office suite, as well as this makes a function in OSX unaccessible, which makes this feature non-existing.

So, to ask clearly: what is the correct shortcut for all OS:
- accessing the list of all possible autoformat suggestions
- jumping to the next autoformat suggestion

This is why I chenged it from enhancement to a normal priority bug. Slovenian enterprise users are crying to get this back working as before.

Thanks, m.

After more than 18 months nothing changed. 
This bug is the reason, why we and many others still run on OOo.

Any updates?

Confirmed in LibreOffice (Dev) 4.4.0 alpha1 under Mac OS X 10.10 (Yosemite) x86-64

Status should be NEW not REOPENED.