IDE of windows still not right (2014R2.1)

I’m still having lots of trouble with the IDE on windows. Selecting code bigger than the code window keeps jumping around sometimes and today I had (for the x’th time this week) a problem with the project explorer. (has been reported but dismissed as not reproducable).

It seems like the project explorer can’t handle function overloading very well. Here is what I noticed:

In the first case: Two different function names are grouped together
In the second case: only the function name is is shown instead of (picStr as String, Name as String, …)

The realy annoying thing is if you don’t see it and press save, you get the dreadful ‘GSOD: Gray Screen Of Death’. (I like to call it that because its equally bad):

Again, lots of time lost thinking what was changed since the last save and sorry to say, completely unacceptable for any respectable IDE.

Also, trying to delete a group with overloaded functions reproduces the GSOD a lot. Most of the time I now delete every individual function, but I don’t think I should work this way and be able to delete the group in one time.

I know stuff has to be done on 64bit and iOS, but please fixing the IDE on Windows should be top priority as this is the place we work in every day. Sorry if I sound pissed off but this is the very last thing any programmer want to have: not being able to rely on your program environment.

Xojo 2014R2.1 Windows 7 64 bit

How can you extract you from the trap (watch carefully the screen shot above about reporting a bug) when you do not have an internet connection at the moment the dialog in the screen shot appears ?

Ignore redraw the dialog and “Report Now” load “Feedback” (yes Michel) and you are in trouble because there is no connection available !

You can still press Report Now. It will save the report on the hard drive until you have a chance to load feedback with an Internet connection. Your crash logs will be very helpful in tracking down the bug.

As far as the Navigator bugs go, we ARE aware of them, CAN reproduce them and ARE trying to fix them. It’s just not so easy unfortunately. They’re not just on Windows.

Don’t know where you heard that the code jumping bug is unreproducible. We have a case for it and it’s easily reproducible.

Thanks for the clarification Greg! Sorry for the tone of the post but at the time I wrote it I was very frustrated because I lost quite some code. (and editing my post was not possible after I settled down :wink: . Fingers crossed for 2014R2.2! :slight_smile:

It was Feedback #35368, but may not have been reported as 100% this error, just a similar crash in the navigator on saving. (my bad)

Save early. Save often. Use source code control often. Seriously.

@Bob Keeney I do, I do, but it’s just I’m typing so fast that in a matter of minutes huge chucks of code come out into existence :slight_smile:

This is where I love an option to “Save before Run”, I know many hate that idea, but personally I love it. Saved my rear-end in Delphi many times… :slight_smile:

I think Xojo technically does save it, but I’ve never had good luck recovering from that save.

Honestly, I hit command S, command R so often I don’t even think about it. I’m sure people watching my videos think I have a phobia or something. :slight_smile:

No “technically” about it.
It does save the project as binary BUT it does not make external items internal when it does this.
If you use plain old VCP without externals then source control & the auto save before running can be very useful.

In agreement with BKeeney, and hear hear hear for Richard Gorbutt, YES. Save before Run. Really easy for Xojo to put in, surprising they never have. VB had it in 1995, 20 years ago. LOVED IT

Yes, I do what Bob said, and there’s the recovery, but that’s so touchy - you don’t know whats been saved and there are times when the rovered version is actually not as up to date. Better to Save before Run.

[quote=134353:@Alain Bailleul]I’m still having lots of trouble with the IDE on windows. Selecting code bigger than the code window keeps jumping around sometimes and today I had (for the x’th time this week) a problem with the project explorer. (has been reported but dismissed as not reproducable).

It seems like the project explorer can’t handle function overloading very well. Here is what I noticed:

In the first case: Two different function names are grouped together
In the second case: only the function name is is shown instead of (picStr as String, Name as String, …)
[/quote]
Fold the row closed & reopen it

But are you saying that IF you save when the visuals are this way it causes the crash ?
I’d report that as every time I have seen this its just presentation and nothing more.

[quote=134397:@Garth Hjelte]
Yes, I do what Bob said, and there’s the recovery, but that’s so touchy - you don’t know whats been saved and there are times when the rovered version is actually not as up to date. Better to Save before Run.[/quote]
We literally save right before running.
I suppose it’s possible there are several versions but the last one saved IS what the project was right before the very last run.

[quote=134398:@Norman Palardy]But are you saying that IF you save when the visuals are this way it causes the crash ?
I’d report that as every time I have seen this its just presentation and nothing more.[/quote]
Not every time they are like this it crashes when I save, but lately every time I had a crash when I saved, I tried to look at the navigator and saw something like that. I was hoping it somehow was related. The first case is in my eyes is the strangest one having two different function names (and maybe that’s also the one that causes a crash when I try to delete the whole group). Could be some kind of ‘key not found’ error in the tree?

Does make sense as I have the crash sometimes when I press run (so probably happens in the save process)

Without a report with the mini dump etc attached its hard to say for sure
BUT - I see his occasionally on OS X as well & it definitely doesn’t result in a crash
Its literally just not refreshed that row with the signature
Hence why folding the row above (for the group of methods) closed then open fixes it