After receiving this error, the screen stops working ("Syncing files to Device Edge ...")
What could be the reason of this problem?
See code here.
I can't understand why it's happening. After this error my widget renders before async function fun.
Assuming ("Syncing files to Device Edge ...") is a async function, program waits for it to finish. But since you try to hotreload before, it can not respond. It is better to just stop the program and re-run again. Or refresh instead of hotreload
Related
In my app the user is presented with a puzzle, drawn by a re-implementation of Flutter's CustomerPainter class and accepting moves made by tapping on the Canvas. The Canvas is continually updated and re-drawn to show the moves. When the user makes the last move and completes a correct solution, the app should tell the user so. The app is using Flutter's AlertDialog to issue such messages to the user.
The problem is that the app is deep in the paint() method of CustomPainter when a solution situation is detected. Any attempt to issue a message at that point crashes the app. The message to the user does appear, but by that time the app has crashed. The error messages are either:
[ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception:
setState() or markNeedsBuild() called during build.
or
[ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception:
Build scheduled during frame.
These messages are followed by comprehensive advice as to what has happened and what to do. There are also several suggestions on Stack Overflow, but I cannot get any of them to work.
If I write SchedulerBinding.instance.addPostFrameCallback in my widget-build it fails to compile because it wants several parts from BindingBase. SchedulerBinding is a mixin. If I try to mixin BindingBase to my Widget, compilation fails again because BindingBase is a class, with a constructor, not a mixin.
If I go the async way, using Future executeAfterBuild(), the app compiles but crashes again, apparently because the async function executes straight away (as is normal) and is not scheduled after the widget-build, as suggested in some of the Stack Overflow posts. The app is definitely not in setState() when it crashes, so maybe marksNeedsBuild() is triggering the crash somehow.
I am using Flutter 2.8.2 and Dart 2.15.1, plus sound null safety. Has Flutter's widget-scheduling policy changed? The Stack Overflow posts I refer to are up to 3 years old.
have you tried putting setState in :
WidgetsBinding.instance?.addPostFrameCallback((_) {setState((){});})
I'm creating a SwiftUI multiplatform app in XCode and I have a section of my code that hangs. I want to update the user so they know what's happening and are willing to wait. I originally planned to have an alert with text that changed and then planned to have a Text element that updated. In both cases this isn't shown until after the code executes and as such only shows the final message (normally the success done message unless an error made it end sooner).
Is there anyway I can have a visible message to the user through an alert or SwiftUI element that is updated right away and thus will be helpful?
The fact that the alert isn't even shown until after the code executes is bad and incorrect. This suggests that you are doing something lengthy on the main thread, and that is an absolute no-no. You are freezing the interface and you risk the WatchDog process crashing your app before the user's very eyes. If something takes time, do it in the background.
For some reason, flutter in VS code stopped showing errors. No runtime or exception errors. Even when I put nulls everywhere on purpose, nothing shows in the console.
The red crash screen appears on device and emulators, but nothing with the details in console output. Not a single error. This image is what I am talking about, it's gone
Anybody ran into such a thing?
Thanks
In case anyone else stumbles upon this, I'll post my brain dead solution (insert face palm emoji). I couldn't figure out what was going on for a good 2-3 hours as I was getting zero output in the Debug Console tab in the terminal window. Turns out I had tried to filter the text using the filter text box. Since nothing was matching my filter text, it was showing nothing. Then I realized I had some text in the text box denoted below. Hopefully this solution saves someone else from some head scratching.
Another common cause of this, is using the filter box in debug console top right corner, if you typed something by mistake, it'll only show the words containing what you typed, and hide everything else. As mentioned by #jaredbaszler.
The code was passed down by another team mate, after inspecting the MyApp state, I found this in the initState, it was logging all error and not being shown in debug console.
#override
void initState() {
super.initState();
getLocale();
configLoading();
FlutterError.onError = (details, {bool forceReport = false}) {
sentry.captureException(
exception: details.exception,
stackTrace: details.stack,
);
};
}
After removing it,I was happy to see the errors and exactly where they were happening. I discovered this a couple of months ago, and posted the answer in case anybody might run into it. Now it seems easy and makes sense, but I missed it.
I am working on an extension/debugger and I am having a problem with step debugging. I have implemented the nextRequest method in my debug adapter and it calls my internal debugger to initiate the step request, then returns the response. I have an event handler that gets notified when the step request is processed and this in turn sends a StoppedEvent of type step to VS Code.
The problem I have is that VS Code reacts to the StoppedEvent by requesting the threads and the stack frames, but it does not render the "stopped" indicator (yellow arrow) at all, so the user has no visual indication that the step succeeded (other than the yellow arrow from the breakpoint disappearing). I'm thinking VS Code may not be getting the right file or line number, but I checked that these are set correctly in the frames I return in the response to stackTraceRequest. I'm not sure what I'm missing here.
This was my mistake. The paths sent were being computed slightly differently form the paths sent at breakpoint events, which is why it worked for breakpoints but not for step events.
When I call this.setState, the render() function is called.
If there is a problem in the render function, this.seState never completes. How can I figure out where in render() the error is?
I do a
console.log('before set state');
this.setState({isLoaded:true});
console.log('after set state');
and I see the first console mention be printed, but not the last one. However, in the iOS simulator there are no warnings or errors or anything. I can find the error by deleting one line at a time from render() and seeing when it stops crashing - but there must be a better way to debug this.
Any ideas?
setState itself calls for a render
from docs (https://facebook.github.io/react/docs/component-api.html) :
setState() will always trigger a re-render unless conditional
rendering logic is implemented in shouldComponentUpdate()