i just updated to Xojo 2024r3.1
it seems the debug log output in the ide does not scroll to the last row?
is that optional now, a new feature?
how can i see the last entry at debugging?
i created a Issue because before (older ide Xojo 2021r3.1) this output in messages was better.
If anyone is interested on the created Issue:
#77914 - 2024r3.1 and 2024r4 DebugLog and Messages Output in IDE, Windows 11
As I don’t use Windows, maybe a screenshot or short video can help me visualize the problem (if you have time). Thanks.
1 Like
Before in 2021r3.1
https://youtu.be/ZuvfSFzbZFU
No Scroll in 2024r3.1 and r4 testing
https://youtu.be/n8onn95bph0
unfortunately Microsoft Game DVR did not record full screen
so status bar with xojo version is not visible in video …
1 Like
Sometimes auto-scroll is really annoying, if you’re logging a lot of info and you want to look at some entries which keep scrolling off the view window. Should be an option, preferably right in the IDE without having to go to preferences.
2 Likes
Not seeing the latest logs is a PITA. And if you try to scroll to see the new logs, the current behavior puts you on the first line of 3000… all the time. This is not a behavior used anywhere, and I can’t see value on it. It needs a fix. As Julia said, it should have a “live” checkbox to disable scroll to the last line so you can walk around manually or auto-scroll to the last (default set). Never the useless scroll to the first line as we currently see.
2 Likes
i would use break or pause the execution of the output will stop.
could also be a flag that debug output stops.
i agree a context menu or button for auto scroll is good idea.
Some codes just should not stop to avoid losing synchronism with other asynchronous parts of the app, so you just log tracking messages and continue.
1 Like
Stopping or pausing logging does not mean buffering to the Message panel needs to stop. That can continue in the background. Stop or pause is only affecting the display of the logging messages.
I’m not talking about it. I’m talking about breaking an app. It means suspending one thread for inspection but we shouldn’t suspend background threads (if preemptive), and while you inspect something, the system state may be changing in an unexpected way and becoming inconsistent. So, under such kind of design, better just log some state or value to track later, and keep going, than breaking the app, breaking also the intended synchronization.
1 Like