Not trying to put oil on any fires but, personally, I prefer the Back buttons to be tab-specific. Makes logical sense to me as that’s what I’m used to with my web browsers.
As Tom suggests, maybe a preference option would help? No idea how much work would be involved or where it would sit in the priority list.
Dave, that sounds like xojospeak.
There is one in very crowd! 
I guess I don’t see the logic… I think Thomas hit the nail on the head. In a browser, the tab are usually unrelated, not different views into the same project that you are working on.
Dave I couldn’t edit my post but they used the exact same logic with the autocomplete combo box that still doesn’t work. It doesn’t work, but works as intended therefore it works even though it doesn’t work, hence xojospeak. I wouldn’t hold my breath on this one ever being changed.
FWIW, I’ve basically stopped using the back button because it never does what I expect. Thomas nailed the reason why.
I’ll give that feedback some points once a particular bug is verified/shipped and I have a new free slot.
The bigger picture here is that we are on release 3.3 and yet some very fundamental features remain broken, such as:
These bugs are not so bad that I can’t work around them and get productive work done, but I think it really says something that they remain un-fixed for so long.
(https://xojo.com/issue/25946)>]25946 - A folder named “Windows” confuses the navigator in the IDEIn my experience, it doesn’t even work the way it was designed. One example is when it trips over this bug: , but it also frequently don’t navigate to the correct spot in other cases as well.
Has anyone else experienced this?
You type in something … and realize you made a mistake (typo, and usually on a property)… and then without warning… it COMMENTS out a line of code seemingly at random and usuallly where you don’t notice it… Then have to track it down when it won’t compile?
This one in particular makes me wonder what’s happening behind the scenes. Why should right-click produce a different result? Don’t the UI elements map to the same code?
Same here. I can’t believe there would be different code run depending on the way in which one selects copy or paste??? Contextual clicking is pretty solid. The menu and keyboard shortcuts are the coding version of Russian roulette.
Beneath the hood they run the same method BUT how they get invoked is slightly different
The contextual menu has NO issues with “what has focus” since that menu is created as part of whatever control got right clicked.
Cmd+C (Ctrl+C) etc do and that’s whats going on and why the difference
Containers in containers in containers
I still maintain that the Navigator is a flawed design. Here we are 3 major releases into the product and there are major issues with focus stealing, copy/paste, and how people would prefer the history to work. If these were easy fixes they’d be done by now.
Just FYI I also fixed these sorts of issues nearly 5 years after the old UI was out as well
Maybe we should appoint a committee.
I don’t think we need a committee, just the back button to work in a reliable fashion :- ). Does the back button take me where I was at in the current tab or where I was at regardless of what tab I am in, or?
I still can’t figure out the IDE. The back button brings me to places I don’t want, there are no book marks and you cannot rename tabs. You can’t create tabs for any underlying objects such as a specific method or code tied to an event. I just don’t don’t get it…
Would it be that difficult just to add some reliable anchor that can be renamed so I can accurately find my way back to what I want to look at, whether that be code in a specific method or code tied to a specific button? Think your “favorites” bookmarks on your browser. No matter where you navigate in the browser that link will take you to where you want to go. To create one just be able to Right click on ANY item in the navigator and “Add to Favorites”. If it is code the code editor is opened, if it control the window editor it belongs to is opened.
What’s the roadmap for the IDE for usability improvements?
I just switched from RS to Xojo and I do not understand the concept of the ‘back button’.
Let’s say I am inside a method. Now I click on a code line and choose GoTo… from the contextual menu.
That works fine. It brings me to the method or what ever I clicked on.
But what I have to do to go back where I came from?
If I click the ‘back button’ I end up at BUILD SETTINGS/Windows. Regardless how many tabs are open.
So, what is the best way to go back easily?
AFAIK there is none once you change tabs
The Back Button works within tabs not across them… Very unintuitive…I’ve stopped using it.
If you stopped using it what are you doing instead?
Right now I am scrolling through the whole project to find my starting point again.
And my project is really big, so it kills me a lot of time!
Sometimes I write rubbish code at my starting point so the debugger brings me back to it if I press the run button.
That is faster than searching manually.
There must be a better way…???
Command-Shift-L is the only thing I can rely on to consistently get where I want to go. Back button bugs out even within the same tab if you use the search or right-click > Go To (method/property/etc), or a few others.
Thanks Karen. Thanks Tom.
How can I read the description?
If I click on the link, Safari tells me that it can not open the address.