Make a simple desktop app and insert into the window open event:
Dim a(0) as integer
a(1) = 1
An OutOfBoundsException is raised.
Then try to navigate round the app.
The result is a loop “This application has encountered a fatal problem and must be shut down … etc”
No report can be generated and the application has to be force quitted.
This is the simplest example but seems to occur after ANY breakpoint is encountered.
But the example was just the simplest I could think of.
When developing and testing stuff, inserting break points at various points in the code and being able to navigate around to help in debugging was a very useful tool in RB and RS. Have we lost that facility?
I have seen this happen, but not consistently. I’m sure if you can make it happen consistently then Xojo would love to get a copy of your project.
Bob what I think Bill is saying is that he starts a debug of his project. When it hit’s an exception he is unable to navigate through his project to trace the exception without the IDE crashing. This is not or should not be normal behaviour.
I am running 2013r1 under OSX 10.8.4 and they are working 100% as expected.
I duplicated your code example… and everything behaved as expected.
My current project is 75,000 lines of code and I’ve been putting breakpoints in various locations during my testing, and have had no problem what so ever.
Ah. Sorry, the misdirection through me for a loop.
As with Dave, I’m not experiencing any issues with breakpoints. However, if you have a breakpoint AFTER the exception it won’t get to that point because it exits the function immediately.
I have no idea why they are so adamently opposed to it, locking out editing solves a very small problem that rarely comes up, and that the forums admins have complete control to stop if needed.
I guess “Steven Taylor” demonstrated elsewhere in Xojo forum that replies may be edited as long as there is no new post after your reply. However there is a bug in the forum software such that the editing of a reply is not allowed immediately unless one moves away from that particular discussion and then returns to avail the “edit” option.
Just like I did now. (This line was added via an “edit”). And also corrected the “no allowed” to “not allowed” above.
Right, I know about that bug, a simple browser refersh fixes it for me. I would think if you change your post frequently to support another point of view after others disagreed with you, that would be a problem. But that behavior is pretty easy to spot and even easier to see if someone did it frequently. Just can’t imagine that being a significant issue in this small community. I looked through the old forum and saw a handful of examples of this over the years, I can’t imagine that being enough to enforce a policy that doesn’t allow edits for 20 minutes.
I agree your thread has been hijacked. On WIndows 7 x64 I’m not seeing this. I would suggest making a movie showing your experience and create a feedback report attaching the movie. Then report back here with the FB case and perhaps email custserve@xojo.com asking for a review.
[quote=15908:@William Atherton]But the example was just the simplest I could think of.
When developing and testing stuff, inserting break points at various points in the code and being able to navigate around to help in debugging was a very useful tool in RB and RS. Have we lost that facility?
Bill[/quote]
Indeed, a life without being able to examine properties when breakpointed would not be worth living. Xojo is working for me in this respect, however.
Since nobody else is experiencing any problems with Xojo in regards to break points… I suggest that you create the smallest project possible where the problem still exists for you… Post it … and provide step by step sequence of events to reproduce the behaviour.
That way any of us here, can take that code, load it on our machines, follow your sequence and either get the same error or not.
Also provide the details of the computer you are using so we can compare that as well.
I submitted a movie to Feedback on 25th June.
Case 27694.
No response yet.
I can reproduce easily:
Run Xojo
Choose new desktop project named testBreak
Add open event to window1
Insert code: Dim i as integer
Add breakpoint to this statement
Hit run
The ide hits the breakpoint.
Select window1 in the Variables subwindow
After a second or two, the following window is shown:
This application has encountered a fatal
problem and must be shut down.
Please tell us more about this problem. An error
report has been prepared which will help us improve
the product. Would you like to launch Feedback and
report the problem now?
Ignore Report Now
Hitting either pushbutton just keeps re-displaying this window.
testBreak has to be force-quitted.
Then hitting ignore a few more times quits Xojo
I should have said that I am using a MacBook 13 inch. I have tried with and without plugins, in 10.6.8 and 10.8.4 with same result. (I am currently on holiday in England from Australia (tragic - I know and I migrated to Xojo just before I left. I cannot recall if this problem was present on my big Mac desktop machine.)
Just tried exactly what you outlined above and things were fine but mind you I am running xojo in win7 which I suppose might be different. But could not replicate your first or latest example. Having said that I did have a problem similar which a “fresh” download and install rectified and has been fine ever since.
It may not be project related, but rather Xojo prefs related, at least it was for me. (Which is why some people don’t see it, but others see it with all projects)