Do you see them in DebugView ?
Yes - just as in my manually create log file. It’s only in the IDE that things ghost out.
Hmm that’s odd… do you know the last method that executed?
Perhaps try to add at the bottom of the last known method
Exception e As RuntimeException
Var eType As String = Introspection.GetType(e).FullName
System.log system.loglevelcritial, CurrentMethodName + " - " +etype + ", "+e.message
This should show you if an exception occoured, don’t leave it there in the build cause it will catch all (even exceptions you don’t want to catch there in production builds). It could be showing an exception that happened but didn’t got catched for some reason by the debugger.
Or try to set break on exceptions off/on (and see if makes a difference)
Done all of that and then some.
I’m just marking this up as yet another unexpected feature of Xojo’s IDE …
yup, there are times… i know.
1 Like
yeah it sucks
the macOS log is just a text area but is uses a couple declares to append text very fast so it rarely drops things
the windows one didnt have such declares etc that could be used to make it fly
sorry 
We have 1000’s of log lines but no such issues on windows or mac. Even with lines that are over 1000’s of characters. It’s probably something else.
Maybe memory issue?
rapidly adding log messages usually does the log in on Windows
it can’t handle a lot of messages logged really quickly
Yes note the scrollbar on the right of the message pane, that indicates that the window has some content but its probably just up off the screen, if you touch the scrollbar or the down arrow it should appear.
The problem is the message pane seemingly was implemented using text = text + newtext followed by a scrollposition change which means there are times when no content is visible and causes the view to strobe and shorten and lengthen the viewable content basically making debugging at runtime useless.
I brought this up at the time <https://xojo.com/issue/55628> but it was ignored as I don’t think anyone at Xojo heavily used the windows ide, needless to say I’ve done extensive testing on that issue but have yet to send in my findings/recommendations as always its a huge investment of time on my end with no guarantee of a fix so I just lost interest in getting to the bottom of it.
But I digress, this doesn’t really help fix your problem.
2 hours to get to the issue? Damn, that won’t be easy to find.
Hows the app’s memory usage, any leaks?
Any recurring code that can be removed temporarily to try and narrow down the cause?
Is the time to failure the same each time?
@Björn_Eiríksson does your WindowSplitter use any windows declares or structures?
But if you pause you’ll see all messages
yeah … I know
I don’t understand the question WindowSplitter is plugin control not Xojo code. Native plugin code does not use “Declares”
Ah plugin, gotcha, thanks.
I was not implying that it does - I was just letting Julian know that I was using nothing that Xojo doesn’t provide with the exception of your WindowSplitter. Not implying that it was the potential cause of what I’m running into.
Yes, When I hit the first break, the pane is populated. But, at the point when the app “poofs”, the Message pane is completely barren.
1 Like
the debuglog queue has probably been flooded
hence why I asked about what you see in debugview
1 Like
Both it and my debug log show the last debug output before the label updates. No traceback or other exception.
I think you missed these Tim? I didn’t see any replies.
Also try nuking off the splitters for a test, just in case, I was seeing some odd behaviour when trying the demo of it earlier.