Here you go:
Yay! Others may (and probably will) disagree. Running in the first tab was annoying and led to confusion.
Yay indeed.
One big problem with the current Xojo “first tab” system is that too many things try to share it, including the debugger, any code you try to edit from within the debugger, search results from the Navigator Filter, any time you right-click a method and choose “Edit…” and so on.
All of these actions jumping to Tab 0 mean that you can’t keep Tab 0 in a consistent status. My mental model after using xojo for a few months is “Tab 0 will be in a random, undefined state every time you look at it”.
(thinking aloud here) In fact, I think I’d like “Double-click opens in new tab” to be augmented with an additional option “Opening code editor always opens in new tab” perhaps with a sub-option “or jumps to that method in an existing tab if one is already open”
Hedging my responses since I would hate to incite more ‘mob mentality’. 
All it took was a simple, incremental feature request.
I have yet to determine any rhyme or reason to the “tabs” in Xojo (assuming there is any). To the point I ignore them (found them VERY useful in RS.)
I end up with multiple tabs pointing to the same Window or Module. some have locks on them… some don’t…
Can someone explain how they are SUPPOSED to work? or perhaps how they “do work” 
They are supposed to lock you to the object you’re on so you can’t accidentally navigate away from it. Tab locking doesn’t work. Period. I think it broke when they put the tab history in during the R1 alpha/beta period.
Part of the issue with the Navigator is that trying to double click to open in a new tab selects the object first and THEN opens it in a new tab. Thus you have two tabs with the same object selected which, as you’ve found, can be terribly confusing.
The only reliable way that I’ve found, so far, is to right click on the object and say Open in New Tab.
I think it’s supposed to work like that but since the double click ‘selects’ the object first, I think the IDE gets confused to which tab it should be working with.
The fact that double click ‘selects’ the row first I think causes issues. I’m not sure that can be solved in the current implementation because a listbox is supposed to work that way. The Navigator is NOT a listbox but i think they wanted the functionality to be the same.
[quote=24619:@Bob Keeney]I think it’s supposed to work like that but since the double click ‘selects’ the object first, I think the IDE gets confused to which tab it should be working with.
The fact that double click ‘selects’ the row first I think causes issues. I’m not sure that can be solved in the current implementation because a listbox is supposed to work that way. The Navigator is NOT a listbox but i think they wanted the functionality to be the same.[/quote]
How I would do it:
Event Navigator.MouseUp
if SingleClick:
remember my status (scroll position, folders that are expanded/closed, item(s) that were selected)
select the new row
if DoubleClick and "open in new tab" preference is true:
open object in new tab
RestoreMyState // restore my status to the prior one before the double-click beganI would also have the RestoreMyState call trigger after the Navigator Filter field has been emptied.
Well, it’s a workaround but it essentially has three load actions: 1. Selects the object on first click. 2. Creates and selects the double clicked object. 3. Restores the first Navigator tab to the previous selection (and then you have to ignore the selection so focus doesn’t go back).
It’s almost like they need to wait on the selection. The user clicks the row and if they click again within the double click time it opens it in a new tab. If the time is more than the double click time it will simply select it. I guess the question then would then be: Does it seem too slow?
I know I’m beating a dead horse, but I question the validity of the Navigator showing every single possible item in the project - too much detail when you don’t need nor want it. But alas, unless they change the way the selection works my argument won’t matter. Selecting an item causes an editor to load now, and in the near future.
[quote=24614:@Dave S]I have yet to determine any rhyme or reason to the “tabs” in Xojo (assuming there is any). To the point I ignore them (found them VERY useful in RS.)
I end up with multiple tabs pointing to the same Window or Module. some have locks on them… some don’t…
Can someone explain how they are SUPPOSED to work? or perhaps how they “do work” ;)[/quote]
I’m glad I am not the only one lost in the trees…
[quote=24614:@Dave S]I end up with multiple tabs pointing to the same Window or Module. some have locks on them… some don’t…
Can someone explain how they are SUPPOSED to work? or perhaps how they “do work” 
[/quote]
A tab is simply supposed to give you an alternative view of your project. Different tabs are typically focussed on different things. The lock should “lock” whatever level you’re drilled down to. It seems to not work as it should. Opening something in a new tab should drill down to it and lock the tab. With the RS IDE, tabs were essential and very modal. With the Xojo IDE, they should feel optional. If you’re working on 3 things at once, open each in a tab and they should be easy to cycle through as you work.
The biggest problem right now with the navigator and tabs is that they are a little buggy. Specifically, the navigator is a little trigger happy, and tab locks don’t work quite as advertised. These are really tough specific problems to identify, as pretty much nobody has managed to do so in a Feedback report. If you want to help everybody the most, and can figure out what specifically is going on that makes the Navigator feel trigger happy, you’d be a hero for reporting it while everyone else is off redesigning things.
From my perspective, the issues I’m talking about are easy to reproduce, and I reported them in the R1 betas, they just aren’t getting fixed very quickly.
For a sample:
<https://xojo.com/issue/26984>
<https://xojo.com/issue/26962> (Fixed!)
<https://xojo.com/issue/26415>
<https://xojo.com/issue/26314>
<https://xojo.com/issue/26281> - Locked Tabs not Behaving As Designed (not even yet Verified, which is quite an oversight if you ask me)
<https://xojo.com/issue/26195>
and others…
[quote=24660:@Michael Diehr]
For a sample:
and others…[/quote]
Please review your settings for bug reporting and make sure cases are not defaulting to Private
IF you notice the dashboard counts have dropped by a lot - a HUGE pile is merging duplicate reports & closing reports that are no longer reproducible.
Every report coming in as private results in searches not finding it so we get duplicates - tons of them
[quote=24667:@Norman Palardy]Please review your settings for bug reporting and make sure cases are not defaulting to Private
IF you notice the dashboard counts have dropped by a lot - a HUGE pile is merging duplicate reports & closing reports that are no longer reproducible.
Every report coming in as private results in searches not finding it so we get duplicates - tons of them[/quote]
Where is this setting? In Feedback preferences, I see only this one:
“When adding info to a case: Info should default to Public | Private”
Thats the one
Does that also affect the status of a brand new case I create? Or only “when adding info to a [existing] case”? The wording is somewhat ambiguous…
New cases as well