right-clic and go to method xxx now opens in first tab ?

General
1

I used to like this feature : right-clic on one of your method, go to the method and you’re there.
in xojo 2018 if the module containing the method was in an opened tab, it went to that tab
since xojo2019, it always opens in the first tab, and it’s very annoying !
is there some prfrence I missed, or should I fill a bug report ?

2

It goes to the first unlocked tab.

3

it has always been like that or it’s a recent “feature” ?
I’ve never understood what was the purpose and the use of the locked or unlocked tabs …

4

[quote=438589:@Jean-Yves Pochez]
in xojo 2018 if the module containing the method was in an opened tab, it went to that tab
since xojo2019, it always opens in the first tab, and it’s very annoying !
is there some préférence I missed, or should I fill a bug report ?[/quote]
A regression in 2019r1. Makes me use 2018r4 to code and use 2019r1.1 to build only.
<https://xojo.com/issue/55410>

5
  • Well…
  • If the current Tab is unlocked, it will “go to” in the current tab, taking away the focus where you’ve come from. So I don’t want to use unlocked Tabs. A Tab for me contains one of the ProjectItems I’m currently working on.
  • The left-most Tab is by default unlocked, New Tabs are opened locked by default - which is a good thing. Fits perfectly my coding workflow.
  • What you’re saying with your comment only works, if the Tab you want to go is the first-and-only one that’s unlocked…. which will hardly ever be the case

So basically in all situations it’s no longer taking you to the Tab you intend to “go to” :frowning:

If I have “ProjectItem X” opened in a Tab, I want to work on that ProjectItem in that Tab. That’s why I’m using Tabs. And the current "go to " NEVER-EVER takes me there (any more).

Anyway, you’ve got our Feedback:

2019r1.1 would be as perfect as it could for me without this regression. In my dreams I would like to have a 2019r1.1 - Update 1 (only changes in IDE, such as that one - no changes in Framework) :wink:

6

I can’t find anything in the release notes that tells when this has been modified.
will switch back to 2018r4 soon this is really not usable for me.
but PLEASE make a pref checkbox in the IDE so that we can have or not this right clic behavior !
(still don’t understand the benefit of this modification to the user experience ? what is it for ?)

7

[quote=438858:@Jean-Yves Pochez]I can’t find anything in the release notes that tells when this has been modified.
will switch back to 2018r4 soon this is really not usable for me.
but PLEASE make a pref checkbox in the IDE so that we can have or not this right clic behavior !
(still don’t understand the benefit of this modification to the user experience ? what is it for ?)[/quote]
There won’t be a preference as the behavior is definitely a bug. Found the issue last night.

8

I’m glad to hear this seems like it’s going to be fixed.

And just in case you’re building the IDE’s executable off the 2019r1.1 release branch with just this fix… let us secretly know in Feedback.app and allow us to download just the ‘patched’ IDE’s .executable :wink:

9

The Layout Editor is so much better/faster in 2019r1. But for daily work I spend much more time in the Code Editor and navigating through code. So this makes all the IDE improvements in 2019r1 not worth much for me.
I might consider 2019r1.1 for layouting, then go back to use 2018r4 for coding. The (automated) builds again with 2019r1.1 (especially because of the fixed crashes on Windows). Quite a back-and-forth… having both in one would currently fit best (for me).