New Version 2018r1: Debugger won’t step to a subroutine located in another window. (Works in 2017r3)
if in my routine, I have it go to a subroutine such as call w1.decodelines , when I use the STEP function, it will not go past this line.
The line stays grey and doesn’t open the W1.decodelines in the Main Thread listing in the debugger.
I also found, that if I put a BREAKPOINT in the W1.decodelines subroutine, it doesn’t stop there! (even though the route is changing the display in my App as it should.
That’s really a mess.
You always have to stop and run the project again if you want to set a new breakpoint (sometimes I even have to quit Xojo and start it again).
This is not so for me (same system), but sometimes the debugger presents an empty panel when stepping over or jumps into methods. <https://xojo.com/issue/51969>
I am also having problems with the Debugger. I have break points but no debug info. When I first compiled a project in 2018r1 my MalwareBytes didn’t like the debugger. It wanted to quarantine the debugger. I setup up and Exclusion in MalwareBytes for user\me\Xojo and then I could at least build the program. But when I got to debugging only had break points and no debugging info at all. In fact, there are no step and step into buttons at the top of the window.
The official bug list ist always in Feedback. See my link above and others in the prerelease forum. [quote=385023:@Alexandre Cunha]No one on Xojo Inc. replied here yet?[/quote]
This forum is a user forum. Some engineers do read and write here occasionally, but that does not mean it is a feedback channel for bugs and proposals. That is the Feedback app.
But in big Projects, it’s really anoying. Because starting the debugger and waiting until the full “Own App System” is running again, can take a while…
Ulrich,
I tried to access Feedback from the link on 2018r1 and it didn’t do anything. I just rebooted and reinstalled Feedback from the link on the website and Feedback appears to be working now (from 2015r3). I think something “hurt” my Winders 7.
After building my app with 2018r1 the build directory was corrupted. When I ran the app on the target machine it had a runtime error, something about a DLL that wasn’t found. I didn’t save the error message. I wiped the build folder and re-built the app with 2017r3 and all was fine. Whew! I will put a report in the Feedback for 2018r1 and fall back to 2017r3 for the mean time.
I’ve built a web app in 64 bits with 2018r1 and it worked without a flaw.
Nevertheless, we’d better wait for a more stable version for now. I have not encountered any difficulty when falling back to 2017r3.
Web app is exactly the topic for me. I am working on one where a thread sometimes silently fails. The debugger will only tell me the id of the thread and its debug identifier, but no exception or anything of that kind.
I cannot revert to 2017r3 because I need the new FileUploaders features.
