33688 is another. Marked as “Unreproducible” but that is incorrect (see notes above).
64 bit is still the top rated case and is well underway. Please move some love to this issue if you have it there.
It seems the issue with the “Windows”-named folder still persists.
Since it was marked as “unreproducible” in case #33688 I took the liberty of opening my own case on this and adding a video that shows exactly how it can be easily and reliably reproduced. Can anyone reproduce and confirm this?
<https://xojo.com/issue/45465>
At XDC last week Xojo said they are going to modify the IDE. Based on what little information they released it looks like each tab you create starts with the project list and then switches to the appropriate editor when double clicked. This is sort of a hybrid between Real Studio and what Xojo does now. I wrote about it (and snapped a few pictures) at http://www.bkeeneybriefs.com/2016/10/xdc-news-ide-redesign-coming/
The reason I post this here is that I assume that the back/forward buttons will work more like they did in Real Studio since this redesign looks more Real Studio-ish and I don’t ever remember anyone complaining about the back/forward buttons there. The Navigator in Xojo makes this really difficult for a variety of reasons.
I always was feeling insecure with the Xojo IDE (but I do not really used the last six or seven releases: I stay with 2015r1).
Even selecting a word have its troubles (as a very old Apple user). If an Apple user want to add some characters to a double-clicked word (shift-arrow) that Apple user will fall in troubles
Where are my short cuts ? (I know there is a list of them, but since Xojo, I stoped to use them: too many changes ?).
That said, if I am the only one to have these troubles, that is only me.
I am currently forced to use the new IDE. The back button is still horribly unusable.
Here’s another example:
I use Find to locate a method, I select the found line and thereby end up in the method’s editor.
I edit some code in the method. Then I add a constant to the same class. Then I try to get BACK to the METHOD, so I click the Back button. But that does not bring me back to it! Instead, it brings me somewhere else where I was long before that.
WTF is this code doing to get this so horribly wrong?! Implementing a working trace of the currently visited locations can’t be so hard. There is already clearly code in the IDE that knows the current location. It’s used to select the item in the left pane, for instance. All one has to do is record that changing value in an array, and you have already a much better working solution that what we have now.
To be clear, what’s listed in the navigator isn’t always granular enough. Sometimes you want the back button to take you to a specific point within a method.
[quote=291689:@Thomas Tempelmann]
WTF is this code doing to get this so horribly wrong?! Implementing a working trace of the currently visited locations can’t be so hard. There is already clearly code in the IDE that knows the current location. It’s used to select the item in the left pane, for instance. All one has to do is record that changing value in an array, and you have already a much better working solution that what we have now.[/quote]
In fact this is PRECISELY what it does now and is exactly why it doesn’t, and can’t, work right.
If you have a folder named “Windows” and there is a Build Step also named “Windows” which location does “Windows” refer to ?
Thats a simple example.
Overloaded methods do NOT include all the params & return type as part of their location.
But to be able to jump to the right item they would need to.
Locations are simply the fully qualified project path to the method - without params & return type.
So when you have several with the same name you will see it select the wrong one.
When you type a location in to the GotoLocation dialog you’ll see it make similar incorrect choices for the exact same reasons.
IF this were trivial to fix it would have been fixed long ago
But the Back button doesn’t even work as we’d expect if there aren’t any objects with duplicate names. A typical case: I open a window, then open its Open event. The Open event calls a CheckRegistration method that is located in another module. I right-click the call to CheckRegistration and have Xojo take me there. I do some work in that method, which calls a method called RepairStr. I dig into that method, and change a line or two in it. I want to hit the Back button to go out of RepairStr and back to CheckRegistration, and another hit of the Back button should take me to the Open event where I started the whole thing.
Web browser forward and backward buttons manage to do this, but the current implementation can’t go backwards if the editing trail would take you out of the current window or module. IMHO that means it’s broken.
The Back button in RealStudio worked perfectly, just give us that and I’ll be a happy camper. If it was possible in RS, it should certainly be possible in Xojo.
For me the problem is simple to replicate. I highlight a bunch of code and right click & select the convert to method option. Now I have a method, I give it a name then click the back button to take me back to the exact place I converted to method. Why? because I want to place a call to that method there! Can do? Not in the current IDE, but did in RS. This is the ONLY thing I miss from RS.
It should have been trivial to NOT introduce this bug, though.
Now, after 3+ year, the minimum would be having this bug fixed, because it severely impact on the already compromised from Navigator IDE usability.
I just avoid the Back button, for my sanity’s sake. I wished it worked as I expect (like RS or VB or a browser), but it doesn’t. After this long, pointless for me to get worked up about it, I’ve just learned to use other things in my workflow to get where I am going. I am sure it is not a trivial task to change as Norman says, but why put it in, in the first place, if it doesn’t work?
I never used that Back button. I was wondering what it was until some good soul shared a video.
What about the IDE forgetting your open events (when you quit it reload it) ?
[quote=291895:@Massimo Valle]It should have been trivial to NOT introduce this bug, though.
Now, after 3+ year, the minimum would be having this bug fixed, because it severely impact on the already compromised from Navigator IDE usability.[/quote]
I’m glad your familiarity with the IDE code base has made this a “trivial to avoid bug”
Perhaps you could review the IDE code base and suggest a fix ?
Seriously, anyone suggesting this is trivial to fix or was trivial to avoid has an incomplete understanding of the problem.
And that will be my last post in this thread.
It’s been over three years. Trivial or not, that’s a long time to wait for a feature to work properly.
Well at XDC Geoff announced significant changes to the IDE, so sit tight and maybe it’ll change.
Which suggests that the underlying design is so messed up that the only way to fix it is to rewrite it.
This happened to me, sometimes (in some projects).
The concept of the current IDE is so bad, that I fear the next IDE will have the same amount of concept flaws even if the main concept is good by intending to go back to an IDE à la RB.
In my opinion the main issue Xojo Inc. is facing is that developers should not be charged with creating such a complex UI without the assistance of pros. This is not meant as an offense towards the developers at Xojo not at all (< this must be bold, because I really mean that) , but it is just not their profession to design a UI. They were never trained for it. And they don’t do it as a full-time job. In addition I assume as the small team they are, they will not be able to put enough time into this process anyway.
Conclusion:
<joke style="sincerity-level=partially;">
We will suffer till the new IDE arrives. We will suffer after the new IDE has arrived.
</joke>
Xojo has the potential to be one of the best solutions on the market, but not if done like in the last years. I think the time is over that developers accept bugs and flaws like the ones in Xojo. Not only the developers already using Xojo, but developers downloading the trial version in hope of testing a good product.
[quote]Locations are simply the fully qualified project path to the method - without params & return type.
[/quote]
This I don’t understand. Why has this design been chosen? That’s like a database table without a unique attribute. Seeing that Xojo gives us the wonderful option of overloading methods, it seems strange to decide that params and return types are not part of the location.